Application code in particular is NOT calling an interrupt..
But I have a Web application (Servlet) that is deployed on the same instance. I do call interrupt on some of the threads servicing web requests when the processing time goes beyond 2.5 min.
But, my understanding is that, the threads alloted for web app are not shared across for the JMS Session Bean pool. The JMS listener problem would be associated with the threads alloted to only JMS pool
(a) Is my understanding of the thread pooling is incorrect?
Otherwise, I am not calling a direct interrupt on any of the JMS session threads..
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176869#4176869
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176869
anonymous wrote : I was also thinking about adding an API element to the RequestContext class: a "resume()" method that basically allows the next waiting request to be processed immediately in another thread (as opposed to executing a background thread for every request). What do you think?
IMHO it is not necessary. I will prefer the explicitly of using the runnable.
Now my last questions (for now):
What is the API to reply asynchronously?
What is the API to identify a (session) client from the handleRequest?
Can I create a endpoint bounded to a session?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176865#4176865
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176865
