Issue with chunking and rollback

[castortech]

I have a situation where we have a rollback and the list compare is failing since all proxies are not resolved:

          if (newRevision != null)
          {
            // We need to resolve all proxy elements for comparison
            getSession().resolveAllElementProxies(newRevision);

            InternalCDORevisionDelta delta = newRevision.compare(oldRevision);

The issue stems from the fact that resolveAllElementProxies doesn't guarantee that all proxies are resolved.

The code has:

  public void resolveAllElementProxies(CDORevision revision)
  {
    InternalCDORevision internalRevision = (InternalCDORevision)revision;
    if (!internalRevision.isUnchunked())
    {
      CDOCollectionLoadingPolicy policy = options().getCollectionLoadingPolicy();

      for (EReference reference : internalRevision.getClassInfo().getAllPersistentReferences())
      {
        checkForProxiesToResolve(policy, internalRevision, reference);
      }

      internalRevision.setUnchunked();
    }
  }

but isUnchecked can be true if only a single chunk has been resolved.

Earlier before the rollback happens, we have a write with the following stacktrace (ignore lines as we have mods):

java.lang.Throwable
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.setUnchunked(BaseCDORevision.java:1167)
	at org.eclipse.emf.cdo.internal.server.Repository.ensureChunks(Repository.java:1075)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.write(BaseCDORevision.java:348)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:505)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRevision(RevisionInfo.java:234)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeResult(RevisionInfo.java:168)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevisionsIndication.responding(LoadRevisionsIndication.java:222)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:162)
	at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:100)
	at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:392)
	at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:74)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:329)
	at org.eclipse.net4j.signal.SignalReactor.runSync(SignalReactor.java:97)
	at org.eclipse.net4j.signal.Signal.run(Signal.java:201)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

so the issue is that in ensureChunks we have:

  public void ensureChunks(InternalCDORevision revision, int chunkSize)
  {
    if (revision.isUnchunked())
    {
      return;
    }

    IStoreAccessor accessor = null;
    boolean unchunked = true;
    for (EStructuralFeature feature : revision.getClassInfo().getAllPersistentFeatures())
    {
      if (feature.isMany())
      {
        MoveableList<Object> list = revision.getListOrNull(feature);
        if (list != null)
        {
          int size = list.size();
          if (size != 0)
          {
            int chunkSizeToUse = chunkSize;
            if (chunkSizeToUse == UNCHUNKED)
            {
              chunkSizeToUse = size;
            }

            int chunkEnd = Math.min(chunkSizeToUse, size);
            accessor = ensureChunk(revision, feature, accessor, list, 0, chunkEnd);

            if (unchunked)
            {
              for (int i = chunkEnd; i < size; i++)
              {
                if (list.get(i) == InternalCDOList.UNINITIALIZED)
                {
                  unchunked = false;
                  break;
                }
              }
            }
          }
        }
      }
    }

    if (unchunked)
    {
      revision.setUnchunked();
    }
  }

which gets called with a chunkSize of 300 and here there thousands of other entries are not resolved.

In resolveAllProxies it runs with:

doResolveProxy(revision, feature, 0, 0, Integer.MAX_VALUE);

but the 0,0 causes it to quickly set minReached & maxReached to true since the first 300 are resolved.

Am I missing something or is there really an issue ?

Thanks
Alain

[castortech]

I would like to add that we have been having sporadic issues with Proxy element that we have never been able to pin down. I am starting to wonder if it would not be the same issue, where a first chunk is loaded (here 300), unchunked is set to true and then at some point we try to address some other references and since unchunked is true, it fails to load them. IMHO there seems to be a value missing to know how much has been unchunked in the revision feature or unchunked to be at the feature level.

[estepper]

Hi Alain,

Apologies for my late reply. And you won't like this reply ;-(

Chunking (collection loading policy) is a feature that I wish was never added because it's so much in dispute with many other common features of CDO, especially those that rely on object comparison, such as rollback. It's so cross-cutting, I'm not able to analyze, fix, and support all that. Do you think the use of Chunking is inevitable for your application?

[castortech]

Hi Eike,

Glad to hear from you, hope you're doing well.

And yes, not sure I like the reply :(, we have as stated above cases with thousands of entries where I feel that the chunking normally helps, until it doesn't.

I would be tempted to say, can't we address some of the issues that I identified and go from there, but you might know things that I don't and feel like we're just gonna be opening a Pandora's box.

What do you think ?

Alain

[estepper]

Some functions, such as comparing objects / lists, just need all the list elements (no proxy elements). when they're executed you end up loading all those missing list elements anyway.

Have you already played with org.eclipse.emf.cdo.util.CDOBalancedTree ? It can help organize the storage of large amounts of objects by putting them in a balanced tree structure.

[castortech]

I had never noticed the balance tree but AFAICT it is not what I need. I need like the current approach where the solution doesn't affect persistence or the model schema. What is needed is ephemeral when you pull data (getContents()) and this containment has 5k entries, to be able to resolve it as needed. At the same time I must say that most often when we pull such data, at the end we will go through all of it, as we often have sorting to do, or need to provide the list for the UI. IMHO what would be great is to have some form of cursor or paginated mode (but that is already pretty much what the loading policy does). The problem is that when data changes between the request for the next "page" reconciliation will take place and potentially change some of the previous content and all. Not an easy task.

But I'd like to address your point about "Some functions, such as comparing objects / lists, just need all the list elements (no proxy elements)", isn't it the case that this is for cases falling out of the "easy path" and quite rare, in which case the cost of resolving all the proxy might not be that impacting (like an optimistic system).