> 1. It's just a fact of life and dealing with it has been improved in V4
> > Including a number of changes to the transports
> > and handling of lost connections,
V4 may improve this, but it's very hard to protect against this general
sequence of events.
The reason why you are seeing the error at all is probably because it happens
when you execute a (possibly long running) query.
If the command over the (broken) socket would have been something like a
"Table.Next", it would very likely have already finished by the time the
transport reconnects and you wouldn't be seeing any follow up error at all
after getting the "connection lost" exception.
The danger here is that you don't know if the command has been executed or not
when you get a "connection lost". The connection might have been lost before
the command was fully transmited (so it never gets executed) or while waiting
for the reply returning the result of the command.
There is unfortunately no way how the transport code could differentiate
between these two.
> 2. There's something wrong with the customer's network infrastructure and
> they need to investigate.
I would say yes. The socket connections shouldn't be lost if the network was
operating correctly.
> 3. There's something wrong (with the customisation we've done) in the server
> and when there are a lot of users, the server is too busy to deal with all
> incoming requests in a timely fashion.
Unlikely. For the server to drop a connection on purpose, there must be 3
heartbeats missing. with the default of 10 seconds heartbeat interval, that
would be 30 seconds, and heartbeat processing in both client and server runs in
separate threads and is using additional socket connections if necessary, so
really nothing you have done should be able to interfer with it. Also, a
connection dropped because of missing heartbeats would also have canceled
processing for the session, so you would probably have recived an "invalid
handle" exception instead of an "illegal re-entered" one, as the session
wouldn't have existed server side anymore by the time the connection has been
re-established and the old session handle would have been invalid.