Memory Leak

["Trustin Lee (이희승)"]

Misuse checker now logs the message at WARN level so that the message is
visible in most cases.  To allow a user to mute the message, it's logged
with a distinguishable category:

    org.jboss.netty.util.internal.SharedResourceMisuseDetector.

Trustin

Trustin Lee (이희승) wrote:
> 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/20100406/44b68574/attachment-0001.bin