Home » Modeling » EMF » CDO: strange OOME on server
| CDO: strange OOME on server [message #427689] |
Thu, 26 February 2009 15:41  |
 Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hi,
I have a very strange phenomenon, maybe someone has an idea?
I have two PCs, one with XP 32-bit, one with Vista 32-bit.
Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
The application uses an HSQLDB backed CDO server which runs in the same
VM as the client using the JVM connector.
The application reads a lot of objects, calculates something and then
creates some other objects which also generates bidirectional
associations to existing objects (so nothing really special here, I have
a bunch of Objects A1, A2, A3, ... An, and the process then generates a
few other Objects B1, B2, ... where B1.reference1 = A1, B1.reference2 =
A4, etc.).
On both PCs I am rumming with -Xmx1024m
The thing is that on Windows XP everything runs fine. Only on Vista I
get an OOME when committing:
!ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at java.util.ArrayList.<init>(Unknown Source)
at org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
at org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
at org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
at org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
at org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
at org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
at org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The even stranger thing is that the OOME occurs no matter if I
create/change 500 or only 50 objects before committing.
Are there any known issues that Java memory handling is different
between Vista and XP?
*puzzled*
Stefan
|
|
|
| Re: CDO: strange OOME on server [message #427690 is a reply to message #427689] |
Thu, 26 February 2009 15:52  |
|
Stefan,
Can you dump the initailCapacity that that is going to be allocated for
the list in both cases?
Cheers
/Eike
----
http://thegordian.blogspot.com
Stefan Winkler schrieb:
> Hi,
>
> I have a very strange phenomenon, maybe someone has an idea?
>
> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>
> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
> The application uses an HSQLDB backed CDO server which runs in the same
> VM as the client using the JVM connector.
>
> The application reads a lot of objects, calculates something and then
> creates some other objects which also generates bidirectional
> associations to existing objects (so nothing really special here, I have
> a bunch of Objects A1, A2, A3, ... An, and the process then generates a
> few other Objects B1, B2, ... where B1.reference1 = A1, B1.reference2 =
> A4, etc.).
>
> On both PCs I am rumming with -Xmx1024m
>
> The thing is that on Windows XP everything runs fine. Only on Vista I
> get an OOME when committing:
>
> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
> !MESSAGE Java heap space
> !STACK 0
> java.lang.OutOfMemoryError: Java heap space
> at java.util.ArrayList.<init>(Unknown Source)
> at org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
> at org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
> at org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
> at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
> at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
> at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
> at org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
> at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
> at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
> at org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
> at org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
> at org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
> at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
> The even stranger thing is that the OOME occurs no matter if I
> create/change 500 or only 50 objects before committing.
>
> Are there any known issues that Java memory handling is different
> between Vista and XP?
>
> *puzzled*
> Stefan
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO: strange OOME on server [message #427712 is a reply to message #427690] |
Fri, 27 February 2009 09:04 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Eike,
your suspicion was correct:
> Can you dump the initailCapacity that that is going to be allocated
> for the list in both cases?
This is the dump of the first commit -- the first line of the console is
a debug message from my application (which shows that we are using the
same data).
My machine (XP):
[...]
WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
createList(0, 0, 0)
createList(102, 102, 102)
createList(2, 2, 2)
createList(0, 0, 0)
createList(2, 2, 2)
createList(0, 0, 0)
createList(2, 2, 2)
createList(0, 0, 0)
createList(2, 2, 2)
createList(0, 0, 0)
createList(2, 2, 2)
createList(0, 0, 0)
createList(2, 2, 2)
createList(0, 0, 0)
[...]
Student's machine (Vista):
[...]
WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
createList(0, 0, 0)
createList(102, 102, 102)
createList(2, 2, 2)
createList(1071335894, 1071335894, 1071335894)
[ERROR] Java heap space
java.lang.OutOfMemoryError: Java heap space
[...]
So, yes, the initialCapacity on the vista machine does not make sense.
But why-oh-why?
Cheers,
Stefan
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Stefan Winkler schrieb:
>> Hi,
>>
>> I have a very strange phenomenon, maybe someone has an idea?
>>
>> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>>
>> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
>> The application uses an HSQLDB backed CDO server which runs in the same
>> VM as the client using the JVM connector.
>>
>> The application reads a lot of objects, calculates something and then
>> creates some other objects which also generates bidirectional
>> associations to existing objects (so nothing really special here, I have
>> a bunch of Objects A1, A2, A3, ... An, and the process then generates a
>> few other Objects B1, B2, ... where B1.reference1 = A1, B1.reference2 =
>> A4, etc.).
>>
>> On both PCs I am rumming with -Xmx1024m
>>
>> The thing is that on Windows XP everything runs fine. Only on Vista I
>> get an OOME when committing:
>>
>> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
>> !MESSAGE Java heap space
>> !STACK 0
>> java.lang.OutOfMemoryError: Java heap space
>> at java.util.ArrayList.<init>(Unknown Source)
>> at
>> org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
>>
>> at
>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
>>
>> at
>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
>>
>> at
>> org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
>>
>> at
>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>
>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>> Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>> Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>> The even stranger thing is that the OOME occurs no matter if I
>> create/change 500 or only 50 objects before committing.
>>
>> Are there any known issues that Java memory handling is different
>> between Vista and XP?
>>
>> *puzzled*
>> Stefan
>>
|
|
|
| Re: CDO: strange OOME on server [message #427713 is a reply to message #427712] |
Fri, 27 February 2009 09:26 |
|
Stefan,
Well, it seems as if the buffer contents or their interpretation are not
in sync with the expectations. This can generally have two reasons:
1) The application protocol implementation (here: CDO) is buggy, i.e.
the receiver logic does not match the sender logic.
2) The Net4j framework implementation is buggy
Both are not impossible. I suggest that you file a bugzilla. Is your
problem reliantly reproducible?
Cheers
/Eike
----
http://thegordian.blogspot.com
Stefan Winkler schrieb:
> Eike,
>
> your suspicion was correct:
>
>> Can you dump the initailCapacity that that is going to be allocated
>> for the list in both cases?
>>
> This is the dump of the first commit -- the first line of the console is
> a debug message from my application (which shows that we are using the
> same data).
>
> My machine (XP):
>
> [...]
> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
> createList(0, 0, 0)
> createList(102, 102, 102)
> createList(2, 2, 2)
> createList(0, 0, 0)
> createList(2, 2, 2)
> createList(0, 0, 0)
> createList(2, 2, 2)
> createList(0, 0, 0)
> createList(2, 2, 2)
> createList(0, 0, 0)
> createList(2, 2, 2)
> createList(0, 0, 0)
> createList(2, 2, 2)
> createList(0, 0, 0)
> [...]
>
>
> Student's machine (Vista):
>
> [...]
> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
> createList(0, 0, 0)
> createList(102, 102, 102)
> createList(2, 2, 2)
> createList(1071335894, 1071335894, 1071335894)
> [ERROR] Java heap space
> java.lang.OutOfMemoryError: Java heap space
> [...]
>
>
> So, yes, the initialCapacity on the vista machine does not make sense.
> But why-oh-why?
>
> Cheers,
> Stefan
>
>
>
>
>
>
>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Stefan Winkler schrieb:
>>
>>> Hi,
>>>
>>> I have a very strange phenomenon, maybe someone has an idea?
>>>
>>> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>>>
>>> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
>>> The application uses an HSQLDB backed CDO server which runs in the same
>>> VM as the client using the JVM connector.
>>>
>>> The application reads a lot of objects, calculates something and then
>>> creates some other objects which also generates bidirectional
>>> associations to existing objects (so nothing really special here, I have
>>> a bunch of Objects A1, A2, A3, ... An, and the process then generates a
>>> few other Objects B1, B2, ... where B1.reference1 = A1, B1.reference2 =
>>> A4, etc.).
>>>
>>> On both PCs I am rumming with -Xmx1024m
>>>
>>> The thing is that on Windows XP everything runs fine. Only on Vista I
>>> get an OOME when committing:
>>>
>>> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
>>> !MESSAGE Java heap space
>>> !STACK 0
>>> java.lang.OutOfMemoryError: Java heap space
>>> at java.util.ArrayList.<init>(Unknown Source)
>>> at
>>> org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
>>>
>>> at
>>> org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>> Source)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>> Source)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>>
>>> The even stranger thing is that the OOME occurs no matter if I
>>> create/change 500 or only 50 objects before committing.
>>>
>>> Are there any known issues that Java memory handling is different
>>> between Vista and XP?
>>>
>>> *puzzled*
>>> Stefan
>>>
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO: strange OOME on server [message #427717 is a reply to message #427713] |
Fri, 27 February 2009 12:02 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
The third explanation is the plugins doesn't match (same version) at the
client and server. We encounter that problem before.
If at the client you are using cdo.20090211.... and on the server
cdo.2009.0115.... The protocol could have changed... so both the server
and client are not in sync.
> Stefan,
> Well, it seems as if the buffer contents or their interpretation are not
> in sync with the expectations. This can generally have two reasons:
> 1) The application protocol implementation (here: CDO) is buggy, i.e.
> the receiver logic does not match the sender logic.
> 2) The Net4j framework implementation is buggy
> Both are not impossible. I suggest that you file a bugzilla. Is your
> problem reliantly reproducible?
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
> Stefan Winkler schrieb:
>> Eike,
>>
>> your suspicion was correct:
>>
>>> Can you dump the initailCapacity that that is going to be allocated
>>> for the list in both cases?
>>>
>> This is the dump of the first commit -- the first line of the console is
>> a debug message from my application (which shows that we are using the
>> same data).
>>
>> My machine (XP):
>>
>> [...]
>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>> createList(0, 0, 0)
>> createList(102, 102, 102)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> [...]
>>
>>
>> Student's machine (Vista):
>>
>> [...]
>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>> createList(0, 0, 0)
>> createList(102, 102, 102)
>> createList(2, 2, 2)
>> createList(1071335894, 1071335894, 1071335894)
>> [ERROR] Java heap space
>> java.lang.OutOfMemoryError: Java heap space
>> [...]
>>
>>
>> So, yes, the initialCapacity on the vista machine does not make sense.
>> But why-oh-why?
>>
>> Cheers,
>> Stefan
>>
>>
>>
>>
>>
>>
>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
>>>
>>> Stefan Winkler schrieb:
>>>
>>>> Hi,
>>>>
>>>> I have a very strange phenomenon, maybe someone has an idea?
>>>>
>>>> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>>>>
>>>> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
>>>> The application uses an HSQLDB backed CDO server which runs in the same
>>>> VM as the client using the JVM connector.
>>>>
>>>> The application reads a lot of objects, calculates something and then
>>>> creates some other objects which also generates bidirectional
>>>> associations to existing objects (so nothing really special here, I have
>>>> a bunch of Objects A1, A2, A3, ... An, and the process then generates a
>>>> few other Objects B1, B2, ... where B1.reference1 = A1, B1.reference2 =
>>>> A4, etc.).
>>>>
>>>> On both PCs I am rumming with -Xmx1024m
>>>>
>>>> The thing is that on Windows XP everything runs fine. Only on Vista I
>>>> get an OOME when committing:
>>>>
>>>> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
>>>> !MESSAGE Java heap space
>>>> !STACK 0
>>>> java.lang.OutOfMemoryError: Java heap space
>>>> at java.util.ArrayList.<init>(Unknown Source)
>>>> at
>>>>
org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
>>>>
>>>> at
>>>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
>>>>
>>>> at
>>>>
org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>>
>>>> at
>>>>
org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>>
>>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
>>>> at
>>>>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>>
>>>> at
>>>>
org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>>
>>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>>> Source)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>> Source)
>>>> at java.lang.Thread.run(Unknown Source)
>>>>
>>>>
>>>> The even stranger thing is that the OOME occurs no matter if I
>>>> create/change 500 or only 50 objects before committing.
>>>>
>>>> Are there any known issues that Java memory handling is different
>>>> between Vista and XP?
>>>>
>>>> *puzzled*
>>>> Stefan
>>>>
>>>>
|
|
|
| Re: CDO: strange OOME on server [message #427718 is a reply to message #427717] |
Fri, 27 February 2009 12:06 |
|
Simon,
Darn, you're right. I forgot about this potential reason. What ccould we
do to automatically ensure deployment consistency at runtime?
Cheers
/Eike
----
http://thegordian.blogspot.com
Simon Mc Duff schrieb:
> The third explanation is the plugins doesn't match (same version) at
> the client and server. We encounter that problem before.
>
> If at the client you are using cdo.20090211.... and on the server
> cdo.2009.0115.... The protocol could have changed... so both the
> server and client are not in sync.
>
>
>> Stefan,
>
>> Well, it seems as if the buffer contents or their interpretation are
>> not in sync with the expectations. This can generally have two reasons:
>
>> 1) The application protocol implementation (here: CDO) is buggy, i.e.
>> the receiver logic does not match the sender logic.
>> 2) The Net4j framework implementation is buggy
>
>> Both are not impossible. I suggest that you file a bugzilla. Is your
>> problem reliantly reproducible?
>
>> Cheers
>> /Eike
>
>> ----
>> http://thegordian.blogspot.com
>
>
>
>> Stefan Winkler schrieb:
>>> Eike,
>>>
>>> your suspicion was correct:
>>>
>>>> Can you dump the initailCapacity that that is going to be allocated
>>>> for the list in both cases?
>>>>
>>> This is the dump of the first commit -- the first line of the
>>> console is
>>> a debug message from my application (which shows that we are using the
>>> same data).
>>>
>>> My machine (XP):
>>>
>>> [...]
>>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>>> createList(0, 0, 0)
>>> createList(102, 102, 102)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> [...]
>>>
>>>
>>> Student's machine (Vista):
>>>
>>> [...]
>>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>>> createList(0, 0, 0)
>>> createList(102, 102, 102)
>>> createList(2, 2, 2)
>>> createList(1071335894, 1071335894, 1071335894)
>>> [ERROR] Java heap space
>>> java.lang.OutOfMemoryError: Java heap space
>>> [...]
>>>
>>>
>>> So, yes, the initialCapacity on the vista machine does not make sense.
>>> But why-oh-why?
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
>>>>
>>>>
>>>> Stefan Winkler schrieb:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a very strange phenomenon, maybe someone has an idea?
>>>>>
>>>>> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>>>>>
>>>>> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
>>>>> The application uses an HSQLDB backed CDO server which runs in the
>>>>> same
>>>>> VM as the client using the JVM connector.
>>>>>
>>>>> The application reads a lot of objects, calculates something and then
>>>>> creates some other objects which also generates bidirectional
>>>>> associations to existing objects (so nothing really special here,
>>>>> I have
>>>>> a bunch of Objects A1, A2, A3, ... An, and the process then
>>>>> generates a
>>>>> few other Objects B1, B2, ... where B1.reference1 = A1,
>>>>> B1.reference2 =
>>>>> A4, etc.).
>>>>>
>>>>> On both PCs I am rumming with -Xmx1024m
>>>>>
>>>>> The thing is that on Windows XP everything runs fine. Only on Vista I
>>>>> get an OOME when committing:
>>>>>
>>>>> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
>>>>> !MESSAGE Java heap space
>>>>> !STACK 0
>>>>> java.lang.OutOfMemoryError: Java heap space
>>>>> at java.util.ArrayList.<init>(Unknown Source)
>>>>> at
>>>>>
> org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>
>>>>>
>>>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
>>>>> at
>>>>>
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>
>>>>>
>>>>> at
>>>>>
> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>
>>>>>
>>>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>>>> Source)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>>> Source)
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>> The even stranger thing is that the OOME occurs no matter if I
>>>>> create/change 500 or only 50 objects before committing.
>>>>>
>>>>> Are there any known issues that Java memory handling is different
>>>>> between Vista and XP?
>>>>>
>>>>> *puzzled*
>>>>> Stefan
>>>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: CDO: strange OOME on server [message #427720 is a reply to message #427713] |
Fri, 27 February 2009 13:56 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Eike,
> Well, it seems as if the buffer contents or their interpretation are
> not in sync with the expectations. This can generally have two reasons:
>
> 1) The application protocol implementation (here: CDO) is buggy, i.e.
> the receiver logic does not match the sender logic.
> 2) The Net4j framework implementation is buggy
>
> Both are not impossible. I suggest that you file a bugzilla. Is your
> problem reliantly reproducible?
Could it be some form of race condition / synchronization problem?
-> The student has a dualcore CPU - I only have an old single-core one :-(
The problem is that
- yes, the bug always comes up with the same commit
- but the student is able to do a successful commit incorporating
instances of another class in the same repository
- but I am not able to reproduce it here and consider the student to be
an offsite client ... We currently work around the problem using other
datasets where the problem seems to not come up ..
- I am on vacation for 3 weeks starting tomorrow :-(
I could file a bug but I could not come up with a testcase ...
Cheers,
Stefan
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Stefan Winkler schrieb:
>> Eike,
>>
>> your suspicion was correct:
>>
>>> Can you dump the initailCapacity that that is going to be allocated
>>> for the list in both cases?
>>>
>> This is the dump of the first commit -- the first line of the console is
>> a debug message from my application (which shows that we are using the
>> same data).
>>
>> My machine (XP):
>>
>> [...]
>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>> createList(0, 0, 0)
>> createList(102, 102, 102)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> createList(2, 2, 2)
>> createList(0, 0, 0)
>> [...]
>>
>>
>> Student's machine (Vista):
>>
>> [...]
>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>> createList(0, 0, 0)
>> createList(102, 102, 102)
>> createList(2, 2, 2)
>> createList(1071335894, 1071335894, 1071335894)
>> [ERROR] Java heap space
>> java.lang.OutOfMemoryError: Java heap space
>> [...]
>>
>>
>> So, yes, the initialCapacity on the vista machine does not make sense.
>> But why-oh-why?
>>
>> Cheers,
>> Stefan
>>
>>
>>
>>
>>
>>
>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
>>>
>>> Stefan Winkler schrieb:
>>>
>>>> Hi,
>>>>
>>>> I have a very strange phenomenon, maybe someone has an idea?
>>>>
>>>> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>>>>
>>>> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
>>>> The application uses an HSQLDB backed CDO server which runs in the
>>>> same
>>>> VM as the client using the JVM connector.
>>>>
>>>> The application reads a lot of objects, calculates something and then
>>>> creates some other objects which also generates bidirectional
>>>> associations to existing objects (so nothing really special here, I
>>>> have
>>>> a bunch of Objects A1, A2, A3, ... An, and the process then
>>>> generates a
>>>> few other Objects B1, B2, ... where B1.reference1 = A1,
>>>> B1.reference2 =
>>>> A4, etc.).
>>>>
>>>> On both PCs I am rumming with -Xmx1024m
>>>>
>>>> The thing is that on Windows XP everything runs fine. Only on Vista I
>>>> get an OOME when committing:
>>>>
>>>> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
>>>> !MESSAGE Java heap space
>>>> !STACK 0
>>>> java.lang.OutOfMemoryError: Java heap space
>>>> at java.util.ArrayList.<init>(Unknown Source)
>>>> at
>>>> org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>>
>>>>
>>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>>
>>>>
>>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>>> Source)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>> Source)
>>>> at java.lang.Thread.run(Unknown Source)
>>>>
>>>>
>>>> The even stranger thing is that the OOME occurs no matter if I
>>>> create/change 500 or only 50 objects before committing.
>>>>
>>>> Are there any known issues that Java memory handling is different
>>>> between Vista and XP?
>>>>
>>>> *puzzled*
>>>> Stefan
>>>>
|
|
|
| Re: CDO: strange OOME on server [message #427730 is a reply to message #427720] |
Fri, 27 February 2009 16:35 |
|
Stefan Winkler schrieb:
> Eike,
>
>> Well, it seems as if the buffer contents or their interpretation are
>> not in sync with the expectations. This can generally have two reasons:
>>
>> 1) The application protocol implementation (here: CDO) is buggy, i.e.
>> the receiver logic does not match the sender logic.
>> 2) The Net4j framework implementation is buggy
>>
>> Both are not impossible. I suggest that you file a bugzilla. Is your
>> problem reliantly reproducible?
>>
> Could it be some form of race condition / synchronization problem?
> -> The student has a dualcore CPU - I only have an old single-core one :-(
>
I have a quad-core :P
> The problem is that
> - yes, the bug always comes up with the same commit
>
Unlikely to be caused by some race condition.
> - but the student is able to do a successful commit incorporating
> instances of another class in the same repository
>
Very strange.
> - but I am not able to reproduce it here and consider the student to be
> an offsite client ... We currently work around the problem using other
> datasets where the problem seems to not come up ..
>
This indicates a problem in CDo rather than in Net4j.
But the only one with the potential to dig deeper seems to be your student.
Without being able to reproduce this problem, I really can't say much.
> - I am on vacation for 3 weeks starting tomorrow :-(
>
Well, you'll quickly forget about this hazzle :P
> I could file a bug but I could not come up with a testcase ...
>
Your student could and should.
Cheers
/Eike
----
http://thegordian.blogspot.com
> Cheers,
> Stefan
>
>
>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Stefan Winkler schrieb:
>>
>>> Eike,
>>>
>>> your suspicion was correct:
>>>
>>>
>>>> Can you dump the initailCapacity that that is going to be allocated
>>>> for the list in both cases?
>>>>
>>>>
>>> This is the dump of the first commit -- the first line of the console is
>>> a debug message from my application (which shows that we are using the
>>> same data).
>>>
>>> My machine (XP):
>>>
>>> [...]
>>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>>> createList(0, 0, 0)
>>> createList(102, 102, 102)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> createList(2, 2, 2)
>>> createList(0, 0, 0)
>>> [...]
>>>
>>>
>>> Student's machine (Vista):
>>>
>>> [...]
>>> WeightedLinkFactory.createLink(OID16, OID33, 0.28173618620580526, [])
>>> createList(0, 0, 0)
>>> createList(102, 102, 102)
>>> createList(2, 2, 2)
>>> createList(1071335894, 1071335894, 1071335894)
>>> [ERROR] Java heap space
>>> java.lang.OutOfMemoryError: Java heap space
>>> [...]
>>>
>>>
>>> So, yes, the initialCapacity on the vista machine does not make sense.
>>> But why-oh-why?
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
>>>>
>>>>
>>>> Stefan Winkler schrieb:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a very strange phenomenon, maybe someone has an idea?
>>>>>
>>>>> I have two PCs, one with XP 32-bit, one with Vista 32-bit.
>>>>>
>>>>> Both running Eclipse 3.4 and an EMF-CDO application which I wrote.
>>>>> The application uses an HSQLDB backed CDO server which runs in the
>>>>> same
>>>>> VM as the client using the JVM connector.
>>>>>
>>>>> The application reads a lot of objects, calculates something and then
>>>>> creates some other objects which also generates bidirectional
>>>>> associations to existing objects (so nothing really special here, I
>>>>> have
>>>>> a bunch of Objects A1, A2, A3, ... An, and the process then
>>>>> generates a
>>>>> few other Objects B1, B2, ... where B1.reference1 = A1,
>>>>> B1.reference2 =
>>>>> A4, etc.).
>>>>>
>>>>> On both PCs I am rumming with -Xmx1024m
>>>>>
>>>>> The thing is that on Windows XP everything runs fine. Only on Vista I
>>>>> get an OOME when committing:
>>>>>
>>>>> !ENTRY org.eclipse.net4j 4 0 2009-02-26 13:54:44.691
>>>>> !MESSAGE Java heap space
>>>>> !STACK 0
>>>>> java.lang.OutOfMemoryError: Java heap space
>>>>> at java.util.ArrayList.<init>(Unknown Source)
>>>>> at
>>>>> org.eclipse.net4j.util.collection.MoveableArrayList.<init>(MoveableArrayList.java:26)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.<init >(CDOListImpl.java:40)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl$1.c reateList(CDOListImpl.java:32)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOList(CDODataInputImpl.java:340)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. readValues(AbstractCDORevision.java:599)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:130)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:41)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.common.revision.CDORevisionUtil.read(CDO RevisionUtil.java:48)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevisionData(CDODataInputImpl.java:418)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:309)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:313)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:227 )
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:170 )
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>>>
>>>>>
>>>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317)
>>>>> at
>>>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>>>
>>>>>
>>>>> at
>>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>>>
>>>>>
>>>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>>>> Source)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>>> Source)
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>> The even stranger thing is that the OOME occurs no matter if I
>>>>> create/change 500 or only 50 objects before committing.
>>>>>
>>>>> Are there any known issues that Java memory handling is different
>>>>> between Vista and XP?
>>>>>
>>>>> *puzzled*
>>>>> Stefan
>>>>>
>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO: strange OOME on server [message #427731 is a reply to message #427719] |
Fri, 27 February 2009 16:37 |
|
Stefan Winkler schrieb:
> Simon,
>
> Simon Mc Duff schrieb:
>
>> The third explanation is the plugins doesn't match (same version) at
>> the client and server. We encounter that problem before.
>>
>> If at the client you are using cdo.20090211.... and on the server
>> cdo.2009.0115.... The protocol could have changed... so both the
>> server and client are not in sync.
>>
> But this can not happen with the JVM connector, as both client and
> server instances come from the same codebase, right?
>
Not right. CDO has an asynmmetrical protocol so, although unlikely, you
could mix up different versions of clien and server side, too. From a
Net4j point of view it plays o role that everything is in the same JVM.
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Wed Sep 25 14:51:06 GMT 2024
Powered by FUDForum. Page generated in 0.03234 seconds |
] 
Search
Help
Register
Login
Home
