dev@glassfish.java.net

Re: Thoughts on Threadpool handling of context ClassLoader

From: Scott Oaks <Scott.Oaks_at_Sun.COM>
Date: Fri, 27 Apr 2007 14:56:26 -0400

Remember that there are actually any number of ORB threadpools -- there
is the default threadpool (thread-pool-1), but ORB listeners can be
configured to use a different threadpool, and remote EJBs can be
configured to execute on a different threadpool. All of these should
probably be managed in the same way.

thread-pool-1 is not an ORB-specific threadpool, of course, as it's used
by the appserver for many things. But I believe that the other thread
pools are only available for the remote EJBs, so they are ORB-specific?
I don't know if that affects anything.

-Scott

On Fri, 2007-04-27 at 14:46, Ken Cavanaugh wrote:
> Lloyd L Chambers wrote:
> > Factor out the thread pool alone so that any client can use it, not
> > just the ORB? And initialize it in its own thread at startup (always)?
> >
> No re-factoring needed in the ORB. The threadpool is independent of the
> ORB. It's just like any other utility
> class in appserv-rt.jar. In fact, several other parts of the app server
> share this same threadpool.
> However, the threadpool startup may need to be factored out of the
> ORBManager code. Right now,
> the threadpool is only initialized when the ORB is initialized, not at
> server startup time.
> But we certainly could move the threadpool initialization someplace
> else, where the
> context ClassLoader is guaranteed to be something that will be valid for
> the lifetime of
> the server VM.
>
> I don't know anything about app server startup, so I can't do this, but
> I'd be happy to work
> with someone to get this done.
>
> Thanks,
>
> Ken.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>