java.sql.SQLException: JZ006: Caught IOException: java.io.IOException: JZ0EM: End of data

[Julie Sher]

Can someone explain what this is and how to fix it? It seems to happen when
trying to close a connection. Relevant stack trace follows:

java.sql.SQLException: JZ006: Caught IOException: java.io.IOException:
JZ0EM: End of data.
at com.sybase.jdbc2.jdbc.ErrorMessage.raiseError(ErrorMessage.java:485)
at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3064)
at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:1876)
at com.sybase.jdbc2.tds.Tds.logout(Tds.java:617)
at com.sybase.jdbc2.jdbc.SybConnection.close(SybConnection.java:739)
at fluximpl.database.JdbcPool.refreshConnections(JdbcPool.java)
at fluximpl.database.JdbcPool$ConnectionSweeper.run(JdbcPool.java)
SQLException: SQLState(JZ006)

[Joseph Weinstein]

Julie Sher wrote:

I'm going to guess it's one of two things. Either the version of the driver
is out-of-sync with the version of the DBMS, or perhaps the connection
was already closed. JDBC does not specify what behavior to expect when
one closes an already-closed connection. Connection.isClosed() is specifically
for telling whether Connection.close() has already been called, so you can try that.
Beware, though, that I have seen some versions of the Sybase driver that
ims-implement this call to actyuall check on the state of the client-DBMS link,
which is useful for some, but against the spec.

Joe Weinstein at BEA

[Jay_Anderson]

I think that you are just seeing a normal exception which is caught by
Sybase close connection method due to the way you are analyzing the
exception data.

When Sybase wants to close the connection it will begin a logout process
with the dataserver. A token is sent to the server, and the server sends a
reply token and disconnects the socket from its end. If the race condition
is such that the disconnect event beats the logout token reply back to
jConnect (and this happens very often), then the exception will be thrown
by Jave network io. The exception should be caught by the sybase close
methods and not visable unless tracing of some sort is enabled.

[Tim]

I too get this error. Happens very frequently in various
scenarios--closing a connection, deleting a temp db table, running other
execute updates. While I can catch and retry it greatly diminishes
performance. ANY help would be greatly appreciated.

Sybase 11.9.2
JConnect 5.5
Error State: JZ006
Error Code: 0

Example of the error

java.sql.SQLException: JZ006: Caught IOException: java.io.IOException:
JZ0EM: End of data.
at com.sybase.jdbc2.jdbc.ErrorMessage.raiseError

(ErrorMessage.java:487)
at
com.sybase.jdbc2.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:723)
at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3071)
at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:1876)
at
com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69)
at
com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:204)
at
com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:187)
at
com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1615)
at
com.sybase.jdbc2.jdbc.SybStatement.executeUpdate(SybStatement.java:1598)
at
com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate(SybPreparedStatement.java:89)

[Joseph Weinstein]

Tim wrote:

> I too get this error. Happens very frequently in various
> scenarios--closing a connection, deleting a temp db table, running other
> execute updates. While I can catch and retry it greatly diminishes
> performance. ANY help would be greatly appreciated.

My first guess is that your code is closing the connection out from under
some other part of your code. Is this in a servlet etc?
Joe Weinstein at BEA

[Tim]

No, this is a standalone application. I do use a connection pool of 8-32
connections. I have looked at the possibility that I have an issue where
one thread is closing the wrong connection. However, wouldn't you expect
to see error state JZ0C0--connection already closed? The majority of times
I see this error is deleting tables in the tempdb.

[Joseph Weinstein]

Tim wrote:

> No, this is a standalone application. I do use a connection pool of 8-32
> connections. I have looked at the possibility that I have an issue where
> one thread is closing the wrong connection. However, wouldn't you expect
> to see error state JZ0C0--connection already closed?

No. The JDBC spec is purposely unspecified as to behavior of JDBC objects
if used after they've been closed. If the connection is closed, all it's statements
and their result sets become defunct, and anyone using one of those subobjects
is liable for any sort of odd behavior. You could make s simple pass-thru wrapper
of a JDBC driver that mostly just uses the sybase driver and passes things back and forth,
but just add a check before each method to see if the connection had been closed yet.
You would also have to catch any exception coming back from any call, and do a check
then too, because if the connection is closed while you are waiting for a ResultSet
call to return etc, then the exception you receive will be because the connection
was closed while you were waiting for a response...
Joe Weinstein at BEA

[mitch....@wellsfargo.com]

We have experienced the same problem. It appears to be a time-out issue on
the SQL server side. We trap the error and restart our java server-side
app via a Kornshell script. We are trying to associate the issue with
either Sybase backups or UNIX server backups.

[Julie Sher]

The combination to have this behavior is physically closing a Connection
while debugging is turned ON.
The way it's explained to us, this happens because it's very hard to really
know whether data transmission between the server and JDBC is really really
done. So when we physically close a connection, jConnect just drops
everything. If there's any chance of unfinished data transmission, an End of
data exception is declared. Usually this exception is caught inside jConnect
and not revealed. And since you usually don't really care when you close a
connection, it should be okay. However, if you turn on debugging, the
jConnect debugging will then forward this upward.

In our case, the physical closing of the Connection happens when we
periodically close and refresh the connection to maintain a pool of healthy
connections. When we set WebLogic logging level to debug, the exceptions
start to pop up in the log.

Sybase tech support says this is not harmful.

<mitch....@wellsfargo.com> wrote in message
news:6EA770AA2284136F004B1A7485256CDF.0077D58485256CC6@webforums...

[J]

On Fri, 7 Mar 2003 16:03:24 -0500, "Julie Sher" <hig...@onebox.com>
wrote:

A slight correction but you have it essentially correct. The error can
be ignored. It's a little more that the server drops the connection
when it is told a client is logging out vs jConnect dropping
everything.

When jconnect closes a connection, it sends a token to the server to
logout. The server sends a token back and then drops its end of the
socket. This orderly termination prevents "disconnected spid"
messages from filling server logs.

Now very often the disconnect of the socket beats the logout token
response back to the jconnect client. There is a socket exception
thrown but the jconnect code knows it is closing and does not
propagate the error up. This is normal behavior.

J