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
