activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Replicated LevelDB status (production worthy?)
Date Wed, 04 Mar 2015 13:52:47 GMT
People reported similar high-level symptoms against 5.10.0 several months
back (you can search the archives on Nabble), and I don't recall any
discussion of anyone finding a solution.  But JIRA is the authoritative
place to find out whether anyone has reported and/or fixed this issue (or
any other).
On Mar 3, 2015 8:23 AM, "James A. Robinson" <jim.robinson@gmail.com> wrote:

> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message