|
| Re: [CDO/Net4j]java.nio.BufferUnderflowException [message #426866 is a reply to message #426808] |
Thu, 22 January 2009 20:10   |
|
David,
That sounds scary! And I have no clue where it comes from. I have
absolutely no experience with 64 bit Java and I hope that others can
jump in.
Even if you were able to come up with a test case that reliantly
reproduces this behaviour in a clean room module test I'd have my
problems to even execute it ;-(
For the 32 bit world I can say that this exception never popped up since
the acient times of Net4j. That makes me think that it's not caused by a
bug in Net4j.
Cheers
/Eike
----
http://thegordian.blogspot.com
David Bonneau schrieb:
> Hi all
>
> I have cdo code which works fine under a 32bit vista installation. To
> be able to use a larger amount of the memory I try it on a x86 64 bits
> linux install. And now after 5 minutes, 10 minutes, 3 hours, ... it
> depends, I have the following exception :
>
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:480)
> at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:529 )
> at
> org.eclipse.net4j.signal.SignalProtocol.handleBuffer(SignalP rotocol.java:215)
>
> at org.eclipse.spi.net4j.Channel$ReceiverWork.run(Channel.java: 305)
> at
> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:26)
> at
> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:1)
> at
> org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWork er.java:64)
> at
> org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Wo rker.java:154)
>
>
> I'm running with a 64 bits eclipse (3.4.1) and a 64 bits jvm (1.6.0_10).
>
> I try to google this kind of exception (a 64 bits jvm bug ?) but I
> find nothing. I would like to know if someone have already encouter
> the same problem ?
>
> David
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO/Net4j]java.nio.BufferUnderflowException [message #426880 is a reply to message #426866] |
Fri, 23 January 2009 09:45 |
 Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Eike ,
I'm having the same issue on a 32 bit Linux environment, that would mean it's not 64bits/32bits related problem.
That said, I'm trying to understand what could link to that. We're using our own Backend (the same as David), could this issue be related with a backend issue ? I mean, if my backend breaks in some way (throw an Exception or something..), could this cause this exception ?
Another hint : if I tune the backend so that it get's slower (save more frequently), then I don't have the bug anymore.. Could that mean that Net4J has an issue which is revealed under big stress ?
Any input on this Eike ?
Cédric
Eike Stepper wrote:
> David,
>
> That sounds scary! And I have no clue where it comes from. I have
> absolutely no experience with 64 bit Java and I hope that others can
> jump in.
> Even if you were able to come up with a test case that reliantly
> reproduces this behaviour in a clean room module test I'd have my
> problems to even execute it ;-(
> For the 32 bit world I can say that this exception never popped up since
> the acient times of Net4j. That makes me think that it's not caused by a
> bug in Net4j.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> David Bonneau schrieb:
>> Hi all
>>
>> I have cdo code which works fine under a 32bit vista installation. To
>> be able to use a larger amount of the memory I try it on a x86 64 bits
>> linux install. And now after 5 minutes, 10 minutes, 3 hours, ... it
>> depends, I have the following exception :
>>
>> java.nio.BufferUnderflowException
>> at java.nio.Buffer.nextGetIndex(Buffer.java:480)
>> at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:529 )
>> at
>> org.eclipse.net4j.signal.SignalProtocol.handleBuffer(SignalP rotocol.java:215)
>>
>> at org.eclipse.spi.net4j.Channel$ReceiverWork.run(Channel.java: 305)
>> at
>> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:26)
>> at
>> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:1)
>> at
>> org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWork er.java:64)
>> at
>> org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Wo rker.java:154)
>>
>>
>> I'm running with a 64 bits eclipse (3.4.1) and a 64 bits jvm (1.6.0_10).
>>
>> I try to google this kind of exception (a 64 bits jvm bug ?) but I
>> find nothing. I would like to know if someone have already encouter
>> the same problem ?
>>
>> David
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: [CDO/Net4j]java.nio.BufferUnderflowException [message #426882 is a reply to message #426880] |
Fri, 23 January 2009 09:58 |
|
Cédric,
Could be a linux problem then. But I also can't exclude that we have a bug in Net4j. It would help me a lot if I were able to reproduce this exception.
If you can't come up with a unit test case for this purpose I'd need at least a complete console log with full tracing enabled. Note that the trace option org.eclipse.net4j/debug.buffer.stream is off by default. Please consider setting it to true.
Does it only happen on the server?
Cheers
/Eike
----
http://thegordian.blogspot.com
Cédric Brun schrieb:
> Hi Eike ,
>
> I'm having the same issue on a 32 bit Linux environment, that would mean it's not 64bits/32bits related problem.
>
> That said, I'm trying to understand what could link to that. We're using our own Backend (the same as David), could this issue be related with a backend issue ? I mean, if my backend breaks in some way (throw an Exception or something..), could this cause this exception ?
>
> Another hint : if I tune the backend so that it get's slower (save more frequently), then I don't have the bug anymore.. Could that mean that Net4J has an issue which is revealed under big stress ?
>
> Any input on this Eike ?
>
> Cédric
>
>
>
> Eike Stepper wrote:
>
>
>> David,
>>
>> That sounds scary! And I have no clue where it comes from. I have
>> absolutely no experience with 64 bit Java and I hope that others can
>> jump in.
>> Even if you were able to come up with a test case that reliantly
>> reproduces this behaviour in a clean room module test I'd have my
>> problems to even execute it ;-(
>> For the 32 bit world I can say that this exception never popped up since
>> the acient times of Net4j. That makes me think that it's not caused by a
>> bug in Net4j.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> David Bonneau schrieb:
>>
>>> Hi all
>>>
>>> I have cdo code which works fine under a 32bit vista installation. To
>>> be able to use a larger amount of the memory I try it on a x86 64 bits
>>> linux install. And now after 5 minutes, 10 minutes, 3 hours, ... it
>>> depends, I have the following exception :
>>>
>>> java.nio.BufferUnderflowException
>>> at java.nio.Buffer.nextGetIndex(Buffer.java:480)
>>> at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:529 )
>>> at
>>> org.eclipse.net4j.signal.SignalProtocol.handleBuffer(SignalP rotocol.java:215)
>>>
>>> at org.eclipse.spi.net4j.Channel$ReceiverWork.run(Channel.java: 305)
>>> at
>>> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:26)
>>> at
>>> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:1)
>>> at
>>> org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWork er.java:64)
>>> at
>>> org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Wo rker.java:154)
>>>
>>>
>>> I'm running with a 64 bits eclipse (3.4.1) and a 64 bits jvm (1.6.0_10).
>>>
>>> I try to google this kind of exception (a 64 bits jvm bug ?) but I
>>> find nothing. I would like to know if someone have already encouter
>>> the same problem ?
>>>
>>> David
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03298 seconds
] 
Search
Help
Register
Login
Home
