Expand my Community achievements bar.

SOLVED

Repeatedly appearing oakstate error at same node in the logs for 6 hours

Avatar

Level 4

 

We are getting the below exception continuously more than 9 hours in logs as part of this functionality. 

 

Functionality :

 

Copying all pages from one country(UnitedStates) to another country(England) and adjusting references for all the pages using referencesearch API. We are passing single same resourceresolver to all method in this functionality to commit after write/modify operation. Using sling jobs in this functionality to make job execution as ordered.

 

Observations:

Initially error is thrown at /content/test/brand1/testpage/home/jcr:content/par/richtext/item1 for 2 hours. Later I deleted home page to stop this error and same error is thrown at /content/test/brand1/testpage for more than 6 hours.

 

Question :

I know this error might be multiple update on same node by different thread. In our code, this exception was catched in respective method and just log it for reference to proceed further(not throwing custom exception). But I don't know why this exception is repeated appearing on logs.

Is there any way to stop this exception without restarting the instance or sling jobs bundle ? I tried to stop sling job via SlingEvent console and getting different error there(

org.apache.felix.http.jetty Exception while processing request to /system/console/slingevent (java.lang.NullPointerException)

java.lang.NullPointerException: null

at org.apache.sling.event.impl.jobs.console.WebConsolePlugin.formatType(WebConsolePlugin.java:400))

 

 

 

 

*ERROR* [sling-threadpool-aa49ea2c-cf94-4d33-af84-de19ae673a98-(apache-sling-job-thread-pool)-34-Test Create Job(test/job/testcopy)] com.test.testUtil Error when saving changes

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

at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:519)

at org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.commit(AuthenticatedResourceProvider.java:215)

at org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.commit(ResourceResolverControl.java:422)

at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.commit(ResourceResolverImpl.java:989)

at com.test.testUtil.lambda$updateReferences$1(testUtil.java:131)

at org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:502)

at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:293)

at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60)

at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:229)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

Caused by: javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /content/test/brand1/testpage

at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:238)

at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:213)

at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:669)

at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:495)

at org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:424)

at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:273)

at org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:421)

at com.adobe.granite.repository.impl.CRX3SessionImpl.save(CRX3SessionImpl.java:208)

at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:517)

... 22 common frames omitted

Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved conflicts in /content/test/brand1/testpage

at org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:115)

at org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyChanged(ConflictValidator.java:90)

at org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyChanged(CompositeEditor.java:90)

at org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyChanged(EditorDiff.java:92)

at org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)

at org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:523)

at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)

at org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)

at org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)

at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)

at org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)

at org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)

at org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:440)

at org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)

at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)

at org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)

at org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)

at org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:51)

at org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)

at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:60)

at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:60)

at org.apache.jackrabbit.oak.segment.scheduler.Commit.apply(Commit.java:105)

at org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.execute(LockBasedScheduler.java:308)

at org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.schedule(LockBasedScheduler.java:279)

at org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:211)

at org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:250)

at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:346)

at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:493)

1 Accepted Solution

Avatar

Correct answer by
Employee

This is due to the OAK behavior which gives you a view on a certain state within the repository, when a change is performed on the repository, the change is performed against this base state and is applied (merged) to the HEAD state.

In case the state of the session differs too much from the HEAD state the merge fails, and an OakMerge exception is raised. This is due to other changes happening in the repository, which could affect also the areas where your session wants to perform its changes. This is a temporary behavior and could be resolved by refreshing the sessions.

It is suggested to keep the sessions short. The same can be achieved by configuring the 'Session Timeout' property at [1]. As the issue is intermittent, short lived sessions will reduce the chances of such issues to minimal.
Please test it on lower environments first.


[1] <Host>:<Port>/system/console/configMgr/org.apache.felix.http

View solution in original post

1 Reply

Avatar

Correct answer by
Employee

This is due to the OAK behavior which gives you a view on a certain state within the repository, when a change is performed on the repository, the change is performed against this base state and is applied (merged) to the HEAD state.

In case the state of the session differs too much from the HEAD state the merge fails, and an OakMerge exception is raised. This is due to other changes happening in the repository, which could affect also the areas where your session wants to perform its changes. This is a temporary behavior and could be resolved by refreshing the sessions.

It is suggested to keep the sessions short. The same can be achieved by configuring the 'Session Timeout' property at [1]. As the issue is intermittent, short lived sessions will reduce the chances of such issues to minimal.
Please test it on lower environments first.


[1] <Host>:<Port>/system/console/configMgr/org.apache.felix.http