| [CDO 4.0 SR2] Indeterministic ClassCastException with prefetch [message #816780] |
Fri, 09 March 2012 08:51  |
 Esteban Dugueperoux
Messages: 472
Registered: July 2009 |
Senior Member |
|
|
Hi CDO Team,
I have a bug I reproduce randomly (half the time) and can't reproduce
with outside my example, I have 2 clients sharing 2 CDOResource
referenced by a local one (XMIResource), the first CDOResource content
is represented by native CDOObjects (some semantic objects in our
terminology) and the second CDOResource content is represented by legacy
objects (some diagram element object in our terminology) which
references these semantic objects.
When these 2 clients access these resources it calls :
cdoResource.cdoPrefetch(CDORevision.DEPTH_INFINITE);
to have all needed CDORevision in the CDORevisionManager's cache to
avoid many load revision request to the server.
The scenario of the ClassCastException is the following (with passive
update mode) :
The first client move a object of the semantic CDOResource from one
container object to another container, this last is child of this first
container, and commits.
In consequence the second client receives these changes through
changedObjects (CDORevisionDelta), newObjects and detachedObjects, in
the CDOSessionImpl.reviseRevisions() to manage the changedObjects, the
second client for each changed object (CDORevisionDelta) try to get the
old CDORevision corresponding from the CDORevisionManager's cache to
update it according to the CDORevisionDelta. But in some case (which
appears randomly) the old CDORevision is not retreived then the
CDORevisionDelta is not applied through the CDOFeatureDeltaVisitor and I
have a CDORevisionDelta which contains a CDORemoveFeatureDelta with a
oldValue equals to UNKNOWN_VALUE.
And after when CDODeltaNotification are sent, the CDONotificationBuilder
constructs a CDODeltaNotification from the previous
CDORemoveFeatureDelta with a oldValue equals to UNKNOWN_VALUE, then if I
do a Notification.getOldValue(), for example like in
EContentAdapter.handleContainment() I get a ClassCastException because
UNKNOWN_VALUE can't be casted to Notifier :
java.lang.ClassCastException:
org.eclipse.emf.cdo.common.revision.delta.CDOFeatureDelta$1 cannot be
cast to org.eclipse.emf.common.notify.Notifier
at
org.eclipse.emf.ecore.util.EContentAdapter.handleContainment(EContentAdapter.java:160)
at
org.eclipse.emf.ecore.util.EContentAdapter.selfAdapt(EContentAdapter.java:80)
at
org.eclipse.emf.ecore.util.EContentAdapter.notifyChanged(EContentAdapter.java:46)
at
org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:380)
at
org.eclipse.emf.common.notify.impl.NotificationChainImpl.dispatch(NotificationChainImpl.java:104)
at
org.eclipse.emf.common.notify.impl.NotificationChainImpl.dispatch(NotificationChainImpl.java:92)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl.sendDeltaNotifications(CDOViewImpl.java:633)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:517)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1237)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:81)
at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:72)
at
org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
I have seen that you use many HashMap/HashSet values() method which
return a list whose order is inderterministic, I have tried to replace
this data structure with LinkedHashMap/LinkedHashSet to avoid this
indeterminism but I have always this bug.
Do you have a tip to help me progress in my analysis of this issue or to
try to reproduce this outside my example?
Best Regards.
|
|
|
| Re: [CDO 4.0 SR2] Indeterministic ClassCastException with prefetch [message #816883 is a reply to message #816780] |
Fri, 09 March 2012 11:32  |
|
Hi Esteban,
That sounds weird. Worse, I don't know how to help if I can't reproduce it ;-(
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 09.03.2012 09:51, schrieb Esteban Dugueperoux:
> Hi CDO Team,
>
> I have a bug I reproduce randomly (half the time) and can't reproduce with outside my example, I have 2 clients
> sharing 2 CDOResource referenced by a local one (XMIResource), the first CDOResource content is represented by native
> CDOObjects (some semantic objects in our terminology) and the second CDOResource content is represented by legacy
> objects (some diagram element object in our terminology) which references these semantic objects.
>
> When these 2 clients access these resources it calls :
> cdoResource.cdoPrefetch(CDORevision.DEPTH_INFINITE);
>
> to have all needed CDORevision in the CDORevisionManager's cache to avoid many load revision request to the server.
>
> The scenario of the ClassCastException is the following (with passive update mode) :
> The first client move a object of the semantic CDOResource from one container object to another container, this last
> is child of this first container, and commits.
>
> In consequence the second client receives these changes through changedObjects (CDORevisionDelta), newObjects and
> detachedObjects, in the CDOSessionImpl.reviseRevisions() to manage the changedObjects, the second client for each
> changed object (CDORevisionDelta) try to get the old CDORevision corresponding from the CDORevisionManager's cache to
> update it according to the CDORevisionDelta. But in some case (which appears randomly) the old CDORevision is not
> retreived then the CDORevisionDelta is not applied through the CDOFeatureDeltaVisitor and I have a CDORevisionDelta
> which contains a CDORemoveFeatureDelta with a oldValue equals to UNKNOWN_VALUE.
> And after when CDODeltaNotification are sent, the CDONotificationBuilder constructs a CDODeltaNotification from the
> previous CDORemoveFeatureDelta with a oldValue equals to UNKNOWN_VALUE, then if I do a Notification.getOldValue(), for
> example like in EContentAdapter.handleContainment() I get a ClassCastException because UNKNOWN_VALUE can't be casted
> to Notifier :
>
> java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.delta.CDOFeatureDelta$1 cannot be cast to
> org.eclipse.emf.common.notify.Notifier
> at org.eclipse.emf.ecore.util.EContentAdapter.handleContainment(EContentAdapter.java:160)
> at org.eclipse.emf.ecore.util.EContentAdapter.selfAdapt(EContentAdapter.java:80)
> at org.eclipse.emf.ecore.util.EContentAdapter.notifyChanged(EContentAdapter.java:46)
> at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:380)
> at org.eclipse.emf.common.notify.impl.NotificationChainImpl.dispatch(NotificationChainImpl.java:104)
> at org.eclipse.emf.common.notify.impl.NotificationChainImpl.dispatch(NotificationChainImpl.java:92)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.sendDeltaNotifications(CDOViewImpl.java:633)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:517)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1237)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
> at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:81)
> at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:72)
> at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
>
> I have seen that you use many HashMap/HashSet values() method which return a list whose order is inderterministic, I
> have tried to replace this data structure with LinkedHashMap/LinkedHashSet to avoid this indeterminism but I have
> always this bug.
>
> Do you have a tip to help me progress in my analysis of this issue or to try to reproduce this outside my example?
>
> Best Regards.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02536 seconds
] 
Search
Help
Register
Login
Home
