| [CDO] Weird race condition when committing [message #431467] |
Sat, 11 July 2009 10:33  |
Eclipse User |
|
|
|
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)
|
|
|
|
|
|
|
| Re: [CDO] Weird race condition when committing [message #431482 is a reply to message #431476] |
Mon, 13 July 2009 02:33  |
| Eclipse User |
|
|
|
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)
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.26304 seconds
Home