Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4B0C5859.40508@apache.org>
Date: Tue, 24 Nov 2009 14:04:09 -0800
From: Patrick Hunt <phunt@apache.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: zookeeper-user@hadoop.apache.org
Subject: Re: Asking zk cluster how its configured and whats this expired
 about?
References: <7c962aed0911241257g6e3a010cv65a4e189077625bc@mail.gmail.com>
	 <4B0C511A.3000705@apache.org>
 <7c962aed0911241347m20395213mc2c42e3905a97549@mail.gmail.com>
In-Reply-To: <7c962aed0911241347m20395213mc2c42e3905a97549@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

stack wrote:
> On Tue, Nov 24, 2009 at 1:33 PM, Patrick Hunt <phunt@apache.org> wrote:
> 
>> We can definitely add this, please create a JIRA.
>>
> ZOOKEEPER-595

Great, thanks!

> 
>>  I was also wondering what this expire stuff in the dump output is about?
>> Those are the expiration sets, or buckets. Each client session is put into
>> a bucket based on when we last heard from it and it's timeout. The leader
>> uses this to determine when to expire sessions.
>>
>> Unfortunately the session ids are being printed in decimal, this is fixed
>> in 3.3.0.
>>
>> Good find, actually this would be useful information for you to monitor in
>> determining which of your hbase clients are "falling behind" wrt
>> heartbeating.
>>
>>
> Well, are items listed under '2 expire at Tue Nov 24 20:57:06 UTC 2009'
> items that have expired or rather, just a logging of when they will expire?
> Looking in logs I do not see sessions expiring.

These are future, as in "when will they expire" - when we hear from a 
session we "promote" it to a subsequent bucket based on the timeout. As 
sessions age (and we don't hear from them) they eventually fall through 
(or bubble up from this dump perspective), this is now the leader 
tracks/determines when to expire a session.

Patrick


> 
>>  Here is what I see:
>>> $ echo dump|nc X.X.X.X 2181
>>> SessionTracker dump:
>>> Session Sets (12):
>>> 0 expire at Tue Nov 24 20:56:24 UTC 2009:
>>> 0 expire at Tue Nov 24 20:56:27 UTC 2009:
>>> 0 expire at Tue Nov 24 20:56:30 UTC 2009:
>>> 0 expire at Tue Nov 24 20:56:39 UTC 2009:
>>> 0 expire at Tue Nov 24 20:56:42 UTC 2009:
>>> 0 expire at Tue Nov 24 20:56:45 UTC 2009:
>>> 0 expire at Tue Nov 24 20:56:48 UTC 2009:
>>> 0 expire at Tue Nov 24 20:57:00 UTC 2009:
>>> 0 expire at Tue Nov 24 20:57:03 UTC 2009:
>>> 2 expire at Tue Nov 24 20:57:06 UTC 2009:
>>>        82512629887926272
>>>        154570223919497222
>>> 2 expire at Tue Nov 24 20:57:09 UTC 2009:
>>>        82512629887926273
>>>        10455035895349254
>>> 3 expire at Tue Nov 24 20:57:21 UTC 2009:
>>>        154570223919497216
>>>        10455035895349248
>>>        154570223919497221
>>>
>>> ephemeral nodes dump:
>>> Sessions with Ephemerals (4):
>>> 0x2524ccbca80000:
>>>        /hbase/rs/1259042878053
>>> 0x12524ccb9f40000:
>>>        /hbase/rs/1259042878032
>>> 0x12524ccb9f40001:
>>>        /hbase/rs/1259042878106
>>> 0x22524ccb9930000:
>>>        /hbase/master
>>>
>>> Thanks,
>>> St.Ack
>>>
>>>
>