db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sin(EaTing)," <uss...@gmail.com>
Subject Re: org.apache.derby.client.am.DisconnectException from Derby 10.1
Date Sat, 07 Jun 2008 03:54:10 GMT
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), <ussraf@gmail.com> 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 <Kristian.Waagan@sun.com>
> 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!
>>>
>>>
>>
>

Mime
View raw message