I did a few test and this work when I have a lot of message of Version2 and
Version1.
And the first test I send 5000 messages of each versions, and the consumer
starting process normal, and when process 500 messages stop, and start to
process again when all the messages was in the queue.
In other
Right now scheduled messages only use KahaDb… not LevelDB… so even if you
setup your instance for LevelDB the store is created as KahaDB.
That means that if your box crashes, and it’s promoted to another machine
via ZK, then you lose all your scheduled messages.
Apparently it doesn’t look like
Start by looking for any messages sitting around, even small numbers of
messages. DLQs are a prime candidate.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/kahadb-cleanup-problem-tp4677917p4687774.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Not trying to ignore any possible issue here...
Is it feasible to use two different queues? One for each version.
That may be the best way to go for many reasons.
--
View this message in context:
Yes for the moment I'm using this
destinationInterceptors
virtualDestinationInterceptor
virtualDestinations
compositeQueue name=transactionQueue
forwardTo
JMX has all the information needed.
Another approach - outside the JVM - netstat.
Something like this may work:
netstat -an | grep 61616
Then use awk or the like to pull out the remote (client) IP address and then
sort | uniq -c to get the counts.
--
View this message in context:
Do you mean get the JMS destination from the received message? If so,
getJMSDestination() should do the job.
https://docs.oracle.com/javaee/6/api/javax/jms/Message.html#getJMSDestination()
--
View this message in context:
