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: Active MQ - Performance with CLIENT Ack
Date Thu, 20 Jul 2017 06:45:35 GMT
Luckily, you don't need access to the code TIBCO BW generates in order to
test this. You can set a breakpoint on the
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/ActiveMQMessageConsumer.java#ActiveMQMessageConsumer.acknowledge%28%29
method and attach a debugger to the JVM that's running your TIBCO code, and
you should be able to tell whether the method is being called even if you
don't have access to the generated source code. Another place you could set
a breakpoint is in ActiveMQSession.sendAck():
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/ActiveMQSession.java#ActiveMQSession.sendAck%28org.apache.activemq.command.MessageAck%29

One other option for investigating this would be to attach a debugger to
the broker and set a breakpoint on TransportConnection.processMessageAck()
-
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/broker/TransportConnection.java#TransportConnection.processMessageAck%28org.apache.activemq.command.MessageAck%29.
That should let you tell whether the ack is making it to the broker, which
tells us which side of the broker-client divide we should be focusing on.

And although I agree that log lines saying an acknowledgement is sent are
promising, I wouldn't consider that to be confirmation that it's actually
happening, which is why I recommend the debugger for a conclusive result.

You're correct that CLIENT_ACKNOWLEDGE means "acknowledge this message and
all previous ones." It's not something I've used personally and I've seen
very few posts to the mailing list about it, but I don't believe that the
broker would fail to process the ack if it's being sent to the broker. The
only situation I can think of would be one where the producer and consumer
were sharing a single connection and the producer started well before the
consumer and completely filled the broker before the consumer even got
started, and then you had also configured the broker so it couldn't do
per-client producer flow control and it had to block the full TCP
connection that they both share. That scenario is possible, but requires
several not-very-likely things to be true at the same time, so it strikes
me as unlikely.

Also, your suggestion about ActiveMQ waiting because it's busy sounds like
the description of a performance problem, which would be expected to result
in acks eventually (though slowly) being processed, not of a correctness
problem where 100% failure occurs, so if I've correctly understood what you
suggested, then I think it's not likely to be what's happening.

BTW, is producer flow control kicking in when this occurs? And when temp
fills, is it eventually clearing, or does it fill and stay full forever
(even if you stop the producers)?

Tim

On Tue, Jul 18, 2017 at 4:00 AM, akpuvvada <akp4tibco@gmail.com> wrote:

> TestActiveMQ.zip
> <http://activemq.2283324.n4.nabble.com/file/n4728623/TestActiveMQ.zip>
>
> Attached the TIBCO BW Project I am using.
>
> It is not a Java code, TIBCO BW is a GUI (Zero Coding) Integration tool
> that
> stored the configuration in XML and converts the XMLs to Java code at
> Run-time and execute. So I have no idea how this actually works and when
> the
> acknowledge() gets executed.
> However, I can confirm from the logs that Acknowledgement is sent by the
> code.
>
> Active MQ is not accepting or not processing the acknowledgement.
> I read that Client acknowledgement is actually "Acknowledge All Previous".
> Would Active MQ wait to process Acks if it is too busy with other things.
> Producer is producing at a very fast rate and temp space has filled-up fast
> when this is observed. Could that be an issue?
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-MQ-Performance-with-CLIENT-Ack-tp4728551p4728623.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

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