The customer has an application server product, where he has processes

called as cartridges which come up and stay around servicing all

the incoming HTTP requests. Most of these processes have a

specific interpreter loaded in them. Thus he has a Java Cartridge

process which has a JVM loaded in it servicing all HTTP requests

directed to Java applications on the server side.

  He loads JVM using JNI invocation API's. Each cartridge process

is multithreaded and at any time he might have a multitude of

threads executing client requests simultaneously. Before he executes

a client request, he attaches the current thread with the JVM and

detach it when he completes the execution.

   The 'ys' layer in his product provides the OS dependent features.

So all threads and mutexes (in our code) uses 'ys' functions to

create and manage. 'ys' layer does a sigwait on couple of signals

like SIGQUIT, SIGTERM etc.

   In most of the stack traces, he found just the thread executing

Java code in the run state. So though the signal was captured in

another thread, the thread that would have caused the dump is the

Java thread.


john.stampfl@eng 1999-08-26
Added thread dump to attachments, "btall.core.wrks.xxxx"