"Unknown packet type 0xffffff81" in SharedSocket.readPacket
Brought to you by:
ickzon
Menu
▾
▴
#402 "Unknown packet type 0xffffff81" in SharedSocket.readPacket
java.sql.SQLException: I/O Error: Unknown packet type
0xffffff81
at
net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2101)
at
net.sourceforge.jtds.jdbc.TdsCore.clearResponseQueue(TdsCore.java:674)
at
net.sourceforge.jtds.jdbc.JtdsStatement.close(JtdsStatement.java:580)
at
org.apache.commons.dbcp.DelegatingStatement.close(DelegatingStatement.java:165)
Logged In: YES
user_id=1080468
It might be added that this is after calling a stored
procedure. The stored procedure takes one integer parameter
(matching a primary key) and returns one resultset row
containing mainly integers and varchars.
Logged In: YES
user_id=1080468
Oh, i'm sorry! There's also this:
Caused by: java.io.IOException: Unknown packet type 0xffffff81
at
net.sourceforge.jtds.jdbc.SharedSocket.readPacket(SharedSocket.java:727)
at
net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:591)
at
net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:406)
at
net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:100)
at
net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:1996)
... 73 more
I'm thinking it might be related to bug 1120442 or bug 1086156?
Logged In: YES
user_id=564978
Could you also please provide a repro case? A simple (or not
so simple) Java class that reproduces the problem? I see the
error but I can't guess what's causing it; it's either some
packet type that's unknown to jTDS or some synchronization
issue inside jTDS. Alternately a log dump (produced by
enabling DriverManager logging) could also help.
BTW, what version of jTDS are you using? And do you have
more than one open Statement on the Connection at the same time?
Alin.
Logged In: YES
user_id=1080468
This error is from a customer. I just discovered that his
classpath contains both jtds-1.0.jar and jtds-1.0.2.jar, and
i'm not sure which one is used. I'll tell him to just use
jtds-1.0.3.jar. If that doesn't clear it up i'll make sure
to produce a log dump. I'm not sure i'll be able to provide
a repro case, but i'll do my best.
Thank you!
Logged In: YES
user_id=564978
Taking another look at this issue, it surely looks like the
duplicate of an older bug (the stack trace comes from a jTDS
1.0) caused by synchronization problems in
SharedSocket/TdsCore. Just to make sure, are you using more
than one Statement per Connection or calling cancel()?
(BTW, if this is the bug, it should be fixed in 1.0.3.)
Alin.
Logged In: YES
user_id=1080468
I don't think i'm using more than one statement per
connection, and i'm not calling cancel().
The customer previously told me that he had tried 1.0.3 and
had the same probem, but after seeing his classpath i'm not
so sure.
He's also had "Connection reset" errors in
SharedSocket.readPacket(), but i don't know if this is the
same bug, or if that was with the same version of jtds.
Once i know for sure which version we are dealing with, i'll
get back to you.
Perhaps we should close this bug, and open a new one if it
doesn't work with 1.0.3?
If you're interested, our bugzilla entry for this problem is
at http://bugzilla.imcode.com/show_bug.cgi?id=3191
Logged In: YES
user_id=564978
The "Connection reset" errors occur either if jTDS sends an
invalid protocol request and the server closes the
connection or if the connection times out. By looking at the
stack trace it looks like the former (and it looks like it's
a jTDS 1.0.3). But there's not much I can do if I can't
reproduce the issue or at least have a log dump.
Alin.
Logged In: YES
user_id=564978
Any updates on this? Have you found out if 1.0.3 was the
issue or an older version was causing the problems?
Alin.
Logged In: YES
user_id=1080468
Sorry, no updates yet. We've been very busy with other
things. I'll try to find out this week.
Logged In: YES
user_id=564978
Ok, I took a better look at this and the two stack traces
come from different releases of jTDS.
The first one (with the unknown packet type) was generated
by jTDS 1.0, which had some pretty serious concurrency
issues at the connection level. There was almost certainly
more than one statement open on that particular connection
at the moment the exception occured. With pooled connections
I think it's important to make sure you close all your
statements.
The second exception was thrown by 1.0.3 and seems to be
caused by a crash on the server side. Either that or an
invalid packet sent by jTDS but I haven't seen one of those
in a long while.
As a conclusion, I think it's safe to discard the first
error (as it has been fixed since 1.0) and pretty safe to
discard the second one (just look into the SQL Server log if
it appears again and there will probably be some evidence of
a crash -- unfortunately there's not much we can do about that).
Alin.
Alin.
Logged In: YES
user_id=1080468
It seems our client hasn't had any more problems with the
database since fixing the classpath, or at least i haven't
been told about them. Hopefully it was just temporary.
Thank you for your help!