Peter Rossbach wrote:
HI Filip,
with your last checkin my trace changed but leak is there. Also I got
a exception too:
yes, still working on it,
Filip
12.04.2007 17:20:30 org.apache.tomcat.util.net.NioSelectorPool
getSharedSelector
INFO: Using a shared selector for servlet write/read
Event
HI Filip,
with your last checkin my trace changed but leak is there. Also I got
a exception too:
12.04.2007 17:20:30 org.apache.tomcat.util.net.NioSelectorPool
getSharedSelector
INFO: Using a shared selector for servlet write/read
Event received connect BEGIN
Getting handler for action con
Hi Filip,
I have testet with NIO and the memory leak is still there.
Peter
Am 12.04.2007 um 16:29 schrieb Filip Hanik - Dev Lists:
Peter Rossbach wrote:
Hi Filip,
I have test your patch with my comet testclient. It seems not
working. The RequestProcessors JMX Objects aren't deregiste
Peter Rossbach wrote:
Hi Filip,
I have test your patch with my comet testclient. It seems not
working. The RequestProcessors JMX Objects aren't deregistered:
So far the patch is only for NIO, I will make it for APR and JIO today.
Access Log:
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometch
Hi Filip,
I have test your patch with my comet testclient. It seems not
working. The RequestProcessors JMX Objects aren't deregistered:
Access Log:
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200 0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect'
Filip Hanik - Dev Lists wrote:
Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think it does.
Since every request processor gets registered with JMX, I just couldn't
find a spot where it was unregistered.
And since the name was dynamic, ie
Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think it does.
Since every request processor gets registered with JMX, I just couldn't
find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++" variable
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
synchr
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}
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
attached is an example patch using weak references that would solve
this problem,
I'd like to get thoughts on this patch, please comment
if the attachment doesn't make it
http://people.apache.org/~fhanik/mem-leak-diff.patch
For sure it's n
Filip Hanik - Dev Lists wrote:
attached is an example patch using weak references that would solve this
problem,
I'd like to get thoughts on this patch, please comment
if the attachment doesn't make it
http://people.apache.org/~fhanik/mem-leak-diff.patch
For sure it's not the right way to do
attached is an example patch using weak references that would solve this
problem,
I'd like to get thoughts on this patch, please comment
if the attachment doesn't make it
http://people.apache.org/~fhanik/mem-leak-diff.patch
Filip
Filip Hanik - Dev Lists wrote:
Thanks to Peter Rossbach for ale
Thanks to Peter Rossbach for alerting me to this.
If we are using the Executor, and are using shrinking thread pools, the
RequestGroupInfo collects these objects and never releases them.
The only reason we don't see the problem with the default thread pool,
is cause it never shrinks, hence it n
13 matches
Mail list logo
