| Getting CDOElementProxy in various places [message #1844480] |
Tue, 14 September 2021 21:58  |
 Alain Picard
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
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 07:37] Report message to a moderator |
|
|
| Re: Getting CDOElementProxy in various places [message #1844594 is a reply to message #1844480] |
Fri, 17 September 2021 08:37  |
|
The UNCHUNKED flag of a CDORevision is kind of a derived value. It's (supposed to be) true if and only if no feature list of that revision contains an element proxy. It's an optimization especially for the majority of scenarios where the session does not use partial collection loading.
Please note that partial collection loading is often a bit questionable in combination with other CDO features that require all list elements to be loaded, such as merging conflict resolvers. You seem to be using this combination. Is partial collection loading really unavoidable for you?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: Getting CDOElementProxy in various places [message #1844615 is a reply to message #1844599] |
Fri, 17 September 2021 15:34 |
|
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.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03296 seconds
] 
Search
Help
Register
Login
Home
