Chris,
I do have one other webapp deployed alongside, but neither of them ever gets
reloaded. We always do a full stop/start of tomcat to roll out new builds
(which is about the only time we ever stop these apps).
There's absolutely no performance penalty that I'm aware of. It was just
the yet-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan,
On 9/20/2011 4:47 PM, Dan Checkoway wrote:
> Thanks Chris. Those threads are *never* idle in this app. :-)
> They're still getting recycled periodically, it looks like, despite
> lack of idle time.
Hmm, that does sound weird. Do you have other
Thanks Chris. Those threads are *never* idle in this app. :-) They're
still getting recycled periodically, it looks like, despite lack of idle
time. Does that make sense or am I on crack?
On Tue, Sep 20, 2011 at 4:38 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan,
On 9/20/2011 2:29 PM, Dan Checkoway wrote:
> I'm curious how long Executor threads live prior to being
> recycled/replaced/what have you. Is there a way to control this
> lifecycle?
You can set maxIdleTime to something other than the default (
If commons-pool supported bulk borrow/return in a single blocking operation,
I'd be all over it. But the fact that if I want to borrow 3000 objects from
the pool, it's 3000 blocking ops, that's a non-starter.
Unless I'm missing something? If there's a "minimally blocking" pool impl
that supports
On 20/09/2011 20:06, Dan Checkoway wrote:
> To be specific, we're having a major issue with garbage generation. To
> avoid this, we're pre-allocating pools of instances (up until now
> ThreadLocal, but that's obviously changing). When a request is processed it
> may need anywhere between 1 and N
To be specific, we're having a major issue with garbage generation. To
avoid this, we're pre-allocating pools of instances (up until now
ThreadLocal, but that's obviously changing). When a request is processed it
may need anywhere between 1 and N objects from the pool, which it grabs and
uses, an
On 20/09/2011 19:59, Dan Checkoway wrote:
> Thanks for the quick reply, Mark. Much appreciated. I was afraid that was
> the case.
>
> What I was trying to accomplish was...data that's not request/response
> specific in any way, that survives requests. I was using ThreadLocal so as
> to make it
> memory leak prevention code.
>
> > What's making this more confusing is that the thread IDs appear to be
> > getting reused, so logging the thread ID isn't helping (it's probably
> > confusing me more than anything).
> >
> > Anyway, can someb
hat's making this more confusing is that the thread IDs appear to be
> getting reused, so logging the thread ID isn't helping (it's probably
> confusing me more than anything).
>
> Anyway, can somebody confirm if Tomcat has explicit deliberate control over
> the Executor
can somebody confirm if Tomcat has explicit deliberate control over
the Executor thread lifecycle, and if so, how I might be able to control
it? And if not, is there a way to control it?
Thanks,
Dan
11 matches
Mail list logo
