transaction blocked in java code when there is a binary node inside to delete

[publicocean0]

considering the bug # 5613

there is another bug related to previous one

in my java code

i have a transaction deleting
a binary document A and a document B with a link to A.

commit function block indefinitely the thread executing the code

specular transaction for inserting /updating works well. The problems seams in delection.

[luigidellaquila]

Hi @publicocean0

could you please share a thread dump? (a kill -3 of the process will do the trick). It will help us to understand where the problem is

Thanks

Luigi

[publicocean0]

"http-nio-8080-exec-7" #122 daemon prio=5 os_prio=0 tid=0x00007ffaa465f000 nid=0xee5 waiting on condition [0x00007ffaf6e97000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x000000008a5c8918> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
    at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
    at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
    at com.orientechnologies.common.concur.lock.OAdaptiveLock.lock(OAdaptiveLock.java:99)
    at com.orientechnologies.orient.enterprise.channel.OChannel.acquireReadLock(OChannel.java:121)
    at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinaryAsynchClient.beginResponse(OChannelBinaryAsynchClient.java:182)
    at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinaryAsynchClient.beginResponse(OChannelBinaryAsynchClient.java:171)
    at com.orientechnologies.orient.client.remote.OStorageRemote.beginResponse(OStorageRemote.java:2153)
    at com.orientechnologies.orient.client.remote.OStorageRemote.commit(OStorageRemote.java:1381)
    at com.orientechnologies.orient.client.remote.OStorageRemoteThread.commit(OStorageRemoteThread.java:453)
    at com.orientechnologies.orient.core.tx.OTransactionOptimistic.doCommit(OTransactionOptimistic.java:596)
    at com.orientechnologies.orient.core.tx.OTransactionOptimistic.commit(OTransactionOptimistic.java:156)
    at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.commit(ODatabaseDocumentTx.java:2659)
    at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.commit(ODatabaseDocumentTx.java:2628)
    at com.123abc.dao.orientdb.BoDAO.removeABC(BoDAO.java:1540)
"OrientDB <- Asynch Client (/127.0.0.1:2424)" #104 daemon prio=5 os_prio=0 tid=0x00007ffa8c013000 nid=0xece runnable [0x00007ffafc182000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:150)
    at java.net.SocketInputStream.read(SocketInputStream.java:121)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    - locked <0x000000008a5c8b78> (a java.io.BufferedInputStream)
    at java.io.DataInputStream.readByte(DataInputStream.java:265)
    at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinary.readByte(OChannelBinary.java:73)
    at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinaryAsynchClient.beginResponse(OChannelBinaryAsynchClient.java:200)
    at com.orientechnologies.orient.enterprise.channel.binary.OAsynchChannelServiceThread.execute(OAsynchChannelServiceThread.java:50)
    at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:77)
"OrientDB <- Asynch Client (/127.0.0.1:2424)" #103 daemon prio=5 os_prio=0 tid=0x00007ffa8c011800 nid=0xecc runnable [0x00007ffafc283000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:150)
    at java.net.SocketInputStream.read(SocketInputStream.java:121)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    - locked <0x000000008a5c8398> (a java.io.BufferedInputStream)
    at java.io.DataInputStream.readByte(DataInputStream.java:265)
    at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinary.readByte(OChannelBinary.java:73)
    at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinaryAsynchClient.beginResponse(OChannelBinaryAsynchClient.java:200)
    at com.orientechnologies.orient.enterprise.channel.binary.OAsynchChannelServiceThread.execute(OAsynchChannelServiceThread.java:50)
    at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:77)

the thread blocked is the first one ... when i try to remove the documents.
I think the thread is blocked waiting a response from the server .... but no response is received. Maybe because ORecordBytes is invisible (a kinda problems related) ?

[andrii0lomakin]

Hi,
In stack trace we can find only classes of remote storage , assigned to @tglman

[publicocean0]

eventually if you can t find the bug ... i ll build a example in java code creating the block and will submit all the code so you have all the context repeatable

[tglman]

@publicocean0

That will be amazing, we are struggling a bit to reproduce.

[publicocean0]

i investigated in all the transaction code ... deleting in alternate way block of code .... now i can block also the console using javascript :)

 js var a=db.command("select from #33:341"); db.begin(); db.delete(a[0].identity); db.commit();

now i trying to delete different nodes....

[publicocean0]

solved.
The problem was inside a trigger on delete giving a exception. When exception is thrown is called db.rollback().

1. the exception inside triggered function is related with another bug : select from Add trigger feature [moved] #3:10 where 3:10 is a binary bytes gives no result in any case(error in console for seeing a binary document #5613).
2. maybe it is to emprove the behaviour of transaction in case there is a nested transaction just for evoiding thread blocks. Anyway now i removed it.
   2.a If the nested transaction throws a error what does it happen?
   2.b If the nested transaction execute a rollback , the parent transaction in what status goes?i suppose when nested transaction executed a rollback , the parent transaction status goes in a incosistent status. It is better throw a exception but not blocking thread.

[tglman]

Hi,

In oriendb there is no concept of nested transaction, the begin();commit(); block works as a "require transaction" so if one is already running it countinue it if not it create it and commit at the end.

Knowing that if an error happen somewhere, the whole transaction is rollbacked.

for the problem with the select of binary content we are checking that, track it in the other issue, anyway you can load a binary record with db.load(new ORecordId(33,341));

by the way, can we close this ?

[publicocean0]

Hi , i know that nested transaction is not handled for now in orientdb. But as you told it might work continuing the transaction normally.... not blocking the thread in any case. In that old block code i opened a nested transaction. Inside the block , there is a exception , so rolling back in the try cach of nested transaction.... and thread was blocked . The issue is related to a block of thread .... a suggestion to verify if in that condition all is ok. Apparently in this case the status of transaction is inconsistent. The nested transaction was inside a triggered function. It is a rare case surelly so priority could be low for investigation, but a thread bock could create serious problem in a production for a orientdb's general customer (for example it was inside a distributed lock ... so server got blocked for all requests :) not in prod fortunately) Anyway my code is changed now and i solved diversely the problem:)

[publicocean0]

i found the problem.

There is a Class A with a trigger on delete.
a is a instance of A.
i call ' delete a ' inside a transaction.
When orientdb enter in trigger
it calls a second js function with a body as this

db.begin()
try{
....
}catch(e){
db.rollback(); throw e;
}

writing a lot of trancing log... i saw that after is called db.begin()... the Thread get blocked on remote client

For now for evoiding the block of thread ... i m using in js

var txcount=db.transaction.amountOfNestedTxs() for understanding if i m in a transaction or not.

[andrii0lomakin]

Hi @publicocean0
Please do not make double rollbacks (inside of catch) it is done automatically if exception is thrown from ODB code itself and issue will be fixed without of hacks.

Does this solution works for you ?

[publicocean0]

in this way ?

db.begin()

....

if (error) throw "error";

Anyway that function inside the trigger function in my case is a function used also in other calls , so in some cases it is in a parent transaction in other no.
Making the ipothesis that rhe above block code is directly in the trigger function , there is another question.... in that case trigger is called by orienddb when a is delete in a transaction all ok , but if i call delete a without using a transaction? trigger is called always correctly ...but what does happen with source above?

[andrii0lomakin]

Hi ,
Yes exactly .

сб, 5 Мар 2016, 11:50 publicocean0 notifications@github.com:

in this way ?

db.begin()

....

if (error) throw "error";

—
Reply to this email directly or view it on GitHub
#5614 (comment)
.

Best regards,
Andrey Lomakin, R&D lead.
OrientDB Ltd

twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin

[tglman]

can we close this ?

[publicocean0]

Hi sorry if I can t answer in this period . I m working in another project very hard. No time. I will write asap. You can close if you want eventually I will reopen

[lvca]

Closing it, in case reopen it. Thanks.