hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Bailey" <nicholas.bai...@rackspace.com>
Subject Re: Zookeeper EventThread and SendThread
Date Thu, 20 May 2010 21:21:56 GMT
Seems like a likely possibility.  We definetly don't have as many application threads as there
are of these. Possibly we are keeping references to handles somehow though.  We will look
into that possibility.

Thanks!

Nick Bailey
Rackspace Hosting
Software Developer, Email & Apps
nicholas.bailey@rackspace.com

On Thursday, May 20, 2010 3:11pm, "Mahadev Konar" <mahadev@yahoo-inc.com> said:

> 
> Hi Nick,
>  These threads are spawned with each zookeeper client handle. As soon as you
> create a zookeeper client object these threads are spawned.
> 
> Are yu creating too many zookeeper client objects in your application?
> 
> Htanks
> mahadev
> 
> On 5/20/10 11:30 AM, "Nick Bailey" <nicholas.bailey@rackspace.com> wrote:
> 
>> Hey guys,
>>
>> Question regarding zookeeper's EventThread and SendThread. I'm not quite sure
>> what these are used for but a stacktrace of our client application contains
>> lines similar to
>>
>> "pool-2-thread-20-EventThread" daemon prio=10 tid=0x00002aac3cb29c00 nid=0x75d
>> waiting on condition [0x000000006b080000..0x000000006b080b10]
>>    java.lang.Thread.State: WAITING (parking)
>>         at sun.misc.Unsafe.park(Native Method)
>>         - parking to wait for  <0x00002aab1f577250> (a
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>>         at
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>>         at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Ab
>> stractQueuedSynchronizer.java:1925)
>>         at
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
>>         at
>> org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:414)
>>
>> "pool-2-thread-20-SendThread" daemon prio=10 tid=0x00002aac3c35d400 nid=0x75c
>> runnable [0x0000000070ede000..0x0000000070edeb90]
>>    java.lang.Thread.State: RUNNABLE
>>         at sun.nio.ch.EPollArrayWrapper.epollWait(Native
>> Method)
>>         at
>> sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:215)
>>         at
>> sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
>>         at
>> sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
>>         - locked <0x00002aab1f571d08> (a sun.nio.ch.Util$1)
>>         - locked <0x00002aab1f571cf0> (a
>> java.util.Collections$UnmodifiableSet)
>>         - locked <0x00002aab1f5715b8> (a
>> sun.nio.ch.EPollSelectorImpl)
>>         at
>> sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
>>         at
>> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:921)
>>
>> There are pairs of threads ranging from thread-1 to thread-50 and also
>> multiple pairs of these threads.  As in pool-2-thread-20-SendThread is the
>> name of multiple threads in the trace.  I'm debugging some load issues with
>> our system and am suspicious that the large amount of zookeeper threads is
>> contributing. Would anyone be able to elaborate on the purpose of these
>> threads and how they are spawned?
>>
>> Thanks,
>>
>> Nick Bailey
>> Rackspace Hosting
>> Software Developer, Email & Apps
>> nicholas.bailey@rackspace.com
>>
> 
> 



Mime
View raw message