Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of jim.robinson@gmail.com
 designates 209.85.192.171 as permitted sender)
MIME-Version: 1.0
From: "James A. Robinson" <jim.robinson@gmail.com>
Date: Tue, 3 Mar 2015 07:21:50 -0800
Message-ID: 
 <CAPd04b40B2qkSskVWnE6avL3Pp6XYb+xGBPMPyd+6GXMBdhh7Q@mail.gmail.com>
Subject: Replicated LevelDB status (production worthy?)
To: users@activemq.apache.org
Content-Type: text/plain; charset=UTF-8

Hi folks,

While testing out ActiveMQ I've been building clusters
VirtualBox.  I've been spinning up two 3-node Replicated
LevelDB stores on my laptop.

I've noticed that the clusters can sometimes get into a
state where none of the nodes is the master.  It appears
to me as though it's an issue with talking to zookeeper.

I'm assuming the issue is related to how few cpu cycles
the clusters are getting as part of this environment, but
the fact that the clusters don't ever recover makes me
wonder if Replicated  LevelDB is still a work in progress?

I was testing it because I saw that MasterSlave pairs
were deprecated in favor of one of the share everything
solutions or Replicated LevelDB.

Typically I'll see a message from this code:

./activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/groups/ChangeListener.scala:102:
       ChangeListenerSupport.LOG.warn("listeners are taking too long
to process the events")

and then nothing.  No more attempts to talk to the
zookeeper cluster, no attempts to elect a new master.

I haven't dug deeply into the issue yet, I wanted to
ask you folks about the status of the code first.

Jim