Even more amazing!
This time I tried to totally upgrade my Derby to 10.4. Not only every disconnect exception is gone, but the speed gets EXTREMELY fast also!!!
My program used to take hours to finish a replication on Derby 10.1 and now it just takes minutes!!!
What did you do with 10.4? That's so cool !!!
It is reproducible. I've tested with your guide and this is the result
1. Remove a column: won't disconnect even the result is added up to 10000 rows
2. Add a column: disconnects less that 7966.
3. Add order by: OK! Won't disconnect now!
4. Using 10.4 derby client to connect, I did not replace the 'derbyclient.jar' at server side, still disconnect with the message:
ERROR 08006: Insufficient data while reading from the network - expected a minimum of 6 bytes and received only -1 bytes. The connection has been terminated.
I guess I need to make an update now. The reason I keep it is because I am using the Derby bundled with WebSphere 6.x.
Thanks!On Fri, Jun 6, 2008 at 8:13 PM, Kristian Waagan <Kristian.Waagan@sun.com> wrote:
I got a org.apache.derby.client.am.DisconnectException when using Derby 10.1
I just did something like
"select access_time, application, keyword, user_ip from log_request where access_time between timestamp('2007-10-01', '00:00:00') and timestamp('2007-10-28', '23:57:30')"
and got the disconnection.
The error message is like:
ERROR (no SQLState): A communication error has been detected. Communication protocol being used: Reply.fill(). Communication API being used: InputStream.read(). Location where the error was detected: insufficient data. Communication function detecting the error: *. Protocol specific error codes(s) TCP/IP SOCKETS
The returned rows should be above 7966 rows. If I try to restrict the constraints so that the return rows is below 7966 rows that is OK.
Any ideas about this?
Did this happen only once, or is it reproducible?
If it is reproducible, can you try the following:
1) Remove, or add, a column from/to the query (not the data!).
2) Add an order by.
This is purely guessing, I just want to rule out an off-by-one error that was fixed some time ago.
Another thing to try is using a newer *client*.
You should consider upgrading anyway, unless there are specific reasons why you are keeping the old version.