|
Re: [CDO] Weird race condition when committing [message #431472 is a reply to message #431467] |
Sat, 11 July 2009 15:09 |
|
Tobias,
Which CDO version are you using?
I worked on a similar issue a while back and I thought it was fixed...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Tobias Habermann schrieb:
> Hi,
>
> i am using CDO with the JVM connector to store large models in an HSQL
> database. I've been using it for a while now without any problems. But
> now I added an import option which loads a model from an .xmi file,
> copies it with EcoreUtil and inserts the copy into a CDO resource.
> This works fine most of the time, but there seems to be a race
> condition and in rare cases i get a "String id unknown" exception
> (stack trace attached below). The problem seems to be that the
> StringCompressor seems to map integer ids to package URIs, but for
> some reason instead of a valid integer value it gets something like
> 2049389 which is of course not mapped to any package.
> Now my CDO code is not really mature as I integrated it when it became
> apparent that the models would be to large to be handled within XMI or
> XML resources, so I cannot really tell if I'm doing something that
> causes the race condition. Is there a way to find out where the
> strange package uri value could come from to see if the error results
> from the way I am importing the model or if occurs at the commit?
>
> Regards,
> Tobias
>
>
> [ERROR] String ID unknown: 2507631
> java.io.IOException: String ID unknown: 2507631
> at
> org.eclipse.net4j.util.io.StringCompressor.read(StringCompre ssor.java:193)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageURI(CDODataInputImpl.java:124)
>
> at
> org.eclipse.emf.cdo.common.model.CDOClassifierRef.<init>(CDOClassifierRef.java:52)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOClassifierRef(CDODataInputImpl.java:129)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOClassifierRefAndResolve(CDODataInputImpl.java:134)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. <init>(AbstractCDORevision.java:116)
>
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:44)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:217)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:289)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:197 )
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:140 )
>
> 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:312)
> 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:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> 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)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: [CDO] Weird race condition when committing [message #431474 is a reply to message #431473] |
Sun, 12 July 2009 09:10 |
|
Tobias,
Race conditions are hard to debug and from looking at the code I can't
see a bug in StringCompressor. Can you help me a bit? To exclude that
the protocol got out-of-sequence you could set the static DEBUG flag to
true. Then the StringCompressor checks if received values are of the
expected type.
In a next step you could try to synchronize the whole read() and write()
methods in StringCompressor, although from looking at the code that
should not make a difference.
I added this test case:
org.eclipse.net4j.util.tests.StringCompressorTest. It uses string
compression for 500 random strings that are sent/received 10000 times
per test thread. There are different scenarios with different numbers of
threads and different transfer directions. They all pass.
I fear you have to provide a test case that reproduces your exception ;-(
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Tobias Habermann schrieb:
> Hello Eike,
>
> I am using CDO Model Repository SDK 2.0.0.v200906221520.
>
> Regards,
> Tobias
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: [CDO] Weird race condition when committing [message #431482 is a reply to message #431476] |
Mon, 13 July 2009 06:33 |
|
Tobias Habermann schrieb:
> Eike,
>
> Your test case runs fine for me too. I am beginning to think that the
> reason for this is probably not within the StringCompressor itself.
> I set the debug flag and got: java.io.IOException: Not an integer
> value (full trace below). Synchronizing the methods did not help
> either. I am trying to put together a test case for you, but it will
> take some time to put together the relevant parts from the project.
Ok.
>
> In the meantime i figured out something else: When the error occurs,
> the ExtendedDataInput carries not an encoded series of numbers
What is an "encoded series of numbers"?
Do you mean the StringCompressors of the
CDOClientProtocol/CDOServerProtocol do not encode a String to an int?
> but it is instead a char[]
> "http://foomodel/sampling#SamplinggeReference" - "Sampling" being one
> of the classes in the model as well as the name of the metamodel
> itself, i don't know where "geReference" comes from, not from my model
> or code.
This definitely looks like a problem but I have never seen such before.
It should be "http://foomodel/sampling#Sampling"
CDOClassifierRef is so simple that I can almost exclude a bug therein.
Can you set a conditional breakpoint (or add an "if") and try to find
out where this String comes from?
> Maybe there is reason for it being there but I don't understand it.
> There should probably not be a string there in the first place, right?
Why not? It's hard to predict when exactly the StringCompressor starts
compressing a given String. For example it relies on the same
compressors being used for both directions (to return acknowledgements
for new mappings, etc).
> From here it's difficult for me to see where that array is
> constructed, but thats probably where the problem is I guess. Can you
> point me there or does it narrow down the problem a bit?
While that looks like a problem, I can not see why the compressor should
not compress the (wrong) string. Personally I have the feeling that the
channel (protocol) got out of sync (between sender and receiver)
completely for some reason. That could explain both (mutually unrelated)
problems as follow-ups...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Regards,
> Tobias
>
>
> java.io.IOException: Not an integer value
> at
> org.eclipse.net4j.util.io.StringCompressor.readInt(StringCom pressor.java:276)
>
> at
> org.eclipse.net4j.util.io.StringCompressor.read(StringCompre ssor.java:135)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageURI(CDODataInputImpl.java:124)
>
> at
> org.eclipse.emf.cdo.common.model.CDOClassifierRef.<init>(CDOClassifierRef.java:52)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOClassifierRef(CDODataInputImpl.java:129)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOClassifierRefAndResolve(CDODataInputImpl.java:134)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. read(AbstractCDORevision.java:119)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDORevision(CDODataInputImpl.java:219)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:238)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:172)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>
> 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:312)
> 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:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> 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)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03067 seconds