Tabs: PersistenceException: Unable to commit changes to session

[Kiwinka]

Bug Report

TLDR;
when doing operation with tabs I have this error:

org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session

Lore
I proxied Tabs component, followed the documentation, created the _cq_editConfig.xml file and also added cq:isContainer="true" property.
Then I created a panel component, which is resourceSuperType of responsivegrid, to represent one panel in the Tabs container.
In the policies of the component I defined that only Panel can be used in Tabs.

Current Behavior

When configurating the Tabs component on a page, after adding new panels, or deleting/moving them, I can't save the actions and I'm stopped by the error 'PersistenceException: Unable to commit changes to session'. This does not happen every time, but I couldn't figure out the pattern. It happens when I configure panels through the configuration window. When adding panel with the '+' on the parent component, it does work and they are added, but when I add name to the panel in the Tabs configuration, I can't save the changes.

Expected behavior
I expect to be able to edit the Tabs configuration.

Environment

• AEM version: AEM 6.5
• Core Components version: 2.17.12
• Tabs version: v1
• JRE version: Java(TM) SE Runtime Environment (build 1.8.0_202-b08)

Additional info
error log.txt

I'm attaching the export from error log (only a part of it)

[ky940819]

This usually happens when two or more things are updating the same nodes at the same time.

Assuming that you don't have any other services that might be updating the content, then my guess would be that this might be related to the panel container making two simultaneous POST requests that might modify the same content.
One post request will set the panel item titles, the second post request reorders them.

I have confirmed that I can reproduce this issue by the following procedure:

• Create a tab container and add several tabs (I added ~20 tabs) - save the tab container
• Open chrome dev tools and observe network
• Edit the tab container
  • Reorder the tabs
  • Rename the tabs
  • do not add or remove tabs
  • Save the dialog
  • Copy the cURL commands for both POST requests and save them into a shell script named "tabs1.sh" that will execute both post requests concurrently (e.g. curl ... & curl ...).
• Edit the tab container again
  • Reorder the tabs
  • Rename the tabs
  • do not add or remove tabs
  • Save the dialog
  • Copy the cURL commands for both POST requests and save them into a shell script named "tabs2.sh" that will execute both post requests concurrently.
• Run both shell scripts serially e.g. tabs1.sh ; tabs2.sh ; tabs1.sh ; tabs2.sh ; ... - This will simulate quickly swapping between the two orderings and namings.
• Observe the error.log and note the error OakState0001: Unresolved ...

The bug only occurs when the two modifications to the node happen at the same time. Usually one will beat out the other slightly and the error will not occur. For this reason the running of one set of orderings and namings and then the other set is repeated to ensure that with every execution there are actually repository changes occurring (i.e. not just posting the same content every time)

The issue is exacerbated under high load (or lower-performance server). When the test is conducted while stressing the system, the error rate is nearly 100% (in my test). When not under stress the error rate is ~5% (in my test).

---

Proposed solution is to post the data and only when the first post is complete should the second post be made.
Or, if possible, make it just one POST.

[Kiwinka]

Thank you very much @ky940819
However, this was not the issue.
After many hours of debugging, it was found that the problem was the path to the core component.
In my proxy component I had:
sling:resourceSuperType="/apps/core/wcm/components/tabs/v1/tabs"
and after changing it to
sling:resourceSuperType="core/wcm/components/tabs/v1/tabs"
everything magically started working.

[ky940819]

I'm glad your issue is resolved.

I would still urge someone to look into the issue though, because I was able to reproduce the same error using the core components example site - so regardless of if we hit different errors, there is still something there.

[Abhishek-F-Secure]

Hi @ky940819 was this issue resolved somewhere? I am getting this issue now