A lot of work was put into improving Derby's performance and scalability
in releases 10.2, 10.3, and 10.4. Glad to hear that you're seeing the
benefit.
Regards,
-Rick
sin(EaTing), wrote:
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 !!!
On Sat, Jun 7, 2008 at 10:51 AM, sin(EaTing), <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
Really amazing!
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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
sin(EaTing), wrote:
Hi,
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?
Hello,
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.
regards,
--
Kristian
Thanks!
