> The odd thing about this is that once it was stuck in a read during an
> internalExecute. But what is really crazy is that another time it was
> stuck in a socket read while our connection pool was initializing and
> the driver was attempting to get a connection handle from the server.
> It was just stuck in the socket read with nothing happening. This
> caused all other threads looking for connections to block on the JDBC
> Connection monitor.

I know about three possibilities of blocking in socket read:

- network error, when no connection exists, though OS believes it is not
broken; an example of such is removing a network cable between two hubs that
connect together client and server (at least that was possible two years
ago)

- bug in Jaybird wire protocol implementation. Unlikely, but still possible.
The easiest way to check if that's the case - use the JNI connection (either
NATIVE or LOCAL) to the same server;

- lock conflict (the most common source of errors). The most common source
of issues. Firebird server waits for a lock conflict resolution. You can
change the timeout in firebird.conf.

Hope this helps.

Roman