Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
you're of course right, I think I simply need to get rid of the
thread local cache, and use the processor cache instead.
do you have any idea of the performance penalty? I'd probably use a
ConcurrentLinkedQueue or something instead of
synchronized{processorCache}
There's a penalty already for using an executor (unfortunately). So
there could be a check: if using an executor, then use a processor
pool of some sort (a dumb synced stack could do it, but I don't know
if it would be better or worse speed wise - maybe about the same since
there's no read at all, only modifications of the "collection"),
otherwise use the thread local. Maybe there could be a better
solution, but it's probably the easy one.
I didn't think about this leak issue when I thought about supporting
executors.
me neither, but then again, the thread local is not the real problem.
its the requestinfo and requestgroupinfo objects, has the funky circular
dependency, and ties it back all the way to the "handler". Had it not
been for those, then there would have been no leak, since the objects
would have been collected when the thread died, and the thread local
reference disappeared.
Filip
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
