CODEWITHSUNDEEP
postgresqlnhibernatenpgsql
Dimitar Lichev
Dimitar Lichev

Reputation: 385

Npgsql causing System.NotSupportedException

For the last two years we've been developing a web based application with ASP.NET MVC 3, NHibernate (v. 3.3.1.4000) and PostgreSql for back-end database, therefore using the Npgsql driver (v. 2.0.12.0). The system has been in successful exploitation on 4 different client servers and has never produced the error I encountered on a new server we setup recently. The exception has occurred only once, upon the initial population with data, and prevented some business entities from being stored to the DB. I really must make sure that in the future the error is properly handled, if not at all possible to be avoided, but am at a loss how. Searching the site and the internet in general for this or similar errors has produced no information. Has any of you encountered this problem or have an idea how to fix it? Thanks :)

Here's the error:

System.NotSupportedException: This stream does not support seek operations.
   at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin)
   at System.IO.BufferedStream.FlushRead()
   at System.IO.BufferedStream.WriteByte(Byte value)
   at Npgsql.NpgsqlSync.WriteToStream(Stream outputStream)
   at Npgsql.NpgsqlReadyState.SyncEnum(NpgsqlConnector context)
   at Npgsql.NpgsqlState.Sync(NpgsqlConnector context)
   at Npgsql.ForwardsOnlyDataReader.GetNextResponseObject()
   at Npgsql.ForwardsOnlyDataReader.GetNextRowDescription()
   at Npgsql.ForwardsOnlyDataReader.NextResult()
   at Npgsql.ForwardsOnlyDataReader..ctor(IEnumerable`1 dataEnumeration, CommandBehavior behavior, NpgsqlCommand command, NotificationThreadBlock threadBlock, Boolean synchOnReadError)
   at Npgsql.NpgsqlCommand.GetReader(CommandBehavior cb)
   at Npgsql.NpgsqlCommand.ExecuteNonQuery()
   at NHibernate.AdoNet.AbstractBatcher.ExecuteNonQuery(IDbCommand cmd)
   at NHibernate.AdoNet.NonBatchingBatcher.AddToBatch(IExpectation expectation)
   at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object[] fields, Boolean[] notNull, Int32 j, SqlCommandInfo sql, Object obj, ISessionImplementor session)
   at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object[] fields, Object obj, ISessionImplementor session)
   at NHibernate.Action.EntityInsertAction.Execute()
   at NHibernate.Engine.ActionQueue.Execute(IExecutable executable)
   at NHibernate.Engine.ActionQueue.ExecuteActions(IList list)
   at NHibernate.Engine.ActionQueue.ExecuteActions()
   at NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource session)
   at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
   at NHibernate.Impl.SessionImpl.Flush()
   at NHibernate.Transaction.AdoTransaction.Commit()

Upvotes: 1

Views: 2170

Answers (2)

Francisco Junior
Francisco Junior

Reputation: 2016

This seems to be a bug inside Npgsql.

According to the stacktrace (and checking Npgsql code: https://github.com/npgsql/Npgsql/blob/master/src/Npgsql/NpgsqlDataReader.cs#L1163), when an error occurs inside the GetNextResponseObject(), Npgsql sends a Sync message to server to reset the conversation to a consistent state. The problem is that when this error occurs, some data may have been left in the stream and when Npgsql tries to write to it, the buffered stream checks if there is data yet and, while flushing the data, tries to call seek which isn't supported by a network stream ( over which the buffered stream is created ).

A possible fix for this bug is to flush the buffered stream from any possible data left before writing to it.

I'll create a pull request with this change.

The biggest problem is that this type or error is very rare, as you noticed. This error occurred only once for you. I'll need to investigate more what have caused the exception to be thrown in the first place.

I hope it helps.

Upvotes: 0

Daniel Schilling
Daniel Schilling

Reputation: 4977

Since the stack trace originates from NHibernate.Transaction.AdoTransaction.Commit, that means this error was probably logged by NHibernate itself. Your application must do its own logging so that you can have...

  • details for errors that occur outside of NHibernate
  • better context for errors that bubble up from NHibernate, like the one you've encountered

See "log all unhandled application errors" and "exception handling should never hide issues" for help on implementing this type of logging.

Without more information about the code that generated this error, this will be nearly impossible to fix. Fixing the logging and exception handling code needs to be one of the top priorities when working with a new code base in order to actually have a fighting chance to fix bugs and improve the code.

Upvotes: 3

Related Questions