Re: Message-Level Authorization - for producers

Although I haven't done this myself, the documentation on custom interceptors (http://activemq.apache.org/interceptors.html) sounds like there are far more options available than just the one from the class you referenced. The send() method would be the one I'd expect you'd want to implement. On

Re: activemq ramdomly re-deliver messages to consumer

That version of ActiveMQ is five and a half years old. It's possible that the behavior you're seeing is still a bug in the current version, but it's quite possible that it's been fixed in one of the nine minor releases (and more incidental releases) since then. Upgrading to a more recent version

activemq ramdomly re-deliver messages to consumer

All I have a strange issue with activemq. I see sometimes it re-deliver the same messages to consumers. Sometimes this happens the same day, some times it happens after couple days. Here are my setups: AMQ version 5.5.1 running active/backup mode using JDBC as persistent I can see messages are

Re: Fwd: Deadlock caused by ActiveMQMessageConsumer.dispatch() due to onEvent invocation

This is definitely a bug, the question is whose bug it is (whose code should change): ActiveMQ, Mule, Spring, or some combination of the three. I looked in http://grepcode.com/file/repo1.maven.org/maven2/org. springframework/spring-jms/3.0.0.RELEASE/org/springframework/jms/connection/

Re: Unmatched acknowledge: MessageAckExpected - message count (1) differs from count in dispatched-list (2)

Please submit this as a bug in JIRA. Tim On Mar 12, 2017 11:48 PM, "xabhi" wrote: > Observed below exceptions in STOMP consumer after failover. The consumer > continued to receive messages but this exception kept coming on both client > and server side and when the master

javax.jms.JMSException: Cannot send, channel has already failed: tcp://127.0.0.1:61616

Hi all, I currently have a Jboss Fuse 6.2.1 with 5 root containers and 6 child containers each. We have a replicated mode broker profile deployed on mq-01, mq-02, mq-03, mq-04, mq-05. One of the 6 child containers is a mq-XX the same applies to the other child containers. In order to find the

Re: The size of KahaDB doesn't seem to decrease

Best place to start is in the docs, see why the files are being retained. http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html On 03/13/2017 06:39 AM, Hidekazu wrote: I use ActiveMQ ver 5.14.3. I thought the size of kahaDB wouldn't get bigger if ActiveMQ could sent

Re: The size of KahaDB doesn't seem to decrease

Hi there, we had the same issue when we were using topics and had durable subscribers which wouldn't connect for up to 4 days. The kahadb files would only be cleaned up when the last durable subscriber has received the message. In our case the topic in in question didn't have a lot of

The size of KahaDB doesn't seem to decrease

I use ActiveMQ ver 5.14.3. I thought the size of kahaDB wouldn't get bigger if ActiveMQ could sent data to subscriber. However, the size of kahaDB continues increasing even it can send all the data to subscriber. There is no pending queue in GUI management console. Is there any necessary

Unmatched acknowledge: MessageAckExpected - message count (1) differs from count in dispatched-list (2)

Observed below exceptions in STOMP consumer after failover. The consumer continued to receive messages but this exception kept coming on both client and server side and when the master activemq instance took over after another failover, all the messages were redelivered and below warning went