Eclipse Community Forums: EMF » [CDO] Rare problem in permission cache

Home » Modeling » EMF » [CDO] Rare problem in permission cache(NoPermissionException when modifying a writable object)

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] Rare problem in permission cache [message #1849800]

Thu, 03 February 2022 10:04

Robert Schulk

Messages: 144
Registered: July 2015

Senior Member

This issue kept us busy for some time and we could never figure out where it is coming from. But now I can somewhat reproduce it on our system.

Problem description:
We continuously add objects to a list (which is the content of a cdo object). We keep the list in a reasonable size of ~1000 obejcts.
Quite rarely, but randomly (it takes ~0 to 1000k commits), one of the objects in the list will have the permission to be read-only. This is tied to the session. Even if we open a new transaction, the permission will stay read-only. For new sessions, the permission is correct again.

Now I am able to reproduce this on our system. I tested the 2021-09 release with H2 db and TCP/JVM/WS connection, non-branching, non-auditing. What I do:
* Add new objects to a list in one thread.
* In another thread: open a view and add an EContentAdapter to the object that holds the list and wait for 1 second. Then close the view again and repeat.

I attached my console output with full cdo tracing enabled. See end for the NoPermissionException. Maybe we can find a workaround to recover the correct permission? Or is this log even enough to hint to a fix?

Attachment: noPermissionLog.txt
(Size: 4.00MB, Downloaded 116 times)

[Updated on: Thu, 03 February 2022 10:25]

Report message to a moderator

Re: [CDO] Rare problem in permission cache [message #1849806 is a reply to message #1849800]

Thu, 03 February 2022 11:18

Robert Schulk

Messages: 144
Registered: July 2015

Senior Member

I created another debug log with the most recent release (20220116-1034). This time additionally with net4j tracing enabled.

What I noticed: we seem to always get another exception beforehand "java.lang.UnsupportedOperationException: Mapping strategy does not support audits"

Attachment: noPermissionLog2.txt
(Size: 3.05MB, Downloaded 99 times)

Report message to a moderator

Re: [CDO] Rare problem in permission cache [message #1849807 is a reply to message #1849800]

Thu, 03 February 2022 11:21

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Robert,

Thanks for trying to reproduce the problem.
Do you think you can come up with a CDO test case, so that I can reproduce it, too?

Here's a list of existing test cases that use and test a security manager:

Bugzilla_417483_Test.doSetUp()
Bugzilla_399487_Test.setUp()
Bugzilla_422170_Test.setUp()
Bugzilla_501607_Test.setUp()
Bugzilla_560280_Test.setUp()
Bugzilla_418267_Test.startSecureRepository()

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] Rare problem in permission cache [message #1849816 is a reply to message #1849807]

Thu, 03 February 2022 14:48

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Sorry, I missed your second message. Do you have the CDO sources at hand in order to try something out?

In CommitTransactionIndication.java at line 410 you see this:

CDOBranchPoint securityContext = commitContext.getBranchPoint();

Please change that line to the following:

CDOBranchPoint securityContext = commitContext.getBranchPoint();
if (!session.getManager().getRepository().isSupportingAudits())
{
     securityContext = securityContext.getBranch().getHead();
}

Does that fix the problem?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] Rare problem in permission cache [message #1849819 is a reply to message #1849807]

Thu, 03 February 2022 15:06

Robert Schulk

Messages: 144
Registered: July 2015

Senior Member

Hi Eike, please see the attached patch which reproduces the problem for me quite reliably. You need to start the test case in non-audit mode.

Its a bit messy ("Logspec" package was copied from our code), sorry for that ;).