[
https://issues.apache.org/jira/browse/OAK-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-7495:
-----------------------------
Description:
On an oak 1.6.1 (AEM 6.3) a suspicious behaviour was detected, where in Sling
an
[addJob|https://github.com/apache/sling-old-svn-mirror/blob/org.apache.sling.event-4.2.0/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L286]
followed by a
[getJobById|https://github.com/apache/sling-old-svn-mirror/blob/org.apache.sling.event-4.2.0/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L294]
(in a different thread though, but perhaps would also fail in same thread) was
not seeing the job that was just created.
To give a bit more background, in Sling getJobById results in a query. That
query uses an index which is built using {{"async, sync"}}. So the assumption
is that the index is actually synchronous. But a test reproducing initially
mentioned scenario showed the opposite.
Attached:
* [^GetJobVerifier.java] a Sling job test case that has 2 threads: a thread
that does addJob, adds the resulting jobId to a list (synchronized). and a
second thread that reads the jobId off that list and does a getJobById. That
getJobById should find the job, as it was just created (how else could you
figure out the jobId) - but sometimes it FAILs (see system out FAIL)
* [^slingeventJob.-1.tidy.json] the index definition showing it is indeed
"async, sync"
PS: Example query that is executed:
{{/jcr:root/var/eventing/jobs//element(*,slingevent:Job)[@slingevent:eventId =
'2018/5/11/2/12/bca505d9-3044-4de9-9732-056ab1b6c513_5569']}}
/cc [~catholicon]
was:
On an oak 1.6.1 (AEM 6.3) a suspicious behaviour was detected, where in Sling
an
[addJob|https://github.com/apache/sling-old-svn-mirror/blob/org.apache.sling.event-4.2.0/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L286]
followed by a
[getJobById|https://github.com/apache/sling-old-svn-mirror/blob/org.apache.sling.event-4.2.0/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L294]
(in a different thread though, but perhaps would also fail in same thread) was
not seeing the job that was just created.
To give a bit more background, in Sling getJobById results in a query. That
query uses an index which is built using {{"async, sync"}}. So the assumption
is that the index is actually synchronous. But a test reproducing initially
mentioned scenario showed the opposite.
Attached:
* [^GetJobVerifier.java] a Sling job test case that has 2 threads: a thread
that does addJob, adds the resulting jobId to a list (synchronized). and a
second thread that reads the jobId off that list and does a getJobById. That
getJobById should find the job, as it was just created (how else could you
figure out the jobId) - but sometimes it FAILs (see system out FAIL)
* [^slingeventJob.-1.tidy.json] the index definition showing it is indeed
"async, sync"
/cc [~catholicon]
> async,sync index not synchronous
> --------------------------------
>
> Key: OAK-7495
> URL: https://issues.apache.org/jira/browse/OAK-7495
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: indexing
> Affects Versions: 1.6.1
> Reporter: Stefan Egli
> Assignee: Vikas Saurabh
> Priority: Major
> Attachments: GetJobVerifier.java, slingeventJob.-1.tidy.json
>
>
> On an oak 1.6.1 (AEM 6.3) a suspicious behaviour was detected, where in Sling
> an
> [addJob|https://github.com/apache/sling-old-svn-mirror/blob/org.apache.sling.event-4.2.0/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L286]
> followed by a
> [getJobById|https://github.com/apache/sling-old-svn-mirror/blob/org.apache.sling.event-4.2.0/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L294]
> (in a different thread though, but perhaps would also fail in same thread)
> was not seeing the job that was just created.
> To give a bit more background, in Sling getJobById results in a query. That
> query uses an index which is built using {{"async, sync"}}. So the assumption
> is that the index is actually synchronous. But a test reproducing initially
> mentioned scenario showed the opposite.
> Attached:
> * [^GetJobVerifier.java] a Sling job test case that has 2 threads: a thread
> that does addJob, adds the resulting jobId to a list (synchronized). and a
> second thread that reads the jobId off that list and does a getJobById. That
> getJobById should find the job, as it was just created (how else could you
> figure out the jobId) - but sometimes it FAILs (see system out FAIL)
> * [^slingeventJob.-1.tidy.json] the index definition showing it is indeed
> "async, sync"
> PS: Example query that is executed:
> {{/jcr:root/var/eventing/jobs//element(*,slingevent:Job)[@slingevent:eventId
> = '2018/5/11/2/12/bca505d9-3044-4de9-9732-056ab1b6c513_5569']}}
> /cc [~catholicon]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
