Re: Asking zk cluster how its configured and whats this expired about?
stack wrote: I want to ask a running zk cluster what its configuration is -- ticktime, session timeout, etc. -- but do not see how. There are the four letter words. Dump and stat do not print what I want. I took a look in logs -- the leader in particular -- and do not see vitals dumped out. Am I missing something? I don't think we provide that through 4letterword or through log. It may be available through jmx but not 100% certain on that. I think the only way to determine currently is to look at the config file (if you have one). We can definitely add this, please create a JIRA. 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. 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): 0x2524ccbca8: /hbase/rs/1259042878053 0x12524ccb9f4: /hbase/rs/1259042878032 0x12524ccb9f40001: /hbase/rs/1259042878106 0x22524ccb993: /hbase/master Thanks, St.Ack
Re: Asking zk cluster how its configured and whats this expired about?
On Tue, Nov 24, 2009 at 1:33 PM, Patrick Hunt ph...@apache.org wrote: We can definitely add this, please create a JIRA. ZOOKEEPER-595 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. Thanks, St.Ack 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): 0x2524ccbca8: /hbase/rs/1259042878053 0x12524ccb9f4: /hbase/rs/1259042878032 0x12524ccb9f40001: /hbase/rs/1259042878106 0x22524ccb993: /hbase/master Thanks, St.Ack
Re: Asking zk cluster how its configured and whats this expired about?
stack wrote: On Tue, Nov 24, 2009 at 1:33 PM, Patrick Hunt ph...@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): 0x2524ccbca8: /hbase/rs/1259042878053 0x12524ccb9f4: /hbase/rs/1259042878032 0x12524ccb9f40001: /hbase/rs/1259042878106 0x22524ccb993: /hbase/master Thanks, St.Ack
