zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chang Song <tru64...@me.com>
Subject Re: Serious problem processing hearbeat on login stampede
Date Wed, 06 Jul 2011 05:02:11 GMT

Actually, "netspider", Chisu Ryu, in my team fixed it.

Thanks, Chisu.

Chang



2011. 7. 6., 오전 3:04, Patrick Hunt 작성:

> Vishal brought up an issue at the ZK post-summit meetup that might
> also be (partially?) resolved by this patch.
> 
> Thanks again Chang Song!
> 
> Patrick
> 
> 2011/7/1 Chang Song <tru64ufs@me.com>:
>> 
>> No problem.
>> Glad to contribute.
>> 
>> Thanks a lot.
>> 
>> 
>> 2011. 7. 2., 오전 1:03, Ted Dunning 작성:
>> 
>>> Thanks for the feedback Jared!
>>> 
>>> (and thanks to Chang as well!)
>>> 
>>> On Fri, Jul 1, 2011 at 8:06 AM, Jared Cantwell <jared.cantwell@gmail.com>wrote:
>>> 
>>>> As a note, I believe we just used this patch to solve a major issue ...
>>>> 
>>>> Thanks Chang!
>>>> ~Jared
>>>> 
>>>> On Tue, Apr 19, 2011 at 10:59 AM, Ted Dunning <ted.dunning@gmail.com>
>>>> wrote:
>>>> 
>>>>> Where is this set?
>>>>> 
>>>>> Why does this cause this problem?
>>>>> 
>>>>> 2011/4/19 Chang Song <tru64ufs@me.com>
>>>>> 
>>>>>> 
>>>>>> Problem solved.
>>>>>> it was socket linger option set to 2 sec timeout.
>>>>>> 
>>>>>> We have verified that the original problem goes away when we turn
off
>>>>>> linger option.
>>>>>> No longer a mystery ;)
>>>>>> 
>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-1049
>>>>>> 
>>>>>> 
>>>>>> Chang
>>>>>> 
>>>>>> 
>>>>>> 2011. 4. 19., 오전 3:16, Mahadev Konar 작성:
>>>>>> 
>>>>>>> Camille, Ted,
>>>>>>> Can we continue the discussion on
>>>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-1049?
>>>>>>> 
>>>>>>> We should track all the suggestions/issues on the jira.
>>>>>>> 
>>>>>>> thanks
>>>>>>> mahadev
>>>>>>> 
>>>>>>> On Mon, Apr 18, 2011 at 9:03 AM, Ted Dunning <ted.dunning@gmail.com>
>>>>>> wrote:
>>>>>>>> Interesting.  It does seem to suggestion the session expiration
is
>>>>>>>> expensive.
>>>>>>>> 
>>>>>>>> There is a concurrent table in guava that provides very good
>>>>>> multi-threaded
>>>>>>>> performance.  I think that is achieved by using a number
of locks
>>>> and
>>>>>> then
>>>>>>>> distributing threads across the locks according to the hash
slot
>>>> being
>>>>>> used.
>>>>>>>> But I would have expected any in memory operation to complete
very
>>>>>> quickly.
>>>>>>>> 
>>>>>>>> Is it possible that the locks on the session table are held
longer
>>>>> than
>>>>>> they
>>>>>>>> should be?
>>>>>>>> 
>>>>>>>> 2011/4/18 Fournier, Camille F. [Tech] <Camille.Fournier@gs.com>
>>>>>>>> 
>>>>>>>>> Is it possible this is related to this report back in
February?
>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>>>> 
>>>> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201102.mbox/%3C6642FC1CAF133548AA8FDF497C547F0A23C0C5265B@NYWEXMBX2126.msad.ms.com%3E
>>>>>>>>> 
>>>>>>>>> I theorized that the issue might be due to synchronization
on the
>>>>>> session
>>>>>>>>> table, but never got enough information to finish the
>>>> investigation.
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> thanks
>>>>>>> mahadev
>>>>>>> @mahadevkonar
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 


Mime
View raw message