Re: What controls message redelivery when a client acknowledgment isn’t sent?

On Fri, Apr 17, 2015 at 4:38 PM, Tim Bain wrote: > Yeah, the whole paradigm of CLIENT_ACKNOWLEDGE is "I know what I'm doing, > don't worry about me, I'll tell you when we're good to go." As long as the > client is alive and still connected, it's called the ball and the broker > won't second-gues

Re: What controls message redelivery when a client acknowledgment isn’t sent?

Yeah, the whole paradigm of CLIENT_ACKNOWLEDGE is "I know what I'm doing, don't worry about me, I'll tell you when we're good to go." As long as the client is alive and still connected, it's called the ball and the broker won't second-guess it. So you've gotta write rock-solid code to make sure y

Re: What controls message redelivery when a client acknowledgment isn’t sent?

Nevermind on this one. I think the issue is that there’s no really solid way to test this. I don’t know enough about the JMS internals. It seems like if I keep the session,consumer open, that the client acknowledge never times out. I gave it ten minutes and it never attempted to hand out the mes

What controls message redelivery when a client acknowledgment isn’t sent?

It looks like redelivery variables work if you call session.rollback() … but not if you just never send an acknowledgment when running with CLIENT_ACKNOWLEDGE mode. http://activemq.apache.org/redelivery-policy.html It seems like it’s exactly 2000ms no matter if I set initialRedeliveryDelay or red

Re: Encourage more users to embed activemq?

On Fri, Apr 17, 2015 at 11:53 AM, Tim Bain wrote: > If you embed it in your app, then you lose the ability to cycle your app > without taking down your broker (which is a bad thing if you use > non-persistent messaging as we do). Oh. to clarify. I built our own foo-activemq service. So it ben

Re: Broker refusing to send messages to only certain queues?

On Fri, Apr 17, 2015 at 11:42 AM, Tim Bain wrote: > Hmm, too bad pulling the obvious threads didn't yield anything. If you > start seeing this happen regularly, maybe you could run a few of the > clients that are likely to hit the problem with the debugging port open so > you can connect in afte

Re: Encourage more users to embed activemq?

From my highly osgi-centric viewpoint this seems like a good use of running activemq in an osgi environment exposing services that can be used by e.g. your REST stuff to publish them externally. Adding servlets would be easy using the http whiteboard service…. thanks david jencks On Apr 17, 2

Re: Encourage more users to embed activemq?

If you embed it in your app, then you lose the ability to cycle your app without taking down your broker (which is a bad thing if you use non-persistent messaging as we do). Clearly that trade-off is a win in your situation, but your situation's a bit of an outlier in terms of performance, so the

Re: Broker refusing to send messages to only certain queues?

Hmm, too bad pulling the obvious threads didn't yield anything. If you start seeing this happen regularly, maybe you could run a few of the clients that are likely to hit the problem with the debugging port open so you can connect in after the fact and try to figure out what's going on... And it'

Encourage more users to embed activemq?

When we initially deployed activemq we took the normal route of using it with an init.d and run the daemon like we do apache, cassandra, etc. Like a daemon. However, I found that we lean pretty hard on the actual implementation of ActiveMQ and need to go above and beyond what ActiveMQ provides.

Re: Broker refusing to send messages to only certain queues?

On Fri, Apr 17, 2015 at 5:24 AM, Tim Bain wrote: > So no JMX stats are changing; does that mean messages aren't being > produced? I had assumed you were flowing messages in but they couldn't get > out so they were piling up on the broker. If you send a couple more > messages, what happens? > >

Re: Monitoring producer flow control.

Yes. The way I was going to do it was have a gauge that measures how long blocking calls are open for. I’ll see it in our monitoring system because all of a sudden the send latencies will keep rising per second. On Fri, Apr 17, 2015 at 5:10 AM, Tim Bain wrote: > Also keep in mind that send() i

Re: Monitoring producer flow control.

Ah. yeah. I just saw that. I wrote a test for it and it triggered the log line. I might look at that line and try to figure out the best way to track that? Maybe a JMX integer that’s integrated for each time it happens? I might not need it in the short term but probably will in the long term. I

AMQ stops sending messages with 36 messages to go consistently on large volume of messages

Hello, I have been stuck in the problem for a while. I have large volumes of request messages that are produced by a 'server' app. The requests are nothing but start Oracle DB rownum and end rownum depending on the 'request page size' can be 500 or 1000. So a massage is an ImmutablePair<1, 499> or

Re: AMQ stops sending messages with 36 messages to go consistently on large volume of messages

-- View this message in context: http://activemq.2283324.n4.nabble.com/AMQ-stops-sending-messages-with-36-messages-to-go-consistently-on-large-volume-of-messag

Re: Broker refusing to send messages to only certain queues?

So no JMX stats are changing; does that mean messages aren't being produced? I had assumed you were flowing messages in but they couldn't get out so they were piling up on the broker. If you send a couple more messages, what happens? Also, you said this is a heavily-loaded broker. Can you do an

Re: JMX variables for queue creation timestamp, last enqueue time, etc.

Sounds useful (and easy to implement). On Apr 16, 2015 10:11 PM, "Kevin Burton" wrote: > It would be handy to have timestamps for various things on queues. > > Right now if a queue is created, it’s unclear how long it’s been in > existence for.. > > Would also be nice to see stats for the last ti

Re: Monitoring producer flow control.

Also keep in mind that send() is a blocking call, so the stopwatch idea will only tell you when PFC has occurred and then cleared up (once send() returns), but won't alert you to a deadlock that won't clear up on its own. On Apr 17, 2015 6:06 AM, "Tim Bain" wrote: > There's a log line in the brok

Re: Monitoring producer flow control.

There's a log line in the broker whenever PFC kicks in; we watched the logs for that line and fire off an email to get someone to investigate. Would that meet your needs? On Apr 16, 2015 10:10 PM, "Kevin Burton" wrote: > I’m looking at implementing producer flow control so that I don’t fill up >

Re: Broker refusing to send messages to only certain queues?

On Thu, Apr 16, 2015 at 8:34 PM, Tim Bain wrote: > If that was happening you'd see the DestinationViewMBean's ExpiredCount > increasing in the JMX counters, but only if the expiration was happening on > the broker; as far as I could tell, there's no stat that captures when > messages expire while