| Getting CDOElementProxy in various places [message #1844480] |
Tue, 14 September 2021 17:58  |
Eclipse User |
|
|
|
From time to time we've been getting some CDOElementProxy show up and lead to ClassCastException.
I read the old forum post at: https://www.eclipse.org/forums/index.php?t=msg&th=487998&goto=1060435&#msg_1060435
For now I added some log and breakpoint (if happens in dev) around the unchunked flag, but there is one thing that I clearly don't understand.
In CDOStoreImpl#resolveProxy we have:
if (value instanceof CDOElementProxy)
{
// Resolve proxy
CDOElementProxy proxy = (CDOElementProxy)value;
value = view.getSession().resolveElementProxy(revision, feature, index, proxy.getIndex());
...
and in CDOSessionImpl#resolveElementProxy we now do:
if (!((InternalCDORevision)revision).isUnchunked())
{
CDOCollectionLoadingPolicy policy = options().getCollectionLoadingPolicy();
return policy.resolveProxy(revision, feature, accessIndex, serverIndex);
}
When would it be Ok to not resolved what is known as a proxy? CDOSessionImpl#resolveElementProxy is called by exactly 2 methods that each test for a CDOElementProxy first, so really not sure what is the alternative if unchunked is not set properly and we still have a proxy to deal with?
But I can also see other cases such as this one that don't seem to go to resolve proxy AFAICT:
java.lang.ClassCastException: class org.eclipse.emf.cdo.internal.common.revision.CDOElementProxyImpl cannot be cast to class org.eclipse.emf.cdo.common.id.CDOID (org.eclipse.emf.cdo.internal.common.revision.CDOElementProxyImpl and org.eclipse.emf.cdo.common.id.CDOID are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3b916fc2)
at org.eclipse.emf.spi.cdo.CDOMergingConflictResolver$1.visit(CDOMergingConflictResolver.java:331)
at org.eclipse.emf.cdo.internal.common.revision.delta.CDORemoveFeatureDeltaImpl.accept(CDORemoveFeatureDeltaImpl.java:83)
at org.eclipse.emf.cdo.spi.common.revision.CDOFeatureDeltaVisitorImpl.visit(CDOFeatureDeltaVisitorImpl.java:55)
at org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.accept(CDOListFeatureDeltaImpl.java:592)
at org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.accept(CDORevisionDeltaImpl.java:364)
at org.eclipse.emf.spi.cdo.CDOMergingConflictResolver.updateObjects(CDOMergingConflictResolver.java:308)
at org.eclipse.emf.spi.cdo.CDOMergingConflictResolver.updateTransactionWithResult(CDOMergingConflictResolver.java:270)
at org.eclipse.emf.spi.cdo.CDOMergingConflictResolver.resolveConflicts(CDOMergingConflictResolver.java:174)
at com.castortech.iris.repository.abstractimpl.IRISConflictResolver.resolveConflicts(IRISConflictResolver.java:58)
at org.eclipse.emf.spi.cdo.CDOMergingConflictResolver.resolveConflicts(CDOMergingConflictResolver.java:142)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.handleConflicts(CDOTransactionImpl.java:959)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidateSynced(CDOViewImpl.java:1301)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:1252)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.doRun(CDOViewImpl.java:2904)
Is the resolver expected to resolve proxy at all times ? If not what is a good solution to address this.
Cheers,
Alain
[Updated on: Wed, 15 September 2021 03:37] by Moderator |
|
|
|
|
| Re: Getting CDOElementProxy in various places [message #1844615 is a reply to message #1844599] |
Fri, 17 September 2021 11:34  |
| Eclipse User |
|
|
|
It's a fact that the DefaultCDOMerger (here used by MergingCDOConflictResolver) can not deal with element proxies. That means that none of the two changes sets that are massed into its merge() method may contain any such proxies. In other words, all CDORevisions (i.e. the ones of the new objects) in those change sets must have the UNCHUNKED flag set. Looking at the code of CDORevisionDeltaImpl.compareLists(...).new ListDifferenceAnalyzer() {...}.checkNoProxies(EList<?>, CDORevision) I get the impression that element proxies would lead to an (expected) exception here. Hmm...
Looking again at your stack trace, the CCE happens in CDOMergingConflictResolver.updateObjects() when applying the newLocalDelta. this newLocalDelta must have been computed by the DefaultCDOMerger. If this newLocalDelta contains a proxy I wonder why this didn't become a problem already earlier in the merger.
I'm sorry that I can't be more concrete and helpful, but without a test case to reproduce and debug the problem it's very hard.
|
|
|
Powered by
FUDForum. Page generated in 0.08166 seconds
Home