You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by "Banerjee, Soumya J" <So...@in.tesco.com> on 2016/05/06 12:38:20 UTC

Problem related to Jackrabbit Oak v1.3.2

Version - 1.3.2
MongoMK

I know that 1.3.2 is not a stable version and we are on our way to migrate to 1.4.1 (latest stable build). But, we have a serious problem in Prod which is affecting a go-live. Any help is greatly appreciated.

In Production, we have a document node that is throwing a OAKMerge001 exception. We are not entirely sure how this state came into being (the person who was authoring the content had created it, deleted and then created again when this happened. The sequence is not exactly clear). The back-end storage is in Mongo.

When we try to delete this node through JCR, we get the same merge error. We have brought in new JCR machines thinking the persistent cache or in memory cache in JCR is creating this conflict. That didn't help.
We also tried deleting the document node directly in Mongo DB through Oak-Mongo.js(oak.removeDescendantsAndSelf()). Even this doesn't help. :(

We found out that if we find the CommitRoot of this document and delete all documents (including the index), it helps. However, the number of documents that get deleted with this is quite and we don't want to do that in a Live environment.

Steps to reproduce the problem:


1.       Create a document through JCR called 1.html

2.       Confirm index and the document in Mongo DB

3.       Update 1.html through JCR HTTP interface a few times

4.       Delete document in MongoDB directly (oak.removeDescendantsAndSelf())

5.       Create 1.html again

6.       Post 1.html with changes to an indexed attribute (property attribute)

7.       Merge conflict will arise.

Are there any other options that you recommend for us to try?

Thanks & Regards,
Soumya Jyoti Banerjee
(Sr. Software Engineer)
Ring : 8722181100
[cid:image001.jpg@01D1A7C2.26331130]


________________________________
This is a confidential email. Tesco may monitor and record all emails. The views expressed in this email are those of the sender and not Tesco.

Tesco Stores Limited
Company Number: 519500
Registered in England
Registered Office: Tesco House, Shire Park, Kestrel Way, Welwyn Garden City, AL7 1GA
VAT Registration Number: GB 220 4302 31

Re: Problem related to Jackrabbit Oak v1.3.2

Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,

there were a number of stability fixes implemented after
1.3.2 (e.g. OAK-3733). You should definitively upgrade to
a stable version.

there are a number of workarounds to reduce the risk of
running into these kind of issues with the version you
are currently using:

- exclude some paths from the affected property index.
  maybe the nodes you create do not need to be in all
  those indexes.
- replace affected property indexes with an asynchronous
  lucene property index. this is only feasible if it is
  OK for your application to index asynchronously

Regards
 Marcel  

On 06/05/16 14:38, "Banerjee, Soumya J" wrote:

>Version ­ 1.3.2
>MongoMK
> 
>I know that 1.3.2 is not a stable version and we are on our way to
>migrate to 1.4.1 (latest stable build). But, we have a serious problem in
>Prod which is affecting a go-live. Any help is greatly appreciated.
> 
>In Production, we have a document node that is throwing a OAKMerge001
>exception. We are not entirely sure how this state came into being (the
>person who was authoring the content had created it, deleted and then
>created again when this
> happened. The sequence is not exactly clear). The back-end storage is in
>Mongo.
> 
>When we try to delete this node through JCR, we get the same merge error.
>We have brought in new JCR machines thinking the persistent cache or in
>memory cache in JCR is creating this conflict. That didn¹t help.
>We also tried deleting the document node directly in Mongo DB through
>Oak-Mongo.js(oak.removeDescendantsAndSelf()). Even this doesn¹t help.
>L
> 
>We found out that if we find the CommitRoot of this document and delete
>all documents (including the index), it helps. However, the number of
>documents that get deleted with this is quite and we don¹t want to do
>that in a Live environment.
> 
>Steps to reproduce the problem:
> 
>1.      
>Create a document through JCR called 1.html
>2.      
>Confirm index and the document in Mongo DB
>3.      
>Update 1.html through JCR HTTP interface a few times
>4.      
>Delete document in MongoDB directly (oak.removeDescendantsAndSelf())
>5.      
>Create 1.html again
>6.      
>Post 1.html with changes to an indexed attribute (property attribute)
>7.      
>Merge conflict will arise.
> 
>Are there any other options that you recommend for us to try?
> 
>Thanks & Regards,
>Soumya Jyoti Banerjee
>(Sr. Software Engineer)
>Ring : 8722181100
>
> 
>
>
>________________________________________
>This is a confidential email. Tesco may monitor and record all emails.
>The views expressed in this email are those of the sender and not Tesco.
>
>Tesco Stores Limited
>Company Number: 519500
>Registered in England
>Registered Office: Tesco House, Shire Park, Kestrel Way, Welwyn Garden
>City, AL7 1GA
>VAT Registration Number: GB 220 4302 31