0

I am using websphere server. I have a servlet which acts as a request processor. Since the request is for (a lot of) background processing, I need to simply create a thread which will do all these background jobs. In the mean time my request processor should return after starting this thread. What I find from looking at the log is as soon as my request processor returns, the background processing thread also seems to exit as it is not giving any log messages. I tried to make background thread a daemon one, but again it is not leaving any log messages. Doesn't the request processor thread which is started by websphere remain alive in the pool of threads for ever? In that case shouldn't my background thread keep on working? Even if the request processor dies, isn't it that given that background thread is a daemon thread, it should keep executing? Please clarify. If there is any flaw in my understanding of how websphere is managing its threads. Please help me understand it.

EDIT:Problem has been solved.Actually it was my bad.I was holding back the HttpServletRequest object to work in with in the background thread.But anyhow it was being destroyed once the request has returned from the servlet.So there was some null pointer exception in my background thread and it was exiting.I still have to make out the life cycle of HttpServletRequest object and when exactly it is destroyed.If you can help me understand this,I will be thankful. Thanks anyway!

EDIT: Adding what Servlets specification has to say on this: Each request object is valid only within the scope of a servlet’s service method, or within the scope of a filter’s doFilter method, unless the asynchronous processing is enabled for the component and the startAsync method is invoked on the request object. In the case where asynchronous processing occurs, the request object remains valid until complete is invoked on the AsyncContext. Containers commonly recycle request objects in order to avoid the performance overhead of request object creation. The developer must be aware that maintaining references to request objects for which startAsync has not been called outside the scope described above is not recommended as it may have indeterminate results.

mawia
  • 9,169
  • 14
  • 48
  • 57
  • 1
    Are you calling `Thread.start()`? Have you tried using JVisualVM to observe your Thread states? – Tim Bender Jan 27 '11 at 04:27
  • yeah I am using Thread.start().I have no idea regarding JVisualVM. – mawia Jan 27 '11 at 05:25
  • Wrap your thread's `run()` method in a try-catch block & log exceptions, perhaps even Error -- because otherwise you won't see the error. This applies to a lot of thread-pools, executors & similar. – Thomas W Sep 30 '13 at 08:26

3 Answers3

1

Doesn't the request processor thread which is started by websphere remain alive in the pool of threads for ever?

Most ThreadPoolExecutor instances allow the threads to die after some extended idle time. This is optional of course and I am not sure how websphere manages its worker threads. However, threads are not dependent on the threads which spawned them to keep them alive. Threads are the entities which keep the JVM alive and each one is independent.

In that case shouldn't my background thread keep on working? Even if the request processor dies, isn't it that given that background thread is a daemon thread, it should keep executing?

Making a Thread daemon only serves to inform the JVM that it may exit if that Thread is still alive. A JVM will continue to execute until all non-daemon threads have terminated. In your case it has no bearing on the problem since websphere won't just exit without being told to shutdown. In general, making the Thread daemon is the exact opposite of what you want. You want that thread's liveliness to keep your JVM alive.

Of course neither of those answers solve your problem. A code snippet of how you create and start the Thread would help. Many people will suggest you look into using an ExecutorService instead of making new Threads.

Tim Bender
  • 20,112
  • 2
  • 49
  • 58
1

Creating threads in a j2ee container is discouraged, see :Why spawning threads in J2EE container is discouraged?

With Websphere you can use either Asynchronous Beans and WorkManager, or you can use JMS and MDB to do the work.

Community
  • 1
  • 1
svachon
  • 7,666
  • 1
  • 18
  • 16
0

In the past, I have used Quartz to create a 'non-blocking worker thread' while responding to an HTTPRequest.

You can pass the work off to the Quartz-thread/job and return a response and then interact with the Quartz-thread/job during subsequent requests.

You can download and learn more about Quartz Scheduler here

You can simplify the process by using Spring abstraction.
For information check out the Spring documentation on scheduling.

I hope this helps - let me know if you need further direction.

Community
  • 1
  • 1
Matthew Huckaby
  • 51
  • 1