You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Bryan Thompson <br...@systap.com> on 2012/02/06 22:03:25 UTC
Interrupt propagated to wrong thread?
I am curious whether there is any known problem where an interrupt could be propagated into the wrong thread by the jini/river library (this is against river 2.2), or perhaps retained across the reuse of a thread for another task.
The critical bit of the stack trace that I am seeing is:
Caused by: java.io.IOException: request I/O interrupted
at com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Session.java:833)
at net.jini.jeri.connection.ConnectionManager$Outbound$Input.read(ConnectionManager.java:550)
at net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpoint.java:410)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:806)
... 12 more
There are definitely times when we interrupt operations, but I am having a very difficult time finding a reason why an interrupt would have been generated during this phase of query processing by our application. However, there are heavy concurrent operations going on which could cause interrupts. Is it possible that the interrupt is being propagated into another thread by mistake?
The full stack trace is:
java.util.concurrent.ExecutionException: java.rmi.UnmarshalException: exception unmarshalling response; nested exception is:
java.io.IOException: request I/O interrupted
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at com.bigdata.service.ndx.ClientIndexView.runParallel(ClientIndexView.java:1742)
at com.bigdata.service.ndx.ClientIndexView.runTasks(ClientIndexView.java:1656)
at com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView.java:1421)
at com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView.java:1338)
at com.bigdata.service.ndx.ClientIndexView.rangeCount(ClientIndexView.java:609)
at com.bigdata.relation.accesspath.AccessPath.historicalRangeCount(AccessPath.java:1357)
at com.bigdata.relation.accesspath.AccessPath.rangeCount(AccessPath.java:1325)
at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.attachRangeCounts(ASTStaticJoinOptimizer.java:510)
at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:312)
at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:457)
at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:457)
at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:179)
at com.bigdata.rdf.sparql.ast.optimizers.ASTOptimizerList.optimize(ASTOptimizerList.java:92)
at com.bigdata.rdf.sparql.ast.eval.AST2BOpUtility.convert(AST2BOpUtility.java:193)
at com.bigdata.rdf.sparql.ast.eval.ASTEvalHelper.evaluateGraphQuery(ASTEvalHelper.java:314)
at com.bigdata.rdf.sail.BigdataSailGraphQuery.evaluate(BigdataSailGraphQuery.java:91)
at org.openrdf.repository.sail.SailGraphQuery.evaluate(SailGraphQuery.java:102)
at com.bigdata.rdf.sail.webapp.BigdataRDFContext$GraphQueryTask.doQuery(BigdataRDFContext.java:799)
at com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.call(BigdataRDFContext.java:632)
at com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.call(BigdataRDFContext.java:280)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.rmi.UnmarshalException: exception unmarshalling response; nested exception is:
java.io.IOException: request I/O interrupted
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:847)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:659)
at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
at $Proxy3.submit(Unknown Source)
at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submit(AbstractDataServiceProcedureTask.java:348)
at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submit(AbstractDataServiceProcedureTask.java:292)
at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(AbstractDataServiceProcedureTask.java:215)
at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(AbstractDataServiceProcedureTask.java:45)
... 5 more
Caused by: java.io.IOException: request I/O interrupted
at com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Session.java:833)
at net.jini.jeri.connection.ConnectionManager$Outbound$Input.read(ConnectionManager.java:550)
at net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpoint.java:410)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:806)
... 12 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Session.java:829)
... 15 more
Re: Interrupt propagated to wrong thread?
Posted by Peter Firmstone <ji...@zeus.net.au>.
You're welcome.
N.B. You'll need to install the patched version of river on the remote
jvm node, where the stack trace originates from.
Peter.
Bryan Thompson wrote:
> Peter,
>
> I'll build from source and apply the patch. Tomorrow will be pretty hectic, but I will try to run through this on Wednesday.
>
> Thanks,
> Bryan
>
>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au]
>> Sent: Monday, February 06, 2012 5:41 PM
>> To: dev@river.apache.org
>> Cc: Bryan Thompson
>> Subject: Re: Interrupt propagated to wrong thread?
>>
>> Well, not to my knowledge, anything could be interrupting the
>> thread (because it's waiting) on the remote machine which is
>> propagating it as an IOException.
>>
>> So we don't know in this case what caused the interruption,
>> as that stack trace is missing.
>>
>> Do you have logging activated at the remote end?
>>
>> I've attached a patch that will record the stack trace, which
>> should identify interrupt cause.
>>
>> But you'll need to build River from source.
>>
>> Alternatively I can commit the patch and you can pick up a
>> Hudson build?
>>
>> Regards,
>>
>> Peter.
>>
>>
>> Bryan Thompson wrote:
>>
>>> I am curious whether there is any known problem where an
>>>
>> interrupt could be propagated into the wrong thread by the
>> jini/river library (this is against river 2.2), or perhaps
>> retained across the reuse of a thread for another task.
>>
>>> The critical bit of the stack trace that I am seeing is:
>>>
>>> Caused by: java.io.IOException: request I/O interrupted
>>> at
>>>
>> com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Ses
>> sion.java:833)
>>
>>> at
>>>
>> net.jini.jeri.connection.ConnectionManager$Outbound$Input.read
>>
> (ConnectionManager.java:550)
>
>>> at
>>>
>> net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpo
>> int.java:410)
>>
>>> at
>>>
>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Ba
>> sicInvocationHandler.java:806)
>>
>>> ... 12 more
>>>
>>> There are definitely times when we interrupt operations,
>>>
>> but I am having a very difficult time finding a reason why an
>> interrupt would have been generated during this phase of
>> query processing by our application. However, there are
>> heavy concurrent operations going on which could cause
>> interrupts. Is it possible that the interrupt is being
>> propagated into another thread by mistake?
>>
>>> The full stack trace is:
>>>
>>> java.util.concurrent.ExecutionException:
>>>
>> java.rmi.UnmarshalException: exception unmarshalling
>> response; nested exception is:
>>
>>> java.io.IOException: request I/O interrupted
>>> at
>>>
>> java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>>
>>> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>>> at
>>>
>> com.bigdata.service.ndx.ClientIndexView.runParallel(ClientInde
>> xView.java:1742)
>>
>>> at
>>>
>> com.bigdata.service.ndx.ClientIndexView.runTasks(ClientIndexVi
>> ew.java:1656)
>>
>>> at
>>>
>> com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView
>> .java:1421)
>>
>>> at
>>>
>> com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView
>> .java:1338)
>>
>>> at
>>>
>> com.bigdata.service.ndx.ClientIndexView.rangeCount(ClientIndex
>> View.java:609)
>>
>>> at
>>>
>> com.bigdata.relation.accesspath.AccessPath.historicalRangeCoun
>> t(AccessPath.java:1357)
>>
>>> at
>>>
>> com.bigdata.relation.accesspath.AccessPath.rangeCount(AccessPa
>> th.java:1325)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.a
>> ttachRangeCounts(ASTStaticJoinOptimizer.java:510)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
>> ptimize(ASTStaticJoinOptimizer.java:312)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
>> ptimize(ASTStaticJoinOptimizer.java:457)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
>> ptimize(ASTStaticJoinOptimizer.java:457)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
>> ptimize(ASTStaticJoinOptimizer.java:179)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.optimizers.ASTOptimizerList.optimiz
>> e(ASTOptimizerList.java:92)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.eval.AST2BOpUtility.convert(AST2BOp
>> Utility.java:193)
>>
>>> at
>>>
>> com.bigdata.rdf.sparql.ast.eval.ASTEvalHelper.evaluateGraphQue
>> ry(ASTEvalHelper.java:314)
>>
>>> at
>>>
>> com.bigdata.rdf.sail.BigdataSailGraphQuery.evaluate(BigdataSai
>> lGraphQuery.java:91)
>>
>>> at
>>>
>> org.openrdf.repository.sail.SailGraphQuery.evaluate(SailGraphQ
>> uery.java:102)
>>
>>> at
>>>
>> com.bigdata.rdf.sail.webapp.BigdataRDFContext$GraphQueryTask.d
>> oQuery(BigdataRDFContext.java:799)
>>
>>> at
>>>
>> com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTas
>> k.call(BigdataRDFContext.java:632)
>>
>>> at
>>>
>> com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTas
>> k.call(BigdataRDFContext.java:280)
>>
>>> at
>>>
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>> at
>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
>> oolExecutor.java:886)
>>
>>> at
>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
>> xecutor.java:908)
>>
>>> at java.lang.Thread.run(Thread.java:662)
>>> Caused by: java.rmi.UnmarshalException: exception
>>>
>> unmarshalling response; nested exception is:
>>
>>> java.io.IOException: request I/O interrupted
>>> at
>>>
>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Ba
>> sicInvocationHandler.java:847)
>>
>>> at
>>>
>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicI
>> nvocationHandler.java:659)
>>
>>> at
>>>
>> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHan
>> dler.java:528)
>>
>>> at $Proxy3.submit(Unknown Source)
>>> at
>>>
>> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submi
>> t(AbstractDataServiceProcedureTask.java:348)
>>
>>> at
>>>
>> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submi
>> t(AbstractDataServiceProcedureTask.java:292)
>>
>>> at
>>>
>> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(
>> AbstractDataServiceProcedureTask.java:215)
>>
>>> at
>>>
>> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(
>> AbstractDataServiceProcedureTask.java:45)
>>
>>> ... 5 more
>>> Caused by: java.io.IOException: request I/O interrupted
>>> at
>>>
>> com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Ses
>> sion.java:833)
>>
>>> at
>>>
>> net.jini.jeri.connection.ConnectionManager$Outbound$Input.read
>>
> (ConnectionManager.java:550)
>
>>> at
>>>
>> net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpo
>> int.java:410)
>>
>>> at
>>>
>> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Ba
>> sicInvocationHandler.java:806)
>>
>>> ... 12 more
>>> Caused by: java.lang.InterruptedException
>>> at java.lang.Object.wait(Native Method)
>>> at java.lang.Object.wait(Object.java:485)
>>> at
>>>
>> com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Ses
>> sion.java:829)
>>
>>> ... 15 more
>>>
>>>
>>>
>>
RE: Interrupt propagated to wrong thread?
Posted by Bryan Thompson <br...@systap.com>.
Peter,
I'll build from source and apply the patch. Tomorrow will be pretty hectic, but I will try to run through this on Wednesday.
Thanks,
Bryan
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Monday, February 06, 2012 5:41 PM
> To: dev@river.apache.org
> Cc: Bryan Thompson
> Subject: Re: Interrupt propagated to wrong thread?
>
> Well, not to my knowledge, anything could be interrupting the
> thread (because it's waiting) on the remote machine which is
> propagating it as an IOException.
>
> So we don't know in this case what caused the interruption,
> as that stack trace is missing.
>
> Do you have logging activated at the remote end?
>
> I've attached a patch that will record the stack trace, which
> should identify interrupt cause.
>
> But you'll need to build River from source.
>
> Alternatively I can commit the patch and you can pick up a
> Hudson build?
>
> Regards,
>
> Peter.
>
>
> Bryan Thompson wrote:
> > I am curious whether there is any known problem where an
> interrupt could be propagated into the wrong thread by the
> jini/river library (this is against river 2.2), or perhaps
> retained across the reuse of a thread for another task.
> >
> > The critical bit of the stack trace that I am seeing is:
> >
> > Caused by: java.io.IOException: request I/O interrupted
> > at
> com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Ses
> sion.java:833)
> > at
> net.jini.jeri.connection.ConnectionManager$Outbound$Input.read
(ConnectionManager.java:550)
> > at
> net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpo
> int.java:410)
> > at
> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Ba
> sicInvocationHandler.java:806)
> > ... 12 more
> >
> > There are definitely times when we interrupt operations,
> but I am having a very difficult time finding a reason why an
> interrupt would have been generated during this phase of
> query processing by our application. However, there are
> heavy concurrent operations going on which could cause
> interrupts. Is it possible that the interrupt is being
> propagated into another thread by mistake?
> >
> > The full stack trace is:
> >
> > java.util.concurrent.ExecutionException:
> java.rmi.UnmarshalException: exception unmarshalling
> response; nested exception is:
> > java.io.IOException: request I/O interrupted
> > at
> java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> > at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> > at
> com.bigdata.service.ndx.ClientIndexView.runParallel(ClientInde
> xView.java:1742)
> > at
> com.bigdata.service.ndx.ClientIndexView.runTasks(ClientIndexVi
> ew.java:1656)
> > at
> com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView
> .java:1421)
> > at
> com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView
> .java:1338)
> > at
> com.bigdata.service.ndx.ClientIndexView.rangeCount(ClientIndex
> View.java:609)
> > at
> com.bigdata.relation.accesspath.AccessPath.historicalRangeCoun
> t(AccessPath.java:1357)
> > at
> com.bigdata.relation.accesspath.AccessPath.rangeCount(AccessPa
> th.java:1325)
> > at
> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.a
> ttachRangeCounts(ASTStaticJoinOptimizer.java:510)
> > at
> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
> ptimize(ASTStaticJoinOptimizer.java:312)
> > at
> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
> ptimize(ASTStaticJoinOptimizer.java:457)
> > at
> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
> ptimize(ASTStaticJoinOptimizer.java:457)
> > at
> com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.o
> ptimize(ASTStaticJoinOptimizer.java:179)
> > at
> com.bigdata.rdf.sparql.ast.optimizers.ASTOptimizerList.optimiz
> e(ASTOptimizerList.java:92)
> > at
> com.bigdata.rdf.sparql.ast.eval.AST2BOpUtility.convert(AST2BOp
> Utility.java:193)
> > at
> com.bigdata.rdf.sparql.ast.eval.ASTEvalHelper.evaluateGraphQue
> ry(ASTEvalHelper.java:314)
> > at
> com.bigdata.rdf.sail.BigdataSailGraphQuery.evaluate(BigdataSai
> lGraphQuery.java:91)
> > at
> org.openrdf.repository.sail.SailGraphQuery.evaluate(SailGraphQ
> uery.java:102)
> > at
> com.bigdata.rdf.sail.webapp.BigdataRDFContext$GraphQueryTask.d
> oQuery(BigdataRDFContext.java:799)
> > at
> com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTas
> k.call(BigdataRDFContext.java:632)
> > at
> com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTas
> k.call(BigdataRDFContext.java:280)
> > at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
> oolExecutor.java:886)
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
> xecutor.java:908)
> > at java.lang.Thread.run(Thread.java:662)
> > Caused by: java.rmi.UnmarshalException: exception
> unmarshalling response; nested exception is:
> > java.io.IOException: request I/O interrupted
> > at
> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Ba
> sicInvocationHandler.java:847)
> > at
> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicI
> nvocationHandler.java:659)
> > at
> net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHan
> dler.java:528)
> > at $Proxy3.submit(Unknown Source)
> > at
> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submi
> t(AbstractDataServiceProcedureTask.java:348)
> > at
> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submi
> t(AbstractDataServiceProcedureTask.java:292)
> > at
> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(
> AbstractDataServiceProcedureTask.java:215)
> > at
> com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(
> AbstractDataServiceProcedureTask.java:45)
> > ... 5 more
> > Caused by: java.io.IOException: request I/O interrupted
> > at
> com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Ses
> sion.java:833)
> > at
> net.jini.jeri.connection.ConnectionManager$Outbound$Input.read
(ConnectionManager.java:550)
> > at
> net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpo
> int.java:410)
> > at
> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Ba
> sicInvocationHandler.java:806)
> > ... 12 more
> > Caused by: java.lang.InterruptedException
> > at java.lang.Object.wait(Native Method)
> > at java.lang.Object.wait(Object.java:485)
> > at
> com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Ses
> sion.java:829)
> > ... 15 more
> >
> >
>
>
Re: Interrupt propagated to wrong thread?
Posted by Peter Firmstone <ji...@zeus.net.au>.
Well, not to my knowledge, anything could be interrupting the thread
(because it's waiting) on the remote machine which is propagating it as
an IOException.
So we don't know in this case what caused the interruption, as that
stack trace is missing.
Do you have logging activated at the remote end?
I've attached a patch that will record the stack trace, which should
identify interrupt cause.
But you'll need to build River from source.
Alternatively I can commit the patch and you can pick up a Hudson build?
Regards,
Peter.
Bryan Thompson wrote:
> I am curious whether there is any known problem where an interrupt could be propagated into the wrong thread by the jini/river library (this is against river 2.2), or perhaps retained across the reuse of a thread for another task.
>
> The critical bit of the stack trace that I am seeing is:
>
> Caused by: java.io.IOException: request I/O interrupted
> at com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Session.java:833)
> at net.jini.jeri.connection.ConnectionManager$Outbound$Input.read(ConnectionManager.java:550)
> at net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpoint.java:410)
> at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:806)
> ... 12 more
>
> There are definitely times when we interrupt operations, but I am having a very difficult time finding a reason why an interrupt would have been generated during this phase of query processing by our application. However, there are heavy concurrent operations going on which could cause interrupts. Is it possible that the interrupt is being propagated into another thread by mistake?
>
> The full stack trace is:
>
> java.util.concurrent.ExecutionException: java.rmi.UnmarshalException: exception unmarshalling response; nested exception is:
> java.io.IOException: request I/O interrupted
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at com.bigdata.service.ndx.ClientIndexView.runParallel(ClientIndexView.java:1742)
> at com.bigdata.service.ndx.ClientIndexView.runTasks(ClientIndexView.java:1656)
> at com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView.java:1421)
> at com.bigdata.service.ndx.ClientIndexView.submit(ClientIndexView.java:1338)
> at com.bigdata.service.ndx.ClientIndexView.rangeCount(ClientIndexView.java:609)
> at com.bigdata.relation.accesspath.AccessPath.historicalRangeCount(AccessPath.java:1357)
> at com.bigdata.relation.accesspath.AccessPath.rangeCount(AccessPath.java:1325)
> at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.attachRangeCounts(ASTStaticJoinOptimizer.java:510)
> at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:312)
> at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:457)
> at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:457)
> at com.bigdata.rdf.sparql.ast.optimizers.ASTStaticJoinOptimizer.optimize(ASTStaticJoinOptimizer.java:179)
> at com.bigdata.rdf.sparql.ast.optimizers.ASTOptimizerList.optimize(ASTOptimizerList.java:92)
> at com.bigdata.rdf.sparql.ast.eval.AST2BOpUtility.convert(AST2BOpUtility.java:193)
> at com.bigdata.rdf.sparql.ast.eval.ASTEvalHelper.evaluateGraphQuery(ASTEvalHelper.java:314)
> at com.bigdata.rdf.sail.BigdataSailGraphQuery.evaluate(BigdataSailGraphQuery.java:91)
> at org.openrdf.repository.sail.SailGraphQuery.evaluate(SailGraphQuery.java:102)
> at com.bigdata.rdf.sail.webapp.BigdataRDFContext$GraphQueryTask.doQuery(BigdataRDFContext.java:799)
> at com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.call(BigdataRDFContext.java:632)
> at com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.call(BigdataRDFContext.java:280)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.rmi.UnmarshalException: exception unmarshalling response; nested exception is:
> java.io.IOException: request I/O interrupted
> at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:847)
> at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:659)
> at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
> at $Proxy3.submit(Unknown Source)
> at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submit(AbstractDataServiceProcedureTask.java:348)
> at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.submit(AbstractDataServiceProcedureTask.java:292)
> at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(AbstractDataServiceProcedureTask.java:215)
> at com.bigdata.service.ndx.AbstractDataServiceProcedureTask.call(AbstractDataServiceProcedureTask.java:45)
> ... 5 more
> Caused by: java.io.IOException: request I/O interrupted
> at com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Session.java:833)
> at net.jini.jeri.connection.ConnectionManager$Outbound$Input.read(ConnectionManager.java:550)
> at net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpoint.java:410)
> at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:806)
> ... 12 more
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:485)
> at com.sun.jini.jeri.internal.mux.Session$MuxInputStream.read(Session.java:829)
> ... 15 more
>
>