Re: Replicated LevelDB status (production worthy?)

2015-03-11 Thread James A. Robinson
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:

Re: Thousands of workers waiting to receive jobs but ActiveMQ isn’t sending them.

2015-03-11 Thread Kevin Burton
Yes. I’m sorry. I meant the stock configuration so no slow consumer strategy! On Wed, Mar 11, 2015 at 12:56 PM, Tim Bain tb...@alumni.duke.edu wrote: There isn't a stock slow consumer strategy. If you didn't configure it, you don't have one. On Wed, Mar 11, 2015 at 1:49 PM, Kevin Burton

Re: Thousands of workers waiting to receive jobs but ActiveMQ isn’t sending them.

2015-03-11 Thread Tim Bain
There isn't a stock slow consumer strategy. If you didn't configure it, you don't have one. On Wed, Mar 11, 2015 at 1:49 PM, Kevin Burton bur...@spinn3r.com wrote: I didn’t configure one… so we’re running the stock one. I’m trying to verify it it’s just a specific task not committing messages

Re: Thousands of workers waiting to receive jobs but ActiveMQ isn’t sending them.

2015-03-11 Thread Tim Bain
Out of curiosity, which slow consumer strategy did you configure? On Wed, Mar 11, 2015 at 11:45 AM, Kevin Burton bur...@spinn3r.com wrote: The problem is that this is happening in production but not locally. Setting prefetchPolicy to zero fixed it for one of our tasks, but another one of our

Re: Replicated LevelDB status (production worthy?)

2015-03-11 Thread Gary Tully
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 j...@highwire.org wrote: So I think the problem is that org.linkedin.zookeeper.tracker.ZooKeeperTreeTracker doesn't appear to handle the event of a

How to limit the store usage in a shared DB environment

2015-03-11 Thread noone100
storeUsage seems not to be applicable for JdbcPersistenceAdapter, since JdbcPersistenceAdapter.size() always returns 0. Is there any other way to slow down a persistent message producer using JdbcPersistenceAdapter when a DB reaches its limits? Thanks! -- View this message in context:

Re: Thousands of workers waiting to receive jobs but ActiveMQ isn’t sending them.

2015-03-11 Thread Tim Bain
I'd definitely set breakpoints and step through with a debugger to try to figure out what's going on. On Mar 10, 2015 8:19 PM, Kevin Burton bur...@spinn3r.com wrote: This is exceedingly bizarre. Now ActiveMQ is refusing to deliver ANY messages to my workers. This is very bizarre, no code has

Re: Data Migration from KahaDB to LevelDB?

2015-03-11 Thread artnaseef
Non-durable topic subscriptions have that issue no matter what - lose the connection and all unconsumed messages are dropped. And all messages published while disconnected are also missed. Keep in mind too that Topics do not persist messages themselves in ActiveMQ; only durable subscriptions