activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: Replicated LevelDB status (production worthy?)
Date Wed, 11 Mar 2015 22:28:16 GMT
I think you are correct here. The rebuild should work so long as the
session has not expired.

On 11 March 2015 at 20:51, James A. Robinson <jimr@highwire.org> wrote:
> So I think the problem is that
>
> org.linkedin.zookeeper.tracker.ZooKeeperTreeTracker
>
> doesn't appear to handle the event of a session disconnect.
> Or at least the version used by ActiveMQ doesn't...
>
> If I force tree to be rebuilt on a reconnect, my earlier unit test
> passes:
>
> https://github.com/jimrobinson/activemq/commit/d272a116ff5c0916a6044d657f99df48f264bd2a
>
> On Tue, Mar 10, 2015 at 4:57 PM, James A. Robinson <jimr@highwire.org> wrote:
>> Working my way through the code and the debug log from
>> the test, I see that the ZooKeeper group is getting emptied
>> out after session expiration occurs:
>>
>> before the timeout:
>>
>> 2015-03-10 12:09:50,614 | DEBUG | ActiveMQ Task | ZooKeeper group for
>> 0000000001 changed: Map(foo ->
>> ListBuffer((0000000000,{"id":"foo","container":null,"address":"tcp://localhost:62092","position":-1,"weight":1,"elected":"0000000000"}),
>> (0000000001,{"id":"foo","container":null,"address":null,"position":-1,"weight":1,"elected":null}),
>> (0000000002,{"id":"foo","container":null,"address":null,"position":-1,"weight":1,"elected":null})))
>>
>> after the timeout:
>>
>> 2015-03-10 12:10:53,490 | DEBUG | ZooKeeper state change dispatcher thread |
>> ZooKeeper group for 0000000001 changed: Map()
>>
>>
>>
>> On Sat, Mar 7, 2015 at 8:52 PM, James A. Robinson <jimr@highwire.org> wrote:
>>>
>>> I think I've got the use a case represented for
>>>
>>> https://issues.apache.org/jira/browse/AMQ-5082
>>>
>>> I could use some advice from others to confirm whether
>>> or not the underlying assumptions behind my test are valid.
>>>
>>> My assumption is that if 3 ElectingLevelDBStore are running,
>>> and they lose quorum due to a zk timeout, that once the
>>> timeout issue is resolved that the pool ought to try and
>>> re-establish a quorum.  Is that a fair assumption?
>>>
>>>
>>> https://github.com/jimrobinson/activemq/commit/58b7198880f5296af6b2e4e9efbbdfdb51220411
>>
>>
>>

Mime
View raw message