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)

















*        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
>



-- 
Jean-Marc Vanel
http://www.semantic-forms.cc:9111/display?displayuri=http://jmvanel.free.fr/jmv.rdf%23me#subject
<http://www.semantic-forms.cc:9111/display?displayuri=http://jmvanel.free.fr/jmv.rdf%23me>
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
+33 (0)6 89 16 29 52
Twitter: @jmvanel , @jmvanel_fr ; chat: irc://irc.freenode.net#eulergui

Reply via email to