Re: Virtual topics, custom prefix limitations

[Devlin]

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 standard
topics/queues, but not for virtual topics.

I found this in the docs, looks interesting, not sure if it would help, but
regardless, it's for 5.13, we're on 5.11.
   
 .
  

Here's our config:
   








   










   




 



  

  

  

  
  
  

  
  

  






--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717887.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

[magmasystems]

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

[Jim Gomes]

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 
wrote:

> 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

[magmasystems]

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

[Jim Gomes]

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 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 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
> > get automatic failover out of a single instance, I would love to know
> about
> > it. Could you do something like:
> >
> > failover:(tcp://localhost:61616,tcp://remotehost:61616)
> >
> > H ... according to
> > http://activemq.apache.org/failover-transport-reference.html, you should
> > be
> > able to. But, will that work with ActiveMQ NMS?
> >
> > -marc
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717859.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>

HornetQ client connect to Artemis server

[hcrobison]

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
server. The current problem I am running into is the following
exception.org.hornetq.api.core.HornetQConnectionTimedOutException: HQ119013:
Timed out waiting to receive cluster topology. Group:nullat
org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:946)
~[hornetq-core-client-2.4.7.Final.jar:na]Please let me know what I need to
provide for further investigation.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/HornetQ-client-connect-to-Artemis-server-tp4717861.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

[Tim Bain]

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 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
> get automatic failover out of a single instance, I would love to know about
> it. Could you do something like:
>
> failover:(tcp://localhost:61616,tcp://remotehost:61616)
>
> H ... according to
> http://activemq.apache.org/failover-transport-reference.html, you should
> be
> able to. But, will that work with ActiveMQ NMS?
>
> -marc
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717859.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

increasing number of pending message when consumer hit wrong url

[MariscaJane]

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 = connection->createSession( Session::AUTO_ACKNOWLEDGE );
//session = connection->createSession( Session::CLIENT_ACKNOWLEDGE );

my first message didnt consumed, still in number of pending message, but my
number of pending message increased T_T

can you help me ?
thank you



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/increasing-number-of-pending-message-when-consumer-hit-wrong-url-tp4717857.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

[magmasystems]

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
get automatic failover out of a single instance, I would love to know about
it. Could you do something like:

failover:(tcp://localhost:61616,tcp://remotehost:61616)

H ... according to
http://activemq.apache.org/failover-transport-reference.html, you should be
able to. But, will that work with ActiveMQ NMS?

-marc



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717859.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Duplicating messages published to a Topic to a Queue

[Lachezar Dobrev]

  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 the way though:
  - diver name must be specified, otherwise the diver is ignored with a log
message (easily missed)
  - to divert topic named "topic.whatever" the address must be
"jms.topic.topic.whatever"
  - to divert to a query named "query.whatever" the forwarding address must
be "jms.queue.queue.whatever"

  Otherwise the diverts work pretty well, I even managed to catch one queue
message being processed on a different node than the one sending the topic
message, which is exactly what I was hoping for.

  Thanks again for the directions.

2016-10-07 13:10 GMT+03:00 Martyn Taylor :

> I don't have enough information to understand you problem fully.  But
> perhaps you could use a combination of duplicate detection and diverts
> could solve your problem.
>
> https://activemq.apache.org/artemis/docs/1.4.0/duplicate-detection.htm
> https://activemq.apache.org/artemis/docs/1.4.0/diverts.html
>
> Cheers
> Martyn
>
>
>
> On Mon, Oct 3, 2016 at 2:54 PM, Lachezar Dobrev 
> wrote:
>
> >   Hello all,
> >
> >   I have a design problem: a topic is clustered in a network of brokers
> to
> > allow multiple nodes to handle events occurring in other nodes: i.e. a
> user
> > logs in on one node, but all nodes *might* need to know that.
> >   A new requirement has surfaced, that copies of these messages need to
> be
> > sent to an external system (not a messaging system). The trivial solution
> > is to add a new subscriber to the Topic that handles the delivery, but
> > since this is a distributed system of equivalent nodes that ends up
> sending
> > the message multiple times, one per node in the cluster.
> >
> >   My current solution is to use Springframework's infrastructure (which
> the
> > Application is based on), and override the JMSTemplate with a custom one
> > that sends a copy of every message sent to the Topic to a special Queue
> > that the deliverer is handling. This seems to work just fine.
> >
> >   I'm wondering if there is any out-of-the-box solution to this problem
> > provided by Artemis. Like routing/duplication/monitoring that I can turn
> on
> > and get the same (or similar) functionality.
> >
> >   Lachezar
> >
>

Ghost Consumers on queue with exclusive consumer

[Petter Nordlander]

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 JMX 
screenshot)

It does not go away by restarting the consuming applications, the broker or by 
removing the queue.
The problem is with exclusive consumer – this ”ghost” can get hold of the 
”exclusiveness” and no messages will flow.

Have anyone seen such a thing? What can be the cause. It has appeared on 
multiple queues, not just a single one.

Clients are JMS/OpenWire clients with client lib 5.13.3 and 5.9.1.


Hälsningar / Best Regards
Petter Nordlander

Fourmation AB
pet...@fourmation.se
fourmation.se

Re: ActiveMQ NMS and Failure Recovery

[Tim Bain]

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
practice are the same thing..."

Also, I'd be cautious about that proxy object layer.  If that layer is
performing reconnections outside the context of breakpoints that mess
things up, it probably means something else is wrong with your
configuration (since the failover transport should be taking care of it
seamlessly for you), and you risk having your proxy object layer mask those
configuration problems.  So I'd recommend including a way to tell when the
proxy layer has to do a reconnect (it should never happen), and if you see
it happening, dig in to why the failover transport isn't doing that for
you.  I'm not saying you shouldn't use it, but monitor it and dig in as
necessary.

Tim

On Wed, Oct 12, 2016 at 2:16 PM, Jim Gomes  wrote:

> It seems like you reinvented the wheel a little bit there, but I'm glad you
> got it to work for you.
>
> Cheers!
>
>
> On Wed, Oct 12, 2016, 8:36 AM magmasystems 
> wrote:
>
> > Thanks Jim and Tim. I managed to hook up a poor-man's recover mechanism.
> > Our
> > application uses a framework that sits over the various low-level
> messaging
> > APIs, such ActiveMQ NMS, Tibco EMS .NET client, and the .NET RabbitMQ
> > client. So we actually have thin "proxy objects" sitting on top of the
> > native MessageConsumers and MessageProducers. When we detect a broker
> > failure, we instantiate a new connection and new sessions, and we
> recreate
> > the MessageConsumers and MessageProducers that the application was using.
> > Not the most elegant solution, but it was accomplished in a few lines of
> > code and seems to work.
> >
> > The most difficult thing to do (which is not too difficult, and only
> > involved finding the correct combination of BindingFlags to use) is to
> copy
> > the listener from the old MessageConsumer to the new MessageConsumer.
> >
> > var handler = typeof(MessageConsumer).GetField("listener",
> > BindingFlags.DeclaredOnly | BindingFlags.Instance |
> BindingFlags.NonPublic
> > |
> > BindingFlags.GetField).GetValue(nativeMessageConsumer);
> > newMessageConsumer.Listener += handler;
> >
> > So
> >
> >
> >
> > --
> > View this message in context:
> > http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-
> tp4717704p4717848.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>

Re: java.io.EOFException when ActiveMQ starts

[Tim Bain]

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 wrong with your SSL configuration as you suggested; there's no
good way in a mailing list discussion to check whether your truststore
trusts your keystore and the certs are being presented properly since
that's all about the binary content and you shouldn't be sharing that
publicly, but you could test the SSL configuration by setting up two
brokers (in a test environment) that each have their JMS_X_SITE_CSV_URL
pointed at each other.  If that configuration gives you EOFExceptions, then
switch to using the tcp transport and see what happens.  If you get errors
with the ssl transport but not the tcp one, there's a good chance it's
something wrong with your keys.

As far as the current configuration (where you have a broker whose only
networkConnection is a static:ssl: one to itself), it's not a useful
configuration (having a networkConnector to yourself serves no purpose),
and you proved early on in this discussion that removing it removes the
WARN log line that you're concerned about.  So I disagree with your
statement that "I feel the configuration still seems fine."  Either switch
to something that serves the purpose you said you're trying to achieve
(like the discovery: transport instead of the static: transport, or like
listing your cross-site servers if you're going to continue using the
static: transport) or take it out and eliminate the WARN line.

Tim

On Wed, Oct 12, 2016 at 10:25 AM, divinedragon  wrote:

> Oh ok. Anyhow, I feel the configuration still seems fine.  It still doesnt
> explain the WARNING entry.
>
> On Oct 12, 2016 8:53 PM, "Tim Bain [via ActiveMQ]" <
> ml-node+s2283324n4717847...@n4.nabble.com> wrote:
>
> > Unfortunately the use of the term "discovery" is misleading.  The term is
> > used as a generic superset over the discovery transport (which allows
> > dynamic discovery at runtime) and the static transport (which allows
> > static
> > discovery at configuration time based on what's in your config file, but
> > no
> > dynamic discovery at runtime; the phrase "hard code" from the page you
> > linked to is the relevant one).  It doesn't inherently mean you get
> > dynamic
> > discovery; you need to use the discovery transport for that.
> >
> > On Oct 12, 2016 7:25 AM, "divinedragon" <[hidden email]
> > > wrote:
> >
> > > I was referring to this(static discovery section).
> > >
> > > http://activemq.apache.org/networks-of-brokers.html
> > >
> > >
> > > On Wed, Oct 12, 2016 at 6:44 PM, Tim Bain [via ActiveMQ] <
> > > [hidden email]  type=node=4717847=1>>
> > wrote:
> > >
> > > > I don't see anywhere that you're using the discovery transport (
> > > > http://activemq.apache.org/discovery-transport-reference.html); am I
> > > just
> > > > not seeing it?  Automatic broker discovery isn't the default
> behavior;
> > > you
> > > > have to use the discovery transport if you want that behavior.
> > > >
> > > > On Oct 12, 2016 7:08 AM, "divinedragon" <[hidden email]
> > > > > wrote:
> > > >
> > > > > I wanted to configure automatic broker discovery. As of now, I just
> > > have
> > > > > one broker(localhost) and that is what I configured. Isn't it how
> > that
> > > > > should be configured?
> > > > >
> > > > > On Wed, Oct 12, 2016 at 6:02 PM, Tim Bain [via ActiveMQ] <
> > > > > [hidden email]  > > type=node=4717831=1>>
> > > > wrote:
> > > > >
> > > > > > OK.  And is it really pointing to localhost   (i.e. this broker
> is
> > > > > > connecting to itself)?  I've never tried that myself, but I can't
> > > > imagine
> > > > > > that resulting in good behavior...  How come that URI isn't to
> > some
> > > > other
> > > > > > (cross-site) host?
> > > > > >
> > > > > > Tim
> > > > > >
> > > > > > On Oct 12, 2016 1:04 AM, "divinedragon" <[hidden email]
> > > > > > > wrote:
> > > > > >
> > > > > > > Oh my bad. Sorry about the type. The value is this.
> > > > > > >
> > > > > > > JMS_X_SITE_CSV_URL=ssl://localhost:7031/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Oct 12, 2016 at 12:23 PM, Tim Bain [via ActiveMQ] <
> > > > > > > [hidden email]  > > > > type=node=4717827=1>>
> > > > > > wrote:
> > > > > > >
> > > > > > > > It looks like you're using the tcp transport to connect to an
> > SSL
> > > > > > > > endpoint;
> > > > > > > > shouldn't you either use the ssl transport or port 7029?
> > > > > > > >
> > > > > > > > On Oct 12, 2016 12:38 AM, "divinedragon" <[hidden email]
> > > > > > > >