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 <akp4ti...@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. >
