On 16/11/17 09:12, Jean-Marc Vanel wrote:
So I tested on the sandbox site,
and it got quickly frozen :( .
In 3 tabs of the browser,
I sent requests more or less simultaneously:
http://semantic-forms.cc:9111/search?q=chrysophylla&clas=
http://semantic-forms.cc:9111/display?displayuri=http%3A%2F%2Fsemantic-forms.cc%3A9111%2Fldp%2F1510064559306-25745506095233869
http://semantic-forms.cc:9111/
In shell server side, I did a kill -3 to get the threads dump,
and there are 8 occurences of the same pattern in bold:
"application-akka.actor.default-dispatcher-13" #38 prio=5 os_prio=0
tid=0x00007fdb74007000 nid=0x5f5f waiting on condition [0x00007fdb881b8000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000f3f42378> (a
java.util.concurrent.Semaphore$FairSync)
Some other thread is holding the permit that control the number of writers.
The WriterLock is a Semaphore with one permit.
The question becomes who has the permit and are they making progress
Note - the lock is not re-entrant. begin-begin on the same thread will
deadlock (in case Akka is being clever about actors to threads).
Andy
* 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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at
org.apache.jena.dboe.transaction.txn.TransactionCoordinator.acquireWriterLock(TransactionCoordinator.java:305)
at
org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:483)
at
org.apache.jena.dboe.transaction.txn.TransactionCoordinator.begin(TransactionCoordinator.java:450)
at
org.apache.jena.dboe.transaction.txn.TransactionalBase.begin(TransactionalBase.java:101)
at
org.apache.jena.tdb2.store.DatasetGraphTDB.begin(DatasetGraphTDB.java:418)
at
org.apache.jena.sparql.core.DatasetGraphWrapper.begin(DatasetGraphWrapper.java:187)
at
org.apache.jena.sparql.core.DatasetGraphWrapper.begin(DatasetGraphWrapper.java:187)
at
org.apache.jena.query.text.DatasetGraphText.begin(DatasetGraphText.java:115)
at
org.apache.jena.sparql.core.DatasetImpl.begin(DatasetImpl.java:111)
at
org.w3.banana.jena.JenaDatasetStore$$anonfun$rw$1.apply(JenaDatasetStore.scala:23)
at scala.util.Try$.apply(Try.scala:192) at
org.w3.banana.jena.JenaDatasetStore.rw
<http://org.w3.banana.jena.JenaDatasetStore.rw>(JenaDatasetStore.scala:22)
at org.w3.banana.jena.JenaDatasetStore.rw
<http://org.w3.banana.jena.JenaDatasetStore.rw>(JenaDatasetStore.scala:10)*
at
deductions.runtime.services.ApplicationFacadeImpl$class.labelForURITransaction(ApplicationFacadeImpl.scala:107)
at
controllers.Application$.labelForURITransaction(Application.scala:8)
at
controllers.WebPages$MainPagePrecomputePlay.<init>(WebPages.scala:46)
at
controllers.WebPages$MainPagePrecomputePlay$.apply(WebPages.scala:39)
at
controllers.WebPages$$anonfun$outputMainPageWithContent$1.apply(WebPages.scala:64)
at
controllers.WebPages$$anonfun$outputMainPageWithContent$1.apply(WebPages.scala:63)
at
play.api.mvc.ActionBuilder$$anonfun$apply$13.apply(Action.scala:371)
It looks like a dead lock.
The main database, concerned by these stacks, is not big: 181,799 quads.
uname -a
Linux scw-80de9e 4.5.7-std-3 #1 SMP Tue Jul 12 09:56:30 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
$ java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
I restarted the server, so that anyone can try.
I forgot to say that the code changes are very limited:
- switch for TDB2
val dts =
if (useTDB2)
org.apache.jena.tdb2.TDB2Factory.connectDataset(database_location)
else
TDBFactory.createDataset(Paths.get(database_location).toString())
- move an iterator inside a transaction after initial problem reported
in first mail
2017-11-15 17:46 GMT+01:00 Andy Seaborne <[email protected]>:
Jean-Marc,
Thank you for the report!
On 15/11/17 11:18, Jean-Marc Vanel wrote:
Hi
I started to test TBD2 on my application semantic_forms .
I dumped the 3 databases with the TDB (1) tool,
then loaded with the TDB 2 tool :
runMain tdb2.tdbloader --loc TDB --verbose
/home/jmv/src/semantic_forms/scala/dump.nq
there where some bad quads with a literal subject from old bugs, that I
had
to manually edit out , but not a big deal.
At runtime many things work, but I had one runtime error in /authenticate
:
*[TransactionException: Iterator used outside its original transaction]*
yes - it's pickier than TDB1 :-)
Indeed , this is exactly that:
https://github.com/jmvanel/semantic_forms/blob/master/scala/
forms/src/main/scala/deductions/runtime/services/Authentication.scala#L66
See Txn.calculateRead for executing a transaction and return a value.
This was on my laptop.
I'll fix the code, which seems to be changes compatible with old TDB.
Then I'll upgrade to TDB2 on the sandbox, then on the real site.
Hope I don't bother you with non complete report .
Not at all.
Andy
