Hi Steve, Sure, it will be at the end of this week.
On Tue, Jan 21, 2014 at 12:36 AM, StevenTomer <[email protected]>wrote: > Andrey, > > The fix to Issue 1977 does work to fix this bug. > > Is there any chance that we could get this on a hotfix? > > Steve > > > On Friday, January 17, 2014 11:03:21 PM UTC-7, StevenTomer wrote: >> >> We are getting the server into a bad state, after which every transaction >> fails with a java.lang.Error (Maximum lock count exceeded). We're using a >> remote connection. >> >> I wrapped a try block, around the lock.readLock().lock() call in the >> class OModificationLock, checking for java.lang.Error (and printing a stack >> trace if there is a failure) and adding an instance counter. >> >> I found that there is a path for which calls to requestModificationLock >> are not being followed up by calls to releaseModificationLock. >> >> The Maximum lock count exceeded message occurs around when the counter >> reaches ~520,000. >> >> When I get the error, the stack trace I printed is as follows: >> java.lang.Error (Maximum lock count exceeded) >> com.orientechnologies.common.concur.lock.OModificationLock.r >> equestMoficationLock(OModificationLock.java:51) >> com.orientechnologies.orient.core.index.OIndexAbstract.acqui >> reModificationLock(OIndexAbstract.java:1084) >> com.orientechnologies.orient.core.index.OClassIndexManager.a >> cquireModificationLock(OClassIndexManager.java:556) >> com.orientechnologies.orient.core.index.OClassIndexManager.c >> heckIndexesAndAcquireLock(OClassIndexManager.java:522) >> com.orientechnologies.orient.core.index.OClassIndexManager.o >> nRecordBeforeUpdate(OClassIndexManager.java:129) >> com.orientechnologies.orient.core.hook.ODocumentHookAbstract.onTrigger( >> ODocumentHookAbstract.java:263) >> com.orientechnologies.orient.core.db.record.ODatabaseRecordAbstract. >> callbackHooks(ODatabaseRecordAbstract.java:1065) >> com.orientechnologies.orient.core.tx.OTransactionOptimistic.addRecord( >> OTransactionOptimistic.java:313) >> com.orientechnologies.orient.server.tx.OTransactionOptimisticProxy.begin( >> OTransactionOptimisticProxy.java:129) >> com.orientechnologies.orient.core.db.record.ODatabaseRecordTx.begin( >> ODatabaseRecordTx.java:94) >> com.orientechnologies.orient.core.db.record.ODatabaseRecordTx.begin( >> ODatabaseRecordTx.java:38) >> com.orientechnologies.orient.core.db.ODatabaseRecordWrapperAbstract.begin >> (ODatabaseRecordWrapperAbstract.java:126) >> com.orientechnologies.orient.server.network.protocol.binary. >> ONetworkProtocolBinary.commit(ONetworkProtocolBinary.java:1047) >> com.orientechnologies.orient.server.network.protocol.binary. >> ONetworkProtocolBinary.executeRequest(ONetworkProtocolBinary.java:303) >> com.orientechnologies.orient.server.network.protocol.binary. >> OBinaryNetworkProtocolAbstract.execute(OBinaryNetworkProtocolAbstract. >> java:125) >> com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:45) >> >> >> >> Tracing into the problem, it only occurs for us when sending a >> Transaction, and the number of locks only increases for creates in this >> transaction (not for updates...) >> >> (OTransactionOptimistic.java) >> protected void addRecord(final ORecordInternal<?> iRecord, final byteiStatus >> , final String iClusterName) { >> switch (iStatus) { >> case ORecordOperation.CREATED: >> database.checkSecurity(ODatabaseSecurityResources.CLUSTER, >> ORole.PERMISSION_CREATE, iClusterName); >> // !! This gets the Modification Lock !! >> database.callbackHooks(TYPE.BEFORE_CREATE, iRecord); >> break; >> >> >> ... >> >> >> switch (iStatus) { >> case ORecordOperation.CREATED: >> // !! This calls the hooks that apply after a create, which >> should free the Modification Lock !! >> database.callbackHooks(TYPE.AFTER_CREATE, iRecord); >> break; >> >> >> ... >> >> >> (ODatabaseRecordAbstract.java) >> public ORecordHook.RESULT callbackHooks(final TYPE iType, final >> OIdentifiable id) { >> // !! There are some returns at the beginning of this function that >> may not be safe - won't free the lock !! >> ... >> // !! Call the trigger !! >> final RESULT res = hook.onTrigger(iType, rec); >> ... >> >> >> (ODocumentHookAbstract.java) >> public RESULT onTrigger(final TYPE iType, final ORecord<?> iRecord) { >> if (ODatabaseRecordThreadLocal.INSTANCE.isDefined() && >> ODatabaseRecordThreadLocal.INSTANCE.get().getStatus() != STATUS.OPEN) >> // !! Probably not safe - won't free the lock !! >> return RESULT.RECORD_NOT_CHANGED; >> >> >> if (!(iRecord instanceof ODocument)) >> // !! Probably not safe - won't free the lock !! >> return RESULT.RECORD_NOT_CHANGED; >> >> >> final ODocument document = (ODocument) iRecord; >> if (!filterBySchemaClass(document)) >> // !! Not safe - won't free the lock !! >> // !! The creates are falling in here when iType = >> TYPE.AFTER_CREATE !! >> return RESULT.RECORD_NOT_CHANGED; >> ... >> >> >> switch (iType) { >> case AFTER_CREATE: >> // !! releases the lock - we don't get here !! >> onRecordAfterCreate(document); >> break; >> case CREATE_FAILED: >> // !! releases the lock - we don't get here !! >> onRecordCreateFailed(document); >> break; >> ... >> >> >> It seems to me that filterBySchemaClass is not doing the right thing - >> the variable includeClasses is set, but only with single items like >> OFunction or OUser. I don't think this is how it was intended to be used. >> >> The return statements that don't call the hook also seem like a problem. >> Maybe it would be wise to look into whether the return statements are the >> right strategy, considering the implications of not releasing the locks. >> It looks like it is possible to get into a similar situation with Updates >> or Deletes, although we have not yet experienced it. >> >> We're really in a bind with this problem - we don't want to have to >> downgrade back to the 1.1.0 server we have been using. >> >> Thanks for your help. I hope I've given you enough information to put >> you right on it. I've made issue 1977 for this. >> >> Steve >> >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Best regards, Andrey Lomakin. Orient Technologies the Company behind OrientDB -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
