Memory Leak

["Trustin Lee (이희승)"]

Thanks for a great answer and suggestion.  I've just updated the Javadoc.

Actually, a warning is logged at DEBUG level if too many timer instances
are created.  However, it seems like people do not see the log message
since java.util.logging's default log level is INFO.  I didn't raise the
log level because there might be a case where a user really wants to run
many timer threads in one's supercomputer.

What would be a better solution to tell a user that he might be making a
mistake?  What I can think of right now is to throw an exception instead
of logging and let user disable the misuse checker if it's intended.

Trustin

Enno Shioji wrote:
> +1 to add a warning about this to
> ReadTimeoutHandler/WriteTimeoutHandler/HashedWheelTimer Javadocs. I
> almost did the same thing.. Something similar to that in
> ExecutionHandler (3.2.0) would be great.
> (  <b>timer, // Must be shared</b> )
> 
> 
> I think we newbie tend to copy and paste whatever example is given in
> Javadoc, so it would be nice to have a warning right there.
> 
> 
> 
> 
> 
> On Mon, Mar 15, 2010 at 9:53 AM, huican ping <pinghuican at gmail.com> wrote:
>> 1:) Plaese don't create timer for each pipeline object, you can create
>> one, and all pipeline objects refer it.
>> 2:) make sure you call timer.stop() when it is not used anymore.
>>
>> On Mon, Mar 15, 2010 at 11:18 AM, ajay_bhosle <ajay.bhosle at zapak.co.in> wrote:
>>> Hi,
>>>
>>>   I am running out of memory which i believe is caused due to
>>> HashedWheelTimer being used in ReadTimeOutHandler, below is the snapshot of
>>> the heap memory which keeps on increasing. Has anyone come across this
>>> issue, please let me know.
>>>
>>>   1:        727040       40714240
>>> [Lorg.jboss.netty.util.internal.ConcurrentIdentityHashMap$HashEntry;
>>>   2:        727849       34936752
>>> java.util.concurrent.locks.ReentrantLock$NonfairSync
>>>   3:        727040       34897920
>>> org.jboss.netty.util.internal.ConcurrentIdentityHashMap$Segment
>>>   4:        181760       13086720
>>> org.jboss.netty.util.internal.ConcurrentIdentityHashMap
>>>   5:        181760       13086720
>>> org.jboss.netty.util.internal.ConcurrentIdentityHashMap$KeyIterator
>>>   6:        181760       10178560
>>> [Lorg.jboss.netty.util.internal.ConcurrentIdentityHashMap$Segment;
>>>   7:        181760        4362240
>>> org.jboss.netty.util.internal.ConcurrentIdentityHashMap$KeySet
>>>
>>> Thanks
>>> Ajay
>>> --
>>> View this message in context: http://n2.nabble.com/Memory-Leak-tp4738033p4738033.html
>>> Sent from the Netty User Group mailing list archive at Nabble.com.
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100324/04dfd01f/attachment-0001.bin