Is it possible for an IConnection to terminate but a submit()'ed request still to be stuck in its waitForCompletion? I seem to be getting such a case, but it is possibly related to the situation in my previous post (in this case, as in that one, all the onDataEnd()'s were called, but not all the waitForCompletion()'s returned. Unlike that case, here after some time the IConnection itself apparently broke.)
"Finalizer" daemon prio=10 tid=0x0000002cb4417000 nid=0x4a2d in Object.wait() [0x0000000040d36000..0x0000000040d36350]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000002aa0dcfa50> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x0000002aa0dcfa50> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x0000002cb4416400 nid=0x4a2c in Object.wait() [0x0000000040c35000..0x0000000040c353d0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x0000002aa0dcd4d0> (a java.lang.ref.Reference$Lock)
"main" prio=10 tid=0x0000000040113400 nid=0x4a22 in Object.wait() [0x000000004022b000..0x000000004022b590]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.otfeed.protocol.request.RequestJob.waitForCompletion(RequestJob.java:118)
- locked <0x0000002a9f4dfd68> (a java.util.concurrent.atomic.AtomicBoolean)
at org.otfeed.protocol.connector.OTEngine$RequestHandler.waitForCompletion(OTEngine.java:99)
at com.test.tester.HistTicksNew.processData(HistTicksNew.java:201)
at com.test.tester.HistTicksNew.main(HistTicksNew.java:268)
"VM Periodic Task Thread" prio=10 tid=0x0000002cb46c6400 nid=0x4a32 waiting on condition
JNI global references: 697
Heap
PSYoungGen total 1798144K, used 881238K [0x0000002c015b0000, 0x0000002caace0000, 0x0000002cb2700000)
eden space 854464K, 73% used [0x0000002c015b0000,0x0000002c27e35b50,0x0000002c35820000)
from space 943680K, 26% used [0x0000002c35820000,0x0000002c44c30000,0x0000002c6f1b0000)
to space 914432K, 0% used [0x0000002c72fe0000,0x0000002c72fe0000,0x0000002caace0000)
PSOldGen total 4775936K, used 3914239K [0x0000002a9f300000, 0x0000002bc2b00000, 0x0000002c015b0000)
object space 4775936K, 81% used [0x0000002a9f300000,0x0000002b8e17fff8,0x0000002bc2b00000)
PSPermGen total 21248K, used 5622K [0x0000002a99f00000, 0x0000002a9b3c0000, 0x0000002a9f300000)
object space 21248K, 26% used [0x0000002a99f00000,0x0000002a9a47db28,0x0000002a9b3c0000)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, it should not be possible. Still, I can not swear that the code is free of bugs. Lets get a minimal manageable reproduction for the problem. I hope you are running it stand-alone, not from a container (some containers do not like application threads).
-Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible for an IConnection to terminate but a submit()'ed request still to be stuck in its waitForCompletion? I seem to be getting such a case, but it is possibly related to the situation in my previous post (in this case, as in that one, all the onDataEnd()'s were called, but not all the waitForCompletion()'s returned. Unlike that case, here after some time the IConnection itself apparently broke.)
Thanks.
----
Connection terminated: OTError: requestId=0, code=5001, desc=io exception in reader: read error
2008-03-01 11:43:46
Full thread dump Java HotSpot(TM) 64-Bit Server VM (1.6.0_02-b05 mixed mode):
"Low Memory Detector" daemon prio=10 tid=0x0000002cb46c4800 nid=0x4a31 runnable [0x0000000000000000..0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread1" daemon prio=10 tid=0x0000002cb46c2000 nid=0x4a30 waiting on condition [0x0000000000000000..0x00000000410381c0]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x0000002cb46c0400 nid=0x4a2f waiting on condition [0x0000000000000000..0x0000000040f371b0]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x0000002cb46bf000 nid=0x4a2e waiting on condition [0x0000000000000000..0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=10 tid=0x0000002cb4417000 nid=0x4a2d in Object.wait() [0x0000000040d36000..0x0000000040d36350]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000002aa0dcfa50> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x0000002aa0dcfa50> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x0000002cb4416400 nid=0x4a2c in Object.wait() [0x0000000040c35000..0x0000000040c353d0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x0000002aa0dcd4d0> (a java.lang.ref.Reference$Lock)
"main" prio=10 tid=0x0000000040113400 nid=0x4a22 in Object.wait() [0x000000004022b000..0x000000004022b590]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.otfeed.protocol.request.RequestJob.waitForCompletion(RequestJob.java:118)
- locked <0x0000002a9f4dfd68> (a java.util.concurrent.atomic.AtomicBoolean)
at org.otfeed.protocol.connector.OTEngine$RequestHandler.waitForCompletion(OTEngine.java:99)
at com.test.tester.HistTicksNew.processData(HistTicksNew.java:201)
at com.test.tester.HistTicksNew.main(HistTicksNew.java:268)
"VM Thread" prio=10 tid=0x0000002cb4411800 nid=0x4a2b runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000004011d800 nid=0x4a23 runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x000000004011ec00 nid=0x4a24 runnable
"GC task thread#2 (ParallelGC)" prio=10 tid=0x0000000040120000 nid=0x4a25 runnable
"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000040121400 nid=0x4a26 runnable
"GC task thread#4 (ParallelGC)" prio=10 tid=0x0000000040122800 nid=0x4a27 runnable
"GC task thread#5 (ParallelGC)" prio=10 tid=0x0000000040123800 nid=0x4a28 runnable
"GC task thread#6 (ParallelGC)" prio=10 tid=0x0000000040124c00 nid=0x4a29 runnable
"GC task thread#7 (ParallelGC)" prio=10 tid=0x0000000040126000 nid=0x4a2a runnable
"VM Periodic Task Thread" prio=10 tid=0x0000002cb46c6400 nid=0x4a32 waiting on condition
JNI global references: 697
Heap
PSYoungGen total 1798144K, used 881238K [0x0000002c015b0000, 0x0000002caace0000, 0x0000002cb2700000)
eden space 854464K, 73% used [0x0000002c015b0000,0x0000002c27e35b50,0x0000002c35820000)
from space 943680K, 26% used [0x0000002c35820000,0x0000002c44c30000,0x0000002c6f1b0000)
to space 914432K, 0% used [0x0000002c72fe0000,0x0000002c72fe0000,0x0000002caace0000)
PSOldGen total 4775936K, used 3914239K [0x0000002a9f300000, 0x0000002bc2b00000, 0x0000002c015b0000)
object space 4775936K, 81% used [0x0000002a9f300000,0x0000002b8e17fff8,0x0000002bc2b00000)
PSPermGen total 21248K, used 5622K [0x0000002a99f00000, 0x0000002a9b3c0000, 0x0000002a9f300000)
object space 21248K, 26% used [0x0000002a99f00000,0x0000002a9a47db28,0x0000002a9b3c0000)
No, it should not be possible. Still, I can not swear that the code is free of bugs. Lets get a minimal manageable reproduction for the problem. I hope you are running it stand-alone, not from a container (some containers do not like application threads).
-Mike