I want to thank everyone for their help. We believe we've found the
problem. I suspect that our previous attempt to trace was corrupt (It
had about 350M of nulls at the end.) since the error sticks out like a
sore thumb.
I assume increasing the number of file handles will solve the problem.
Here's the relevant part of the trace:
[derby]
[net][time:1207921858092][thread:AWT-EventQueue-0][tracepoint:2][Reply.fill]
[derby] RECEIVE BUFFER: CMDCHKRM (ASCII)
(EBCDIC)
[derby] 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0123456789ABCDEF
[derby] 0000 0010D0520001000A 1254000611490080 ...R.....T...I..
..}.............
[derby]
[derby] RECEIVE BUFFER: SQLCARD (ASCII)
(EBCDIC)
[derby] 0000 0134D0030001012E 240800FFFFFFFF58 .4......$......X
..}.............
[derby] 0010 5344473343535331 3030333000000000 SDG3CSS10030....
................
[derby] 0020 0000000000000000 0000000000000000 ................
................
[derby] 0030 0000000000202020 2020202020202020 .....
................
[derby] 0040 000000ED4D657461 2D6461746120666F ....Meta-data fo
....(../.././..?
[derby] 0050 7220436F6E746169 6E6572206F72672E r Container org.
...?>./.>...?...
[derby] 0060 6170616368652E64 657262792E696D70 apache.derby.imp
/./........`.._.
[derby] 0070 6C2E73746F72652E 7261772E64617461 l.store.raw.data
%...?..../..././
[derby] 0080 2E524146436F6E74 61696E6572344066 [EMAIL PROTECTED]
.....?>./.>... .
[derby] 0090 313263353320636F 756C64206E6F7420 12c53 could not
.......?.%..>?..
[derby] 00A0 6265206163636573 7365643A3A53514C be accessed::SQL
.../...........<
[derby] 00B0 53544154453A2058 4A3030314A617661 STATE: XJ001Java
............././
[derby] 00C0 2065786365707469 6F6E3A20272F686F exception: '/ho
........?>.....?
[derby] 00D0 6D652F7064736572 7665722F50445365 me/pdserver/PDSe
_...........&...
[derby] 00E0 727665722F6F7269 6F6E44422F736567 rver/orionDB/seg
.....?..?>......
[derby] 00F0 302F636436312E64 61742028546F6F20 0/cd61.dat (Too
......../....??.
[derby] 0100 6D616E79206F7065 6E2066696C657329 many open files)
_/>`.?..>...%...
[derby] 0110 3A206A6176612E69 6F2E46696C654E6F : java.io.FileNo
..|/./..?...%.+?
[derby] 0120 74466F756E644578 63657074696F6E27 tFoundException'
..?.>........?>.
[derby] 0130 2E0000FF ....
....
[derby]
[derby] BEGIN TRACE_DIAGNOSTICS
[EMAIL PROTECTED] java.sql.SQLException
[EMAIL PROTECTED] SQL state = 08006
[EMAIL PROTECTED] Error code = 40000
[EMAIL PROTECTED] Message = A network protocol error was
encountered and the connection has been terminated: the requested
command encountered an unarchitected and implementation-specific
condition for which there was no architected message
[EMAIL PROTECTED] Stack trace follows
org.apache.derby.client.am.DisconnectException: A network protocol error
was encountered and the connection has been terminated: the requested
command encountered an unarchitected and implementation-specific
condition for which there was no architected message
at
org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConnectionReply.java:888)
at
org.apache.derby.client.net.NetStatementReply.parsePrepareError(NetStatementReply.java:527)
at
org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(NetStatementReply.java:143)
at
org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(NetStatementReply.java:52)
at
org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(StatementReply.java:40)
at
org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(NetStatement.java:139)
at
org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Statement.java:1341)
at
org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(PreparedStatement.java:1874)
at
org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(PreparedStatement.java:1952)
at
org.apache.derby.client.am.PreparedStatement.prepare(PreparedStatement.java:309)
at
org.apache.derby.client.am.Connection.prepareStatementX(Connection.java:1646)
at
org.apache.derby.client.am.Connection.prepareStatement(Connection.java:413)
[EMAIL PROTECTED] wrote:
Thanks you did exactly the right thing. I should have mentioned
getCause() as well. (Both are currently in use, I believe).
I agree with Bryan's conclusions in another email; this sounds like a
Derby bug.
Based on the call stack I'd say what you're seeing is a "meta
error" (for lack of a better word). I think that what is happening is
that the client sends a request to prepare a statement to the server,
but something goes wrong and an error is returned. As the client tries
to parse the reply it detects that an error has occured
(parsePrepareError(NetStatementReply.java:527)), but the error handling
appears not to be able to handle the returned error correctly, and so you
end up with a generic (and rather unhelpful) error message.
If my analysis is correct, you may get around this if you can guess or
trace what the root cause on the server is, and avoid it
altogether.
The best thing, obviously would be if you could come up with
a small(er) example which reproduces the problem, which you can share with
us (include in a Jira issue). Without being able to reproduce the
problem, it will be nearly impossible for someone else to fix it, I'm
afraid.
