I've had a BufferUnderflowException kill a DB Thread in a high performance application, with the following stack trace ('Caused by:' because this is after an explicit catch and log in the application):
Caused by: java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Buffer.java:497)
at java.nio.HeapByteBuffer.getInt(HeapByteBuffer.java:355)
at org.drizzle.jdbc.internal.common.packet.buffer.Reader.readInt(Reader.java:86)
at org.drizzle.jdbc.internal.mysql.packet.MySQLGreetingReadPacket.<init>(MySQLGreetingReadPacket.java:39)
at org.drizzle.jdbc.internal.mysql.MySQLProtocol.<init>(MySQLProtocol.java:153)
at org.drizzle.jdbc.DrizzleDriver.connect(DrizzleDriver.java:73
I'm guessing that the easiest way to solve it would be to catch the BufferUnderflowException at some point (Reader?) and re-throw it wraped in an IOException (so that that gets wrapped in a QueryException in MySQLProtocol).
It starts with the client connect()ing to the server which may send a ERR packet and finish the handshake or send a Initial Handshake Packet which the client answers with a Handshake Response Packet
So a proper fix would presumably require determining the type of packet first, and acting accordingly in the MySQLProtocol constructor.
I've had a BufferUnderflowException kill a DB Thread in a high performance application, with the following stack trace ('Caused by:' because this is after an explicit catch and log in the application):
This was caused by MySQL blocking the host.
I'm guessing that the easiest way to solve it would be to catch the BufferUnderflowException at some point (Reader?) and re-throw it wraped in an IOException (so that that gets wrapped in a QueryException in MySQLProtocol).
But, that first packet isn't required to be a MySQLGreetingReadPacket:
So a proper fix would presumably require determining the type of packet first, and acting accordingly in the MySQLProtocol constructor.