I appreciate your reply.
I will test with the -1.
I have tried async - it fails just like a sync.
I have a controller (also in a Glassfish instance) with a rule system.
The controller will NEVER overtask any Glassfish worker instance. After
sending a tasking message, the controller will receive a SOAP message
from each "worker" Glassfish instance when that instance has completed.
It is important that each Glassfish instance completes their task
without failure before that instance can be tasked again. The rule
system is in charge of that awareness. There are web services requiring
other web services - all must be orchestrated in the correct order and
timing even though it is not known prior to tasking exactly how long
each web service will require to complete their task. As fast as a
Glassfish instance can complete it current duties, it can be tasked
again - but, not before completion. Each instance in addition to
required output (database records) also keeps records of completion in
case something goes wrong, the process can be restarted.
Currently, the Glassfish worker instance starts its task as commanded
and 15 minutes later something - not my controller message - cause I
only sent one - starts a second process in the Glassfish worker instance
after the "interrupted idle thread" kicks. Then my databases are
corrupted because the analytics are running twice.
I appreciate your observations. Thanx very very much for your help. I
was really stuck - now I hope to make a little progress once again.
From: NBW [mailto:emailnbw_at_gmail.com]
Sent: Tuesday, September 28, 2010 2:03 PM
To: users_at_glassfish.dev.java.net
Subject: Re: Re: RE: Re: Interrupted idle thread
On Tue, Sep 28, 2010 at 11:32 AM, Martin, Ray <armart3_at_tycho.ncsc.mil>
wrote:
Thank you, Sir.
I will be testing using your suggestion. Do you know if there is a
setting for "never time out"?
I thought I read somewhere on this list that you might be able to use -1
to achieve this but I am not sure if that's the case or not.
From what you are saying it seems to me though that a better approach
would be to make this an async operation. Even if you make these threads
never time out what will happen is that after a few of these long
running requests get kicked off you will deplete the HTTP connector
thread pool. This will prevent handling any more requests to any web
apps that your instance may be running.
Also, I have not yet used your suggestion, but, in all cases -
synchronous or asynchronous - the "interrupted idle thread" occurred in
my testing. I was expecting that asynchronous web operations would not
hit the "interrupted idle thread" because the asynchronous message
returns immediately. But, no matter, the long running web operation
still hits the "interrupted idle thread".
I have some web operations that run for days - so, I am really
looking for a "never time out" setting.
I suspect you are starting your worker thread from the same thread that
is involved in the HTTP request. In that case they will be part of the
same thread group and when the parent is interrupted the children are
interrupted as well. There are a few approaches to take here. Some of
them are technically not allowed by the EE specification but you can get
away with them if you understand the pitfalls. For example you can start
your own threads from a synchronized method in a Singleton EJB (which
you inject into your web service). In that case these threads won't be
interrupted in the case you are talking about. However, the 'right' way
to go about this with EE6 would be to have your Web Service use a
Stateless session bean which is injected into it which has an
@Asynchronous method on it that returns a Future<V>. For an example of
this check out:
http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview_P
art3.html#asynejb
Thank you so much - I was unaware of the setting from the
console - my bad. I am off to do some testing.
No problem. Good luck.
-Noah