[Swift-devel] Re: hanging workflow

[Mihael Hategan]

On Mon, 2007-04-30 at 15:44 +0000, Ben Clifford wrote:
> ok, so:
> 
> > threads
> Group system:
>   (java.lang.ref.Reference$ReferenceHandler)0x111               Reference 
> Handler cond. waiting
>   (java.lang.ref.Finalizer$FinalizerThread)0x110                Finalizer         
> cond. waiting
>   (java.lang.Thread)0x112                                       Signal 
> Dispatcher running
> Group main:
>   (java.lang.Thread)0x1                                         main              
> cond. waiting
>   (org.globus.cog.karajan.workflow.events.EventWorker)0x269     Worker 0          
> cond. waiting
>   (org.globus.cog.karajan.workflow.events.EventWorker)0x26a     Worker 1          
> cond. waiting
>   (java.util.TimerThread)0x270                                  Timer-0           
> cond. waiting
>   (org.globus.cog.karajan.workflow.events.EventDispatcher)0x274 
> EventDispatcher   cond. waiting
>   (java.lang.Thread)0x4fa                                       Thread-4          
> running
>   (java.lang.Thread)0x506                                       Thread-5          
> sleeping
>   (org.griphyn.vdl.karajan.VDSAdaptiveScheduler)0x526           Scheduler         
> cond. waiting
>   (java.util.TimerThread)0x567                                  Timer-1           
> cond. waiting
>   (java.lang.Thread)0x5cc                                       
> pool-1-thread-3   cond. waiting
>   (java.lang.Thread)0x5cf                                       
> pool-1-thread-4   cond. waiting
> > 
> 
> 
> The oh so delightfully names Thread-4 appears sitting in running state all 
> the time (from typing 'threads' three times), and Thread-5 sits in 
> sleeping state.

Both of those are noops. One of them is the one waiting for input on
stdin, and the other one is an equivalent thing waiting for a telnet
connection.

The workers are essential. They do the actual stuff, and they seem to be
waiting (which means nothing is running). The scheduler is also
sleeping. So I can't tell much from this.

> 
> and:
> 
> Thread-4[1] where
>   [1] java.net.PlainSocketImpl.socketAccept (native method)
>   [2] java.net.PlainSocketImpl.accept (PlainSocketImpl.java:384)
>   [3] java.net.ServerSocket.implAccept (ServerSocket.java:450)
>   [4] java.net.ServerSocket.accept (ServerSocket.java:421)
>   [5] org.griphyn.vdl.karajan.Monitor$Service.run (Monitor.java:428)
>   [6] java.lang.Thread.run (Thread.java:613)
> 
> Thread-5[1] where
>   [1] java.lang.Thread.sleep (native method)
>   [2] org.griphyn.vdl.karajan.InHook.run (InHook.java:54)
>   [3] java.lang.Thread.run (Thread.java:613)
> 
> Let me know what else you want...

I wish I knew.
There are two things to consider:
Are there any swift/karajan threads blocked and why (the 't' 'enter'
should have clarified that). Alternately you can try logging into the
monitor service and type the same ('t' 'enter'). You'll find the port
with netstat.

>