|
From: Christopher T. <ct...@co...> - 2010-11-22 09:29:39
|
Hi all,
I'm forwarding this on behalf of Johannes, he seems to be having
problems with his list subscription.
--- snip ---
I am using ServiceWrapper (stable version 3.5.6) under 32bit CentOS 5 in
a VM with 2 CPUs.
Whenever I stopped a Java program with the wrapper (different
configurations), the wrapper stopped pinging the JVM after some seconds
(which eventually leads to the JVM ending itself because it does not
receive ping packages from the wrapper any more).
The last system call that never returns according to strace is always
nanosleep:
gettimeofday({1290172014, 465559}, NULL) = 0
read(5, 0x8895070, 1024) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1290172014, 465610}, NULL) = 0
recv(7, 0xbffa98cb, 1, 0) = -1 EAGAIN (Resource
temporarily unavailable)
waitpid(13065, 0xbffa98a8, WNOHANG|WSTOPPED) = 0
nanosleep({0, 100000000}, NULL) = 0
gettimeofday({1290172014, 566505}, NULL) = 0
read(5, 0x8895070, 1024) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1290172014, 566552}, NULL) = 0
recv(7, 0xbffa98cb, 1, 0) = -1 EAGAIN (Resource
temporarily unavailable)
waitpid(13065, 0xbffa98a8, WNOHANG|WSTOPPED) = 0
nanosleep({0, 100000000},
If I call pstack on the wrapper, you can see that two threads currently
hang in the nanosleep method:
Thread 2 (Thread -1210287216 (LWP 13115)):
#0 0x00994410 in __kernel_vsyscall ()
#1 0x00d22506 in __nanosleep_nocancel () from /lib/libpthread.so.0
#2 0x0805b0d0 in wrapperSleep ()
#3 0x0805b420 in timerRunner ()
#4 0x00d1b2db in start_thread () from /lib/libpthread.so.0
#5 0x00c7512e in clone () from /lib/libc.so.6
Thread 1 (Thread -1208169792 (LWP 13114)):
#0 0x00994410 in __kernel_vsyscall ()
#1 0x00d22506 in __nanosleep_nocancel () from /lib/libpthread.so.0
#2 0x0805b0d0 in wrapperSleep ()
#3 0x08059f6c in wrapperEventLoop ()
#4 0x08056628 in wrapperRunConsole ()
#5 0x0805cce3 in main ()
#0 0x00994410 in __kernel_vsyscall ()
If I send a signal to the wrapper, it reacts again, but before, it hangs
forever in the nanosleep method.
Is this a known problem of ServiceWrapper running with multiple CPUs?
Do I have to recompile with usleep support instead or is there an option
to always use usleep?
Best,
--Christopher (on behalf of Johannes)
|