Our project is building web services that execute in two basic layers. Services in the “outer” layer extract the body from the Soap message, perform xml validation and then remotely invoke a service in the “inner” layer. When the remotely invoked service completes, the “outer” layer services packages the results into a valid soap response to be returned to the calling client. During the development phase, the remote server alias points to the same physical server resulting in both layers running on the same box. At some future point, we may use two physical servers.
The project team has developed some multithreaded utilities that perform things like request logging, metrics capture and auditing. Calls to these services are sprinkled throughout the business logic services in the “inner” layer.
Here’s the issue: New sessions appear to be created for each execution of the web service. The user ID associated with these sessions is the one found on the remote server alias. These sessions never expire. Killing them from the admin console or from a java service causes them to disappear for a few seconds but then reappear shortly thereafter. Also our thread count continues to increase.
All of our utility services invoke a java service that uses the following command to invoke a service on its own thread:
Several of these utilities, simply spawn the thread. They do not execute a subsequent wait step to collect data from the thread.
So, my questions are:
- Is using doThreadInvoke without a subsequent wait step (or call to getData()) a bad thing or is this an acceptable use? []What is the relationship between threads spawned during a remote invoke and the session that gets created by the remote invoke? []Why don’t these sessions expire? [*]Can the object reference of a thread (st in my example above) be used to kill a thread that is hanging around?
Thanks in advance,
Mark