You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by "sin(EaTing)," <us...@gmail.com> on 2008/06/06 13:58:13 UTC
org.apache.derby.client.am.DisconnectException from Derby 10.1
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?
Thanks!
Re: org.apache.derby.client.am.DisconnectException from Derby 10.1
Posted by Rick Hillegas <Ri...@Sun.COM>.
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), <ussraf@gmail.com
> <ma...@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 <ma...@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!
>
>
>
>
Re: org.apache.derby.client.am.DisconnectException from Derby 10.1
Posted by "sin(EaTing)," <us...@gmail.com>.
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), <us...@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 <Kr...@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!
>>>
>>>
>>
>
Re: org.apache.derby.client.am.DisconnectException from Derby 10.1
Posted by "sin(EaTing)," <us...@gmail.com>.
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 <Kr...@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!
>>
>>
>
Re: org.apache.derby.client.am.DisconnectException from Derby 10.1
Posted by Kristian Waagan <Kr...@Sun.COM>.
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!
>