Re: Virtual topics, custom prefix limitations

Hi Tim, We managed to get working virtual topics in a 2 broker network, but only for cases where producer and consumers are using the same broker; consumers connected to the broker where the producer is not present did not receive messages. We confirmed the network functions as expected for

Re: ActiveMQ NMS and Failure Recovery

That's a great idea! -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717873.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

I think you may be able to remove a lot of your exception handling code if you turn on failover:. It's so universal, I'm almost tempted to propose making it the default, and you would have to say nofailover: if you didn't want it. On Thu, Oct 13, 2016 at 8:53 AM magmasystems

Re: ActiveMQ NMS and Failure Recovery

Thanks, Jim. If failover works with a single instance, then I surely did reinvent the wheel :-) -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717869.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

Yes, failover works on a single instance. I think I mentioned that in my first reply. You don't need to list two brokers. You just need to have the failover: keyword in the connection URI. On Thu, Oct 13, 2016, 7:49 AM Tim Bain wrote: > Yes, the failover transport works

HornetQ client connect to Artemis server

We are in the process upgrading from HornetQ (2.4.7) to Artemis (1.4.0). Artemis server migration itself is working - server running and Artemis client can talk to server. However, we still need to support clients who use HornetQ client. We need HornetQ clients to be able to talk to the Artemis

Re: ActiveMQ NMS and Failure Recovery

Yes, the failover transport works in all three dialects (Java, .NET, and C++). On Oct 13, 2016 7:08 AM, "magmasystems" wrote: > Thanks guys. As I mentioned, the devs tend to do stuff on their laptops > without running multiple instances of ActiveMQ. They basically

increasing number of pending message when consumer hit wrong url

hai everyone this my first time using C, i have problem in my consumer, i have 1 number of pending message, when i set wrong url in the consumer's config and i start it, my number of pending message increased is there any problem using one of these in run method ? //session =

Re: ActiveMQ NMS and Failure Recovery

Thanks guys. As I mentioned, the devs tend to do stuff on their laptops without running multiple instances of ActiveMQ. They basically go to the ActiveMQ directory, run the activemq.bat file, do some debugging, and then CTRL+C out of ActiveMQ. If there are any patterns or tricks we could use to

Re: Duplicating messages published to a Topic to a Queue

Thanks! Diverting was exactly what I was looking for. Creating a non-exclusive divert from the topic to the queue did the trick without any class changes. Very nice. Using the Spring support for declarative configuration management it is pretty easy to declare diverts. A few things bit me on

Ghost Consumers on queue with exclusive consumer

A solution uses several queues where consumer of the queues are using the exclusive consumer pattern to make sure a single node gets all messages. After upgrade to 5.13.3 from 5.9.1 some queues are getting ”ghost consumers”. I.e. consumers with *no connection* that cannot be removed. (attached

Re: ActiveMQ NMS and Failure Recovery

Like Jim, I think that the failover transport should be capable of doing the reconnect for you when debugging (and it's definitely capable of doing it when there isn't a debugger in the mix), but it's possible that this is one of the situations that illustrate the saying, "In theory, theory and

Re: java.io.EOFException when ActiveMQ starts

I've never tried configuring a broker with a static networkConnector connected to itself (why would I, it's a useless configuration), but it wouldn't surprise me if the broker rejected that self-connection, which could result in the EOFException you saw. It's also possible that there's something