[Mulgara-dev] Sporadic exception from MulgaraTransactionFactory.acquireMutex

Paul Gearon gearon at ieee.org
Fri Aug 22 20:49:48 UTC 2008 

I can't say this for sure, but this MAY have been fixed.

A concurrency bug got fixed between 2.0.1 and 2.0.2, and Fedora was
built using 2.0.1.  The line of code that reports the exception has
been updated in the latest release, so it looks like the bugfix that
occurred was directly related to this.

I haven't set up Fedora before (even though I work for them). Do you
know if you can pull in Mulgara 2.0.2 and run that instead of the
existing one? If that proves to be difficult, let me know and I'll ask
how to do it from the Fedora developers.

Paul

On Fri, Aug 22, 2008 at 2:57 PM, Morten Grouleff <mgr at trifork.com> wrote:
> I'm unsure if this is a Mulgara or Fedora  problem, but my best bet is Mulgara.
>
> We're using the Mulgara embedded inside Fedora. When running many itql queryes in parallel through the "risearch"
> interface in fedora, we sometimes get this stacktrace in the fedora server log, but only a few times out of the 1849
> calls. The queries are identical, apart from a parameter. If I run the same sequence of queries sequentially, no
> exceptions occur.
>
> INFO 2008-08-22 19:58:35.150 [http-8080-Processor170] (Cache) Authenticating user [fedoraAdmin]
> ERROR 2008-08-22 19:58:35.177 [http-8080-Processor293] (RISearchServlet) Unexpected error servicing API-A request
> org.trippi.TrippiException: Interrupted while waiting to acquire lock
>         at org.trippi.impl.mulgara.MulgaraTupleIterator.<init>(MulgaraTupleIterator.java:27)
>         at org.trippi.impl.mulgara.MulgaraSession.query(MulgaraSession.java:138)
>         at org.trippi.impl.base.ConcurrentTriplestoreReader.findTuples(ConcurrentTriplestoreReader.java:79)
>         at fedora.server.resourceIndex.ResourceIndexImpl.findTuples(ResourceIndexImpl.java:280)
>         at fedora.server.resourceIndex.ResourceIndexModule.findTuples(ResourceIndexModule.java:297)
>         at org.trippi.server.TrippiServer.find(TrippiServer.java:119)
>         at org.trippi.server.http.TrippiServlet.doFind(TrippiServlet.java:512)
>         at org.trippi.server.http.TrippiServlet.doGet(TrippiServlet.java:377)
>         at fedora.server.access.RISearchServlet.doGet(RISearchServlet.java:99)
>         at org.trippi.server.http.TrippiServlet.doGet(TrippiServlet.java:269)
>         at org.trippi.server.http.TrippiServlet.doPost(TrippiServlet.java:572)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>         at fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>         at fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>         at fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>         at fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
>         at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
>         at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: org.mulgara.query.TuplesException: Interrupted while waiting to acquire lock
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>         at org.mulgara.resolver.MulgaraTransactionFactory.newException(MulgaraTransactionFactory.java:342)
>         at org.mulgara.resolver.MulgaraTransactionFactory.newExceptionOrCause(MulgaraTransactionFactory.java:351)
>         at org.mulgara.resolver.MulgaraTransactionFactory.acquireMutex(MulgaraTransactionFactory.java:278)
>         at org.mulgara.resolver.MulgaraInternalTransaction.acquireMutex(MulgaraInternalTransaction.java:763)
>         at org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:642)
>         at org.mulgara.resolver.TransactionalAnswer.beforeFirst(TransactionalAnswer.java:104)
>         at org.trippi.impl.mulgara.RowGroup.initialize(RowGroup.java:48)
>         at org.trippi.impl.mulgara.RowGroup.<init>(RowGroup.java:33)
>         at org.trippi.impl.mulgara.CollapsedAnswer.initialize(CollapsedAnswer.java:74)
>         at org.trippi.impl.mulgara.CollapsedAnswer.<init>(CollapsedAnswer.java:58)
>         at org.trippi.impl.mulgara.MulgaraTupleIterator.<init>(MulgaraTupleIterator.java:24)
>         ... 39 more
> Caused by: java.lang.InterruptedException
>         at java.lang.Object.wait(Native Method)
>         at org.mulgara.resolver.MulgaraTransactionFactory.acquireMutex(MulgaraTransactionFactory.java:276)
>         ... 47 more
>
> Is it a part of Mulgara that interrupts another thread? Or should I look elsewhere for the "interrupting party"?
>
> Any suggestions?
> --
> Regards,
> Morten Grouleff
> --------------------------------------------------------------------
> Trifork A/S,  Margrethepladsen 4, DK-8000 Aarhus C, Denmark.
> JAOO 2008: Sep. 28. - Oct. 3. 2008  http://jaoo.dk/   See you there?
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
>

More information about the Mulgara-dev mailing list