Well, I'm pretty sure zookeeper won't let the client specify a value outside its own minSessionTimeout and maxSessionTimeout, so I think the real question is how close to minSessionTimeout I can get without seeing problems. It's really just masking the underlying problem though, right? The client ought to reinitialize itself in the event of failures and sometimes it is not. On Sat, Jul 25, 2015 at 08:25 Tim Bain <tb...@alumni.duke.edu> wrote:
> James, > > You've tested two of the three cases; would it be possible to test the > third one? > > - ActiveMQ timeout < ZooKeeper timeout: fails > - ActiveMQ timeout = ZooKeeper timeout: succeeds > - ActiveMQ timeout > ZooKeeper timeout: ??? > > If we can zero in on exactly what the recommendation is, I can update > http://activemq.apache.org/replicated-leveldb-store.html (or another page > if you think there's a more appropriate one) to include the recommendation > we come to. But I don't want to say on the official documentation that it > has to be = if >= would work fine. > > Tim > > On Fri, Jul 24, 2015 at 10:39 AM, James A. Robinson <j...@highwire.org> > wrote: > > > So about 40 hours after fixing the settings so that both activemq and > > zookeeper agreed on what the session timeout is, I haven't seen any new > > instances of the errors I was seeing before. Previously it'd typically > be > > no more than 4 hours between complaints about needing to re-establish > > zookeeper connections. > > > > If I'm right, then this indicates the instability I saw can be masked > over > > by making sure the two agree on the session timeout, but that the > > fundamental fragility of the activemq zookeeper client code is still a > > potential risk. > > > > Jim > > > > On Wed, Jul 22, 2015 at 6:27 PM James A. Robinson <j...@highwire.org> > > wrote: > > > > > Hrm... I'm wondering if this is due to the zookeeper server having a > > > default session timeout of 40 seconds vs. a lower one I set for the > > > activemq node... > > > > > >
