river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Interrupt propagated to wrong thread?
Date Mon, 06 Feb 2012 22:58:36 GMT
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
>>>
>>>   
>>>       
>>     


Mime
View raw message