My query is for the product Red Hat AMQ 7.X (and I am using 7.2), which is based on Apache ActiveMQ Artemis and a .Net client connecting to the queue using AMQP protocol.
An Artemis article discusses unicast (point-to-point), multicast (publish-subscribe) and a combination of these addressing: https://activemq.apache.org/artemis/docs/2.0.0/address-model.html
It does not detail the case of two consumers connecting to the same multicast queue under an address. Our requirement is to
Have pub-sub model of communication, with the publisher publishing to a multicast address.
Have many queues that can take action based on the published message, say one queue for "FollowupJob" and another for "MailerComponent".
Have X number of consumers - "MailerComponent" connect to one queue to distribute the load so that the messages delivered to that queue is distributed between the X consumers in a round robin fashion.
A later section describes such a configuration: https://activemq.apache.org/artemis/docs/2.0.0/address-model.html#configuring-a-shared-durable-subscription-queue-with-up-to-10-concurrent-consumers
It seems to meet my need, but I wanted to double-check as the explanation above did not cover this scenario.
Any queue (whether multicast or anycast) can support multiple consumers unless you've set max-consumers to 1 or exclusive to true.
Related
My experience with setting up Tibco infrastructure is minimal, so please excuse any misuse of terminology, and correct me where wrong.
I am a developer in an organization where I don't have access to how the backend is setup for Tibco. However we have bandwidth issues between our regional centers, which I believe is due to how it's setup.
We have a producer that sends a message to multiple "regional" brokers. However these won't always have a client who needs to subscribe to the messages.
I have 3 questions around this:
For destination bridges: https://docs.tibco.com/pub/ems/8.6.0/doc/html/GUID-174DF38C-4FDA-445C-BF05-0C6E93B20189.html
Is a bridge what would normally be used, to have a producer send the same message to multiple brokers/destinations or is there something else?
It's not clear in the documentation, if a bridge exists to a destination where there is no client consuming a message, does the message still get sent to that destination? I.e., will this consume bandwidth even with no client wanting it?
If the above is true (and messages are only sent to destinations with a consumer), does this apply to both Topics and Message Selectors?
Is a bridge what would normally be used, to have a producer send the same message to multiple brokers/destinations or is there something else?
A bridge can be used to send messages from one destination to multiple destinations (queues or topic).
Alternatively Topics can be used to send a message to multiple consumer applications. Topics are not the best solution if a high level of integrity is needed(no message losses, queuing, etc).
It's not clear in the documentation, if a bridge exists to a destination where there is no client consuming a message, does the message still get sent to that destination? I.e., will this consume bandwidth even with no client wanting it?
If the bridge destination is a queue, messages will be put in the queue.
If the bridge destination is a Topic, messages will be distributed only if there are active consumers applications (or durable subscribers).
3 If the above is true (and messages are only sent to destinations with a consumer), does this apply to both Topics and Message Selectors?
This applies only to Topics (when there is no durable subscriber)
An alternative approach would be to use routing between EMS servers. In this approach Topics are send to remote EMS servers only when there is a consumer connected to the remote EMS server (or if there is a durable subscriber)
https://docs.tibco.com/pub/ems/8.6.0/doc/html/GUID-FFAAE7C8-448F-4260-9E14-0ACA02F1ED5A.html
I have two ActiveMQ brokers (A and B) that are configured as a cluster of network of brokers with a static list.
Normal message consumption and store and forward works as expected. That is: messages on A with no consumers connected will be picked up by a consumer connected to broker B.
I do see that this is not the case for advisory messages.
In my current setup I have an application that is monitoring the DLQ by connecting to the advisory: ActiveMQ.Advisory.MessageDLQd.Queue. I need this to trigger certain actions when messages arrive in the DLQ.
When testing the cluster I don't see any advisory messages for DLQ messages on broker A coming through to my monitoring application connected to broker B.
Any idea how I can have advisory messages also stored and forwarded just like normal queue messages?
Advisory Messages are not really meant for that sort of thing, they are Topic based event information specific to a given broker. The brokers can use them to discover activity on another broker or a client can listen to the broker it is connected to for information on activity there but broadcasting advisories across networks would lead to confusion as you have no context on where the advisory came from or how it was acted on.
I have a master/slave AMQ broker setup for JMS messaging. I have two servers that I would like to setup as a master/slave durable consumers using Apache Camel. We've been achieving this by having both servers attempt to connect with the same client ID. One node handles all of the work but if it goes down the other node connects and picks right back up on the work. This has been working fine for having a single consumer at a time but it makes noise in disconnected server's log files with the message
ERROR org.apache.camel.component.jms.DefaultJmsMessageListenerContainer]
(Camel (spring-context) thread #0 - JmsConsumer[global.topic.event]) Could
not refresh JMS Connection for destination 'global.topic.event' - retrying
using FixedBackOff{interval=5000, currentAttempts=12,
maxAttempts=unlimited}. Cause: Broker: broker - Client: client already
connected from tcp://xxx.xx.xx.xxx:xxxx
Is there a proper way to get the functionality that I'm looking to achieve? I was considering having the slave server ping the master to coordinate which one is connected but I'd like to keep the implementation as simple as possible.
Convert your usage of topics on the consumer side to Virtual Topics. Virtual Topics allow you to continue to have existing message flows produce and consume from the topic, but also have consumers listen on specially named queues.
Once you are consuming from a queue, you can implement all the consumer patterns-- exclusive consumer (which allows that hot-standby backup consumer), message groups, parallel consumers, etc.
Can there more than one listener to a queue manager ? I have used one listener/queue manager combination so far and wonder if this possible. This is because we have 2 applications connecting to same queue manager and seems to have problem with that.
There are a couple meanings for the term listener in an MQ context. Let's see if we can clear up some confusion over the terminology and then answer the question as it relates to each.
As defined in the spec, a JMS listener is an object that implements a callback mechanism. It listens on destinations for messages and calls onMessage when they arrive. The destinations may be queues or topics hosted by any JMS-compliant transport provider.
In IBM MQ terms, a listener is a process (runmqlsr) that handles inbound connection requests on a server. Although these can handle a variety of protocols, in practice they are almost exclusively TCP listeners that bind a port (1414 by default) and negotiate connection requests on sockets.
TCP Ports
Tim's answer applies to the second of these contexts. MQ can listen for sockets on multiple ports and indeed it is quite common to do so. Each listener listens on one and only one port. It may listen on that port across all network interfaces or can be bound to a specific network interface. No two listeners can bind to the same combination of interface and port though.
In a B2B context the best practice is to run a dedicated listener for each external business partner to isolate each of their connections across dedicated access paths. Internally I usually recommend separate ports for QMgr-to-QMgr, app-to-QMgr and interactive user connections.
In that sense it is possible to run multiple listeners on a given QMgr. Each of those listeners can accept many connections. Their job is to negotiate the connection then hand the socket off to a Message Channel Agent which talks to the QMgr on behalf of the remotely connected client or QMgr.
JMS Listeners
Based on comments, Ulab refers to JMS listeners. These objects establish a connection to a queue manager and then wait in GET mode for new messages arriving on a destination. On arrival of a message, they call the onMessage method which is an asynchronous callback routine.
As to the question "can there more than one (JMS) listener to a queue manager?" the answer is definitely yes. A multi-threaded application can have multiple listeners connected, multiple application instances can connect at the same time, and many thousands of application connections can be handled by a single queue manager with sufficient memory, disk and CPU available.
Of course, each of these applications is ultimately connected to one or more queues so then the question becomes one of whether they can connect to the same queue.
Many listeners can listen on the same queue so long as they do not get exclusive access to it. Each will receive a portion of the messages arriving.
Listeners on QMgr-managed subscriptions are exclusively attached to a dynamic queue but multiple instances on the same topic will all receive the same messages.
If the queue is clustered and there is more than one instance of it multiple listeners will be required to get all the messages since they will normally be distributed by MQ workload distribution across those instances.
Yes, you can create as many listeners as you wish:
http://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.explorer.doc/e_listener.htm
However, there is no reason why two applications can't connect to the queue manager via the same listener (on the same port). What problem have you run into?
Can I set up one MDB to listen to more than one listener port? Each listener port will be connected to one particular queue.
If not, why is the restriction that one MDB can listen to only one port?
No. An MDB may only be associated with one listener port (or one activation specification).
As a possible workaround to this limitation, you can configure your MDB multiple times so that each one can be bound to a different queue (listener port / activation spec).
MDBs are deployed to an application server. The application server is typically only listening on one port. You can build a simple java application that creates different connections to different servers; in a configurable way though. Just not as MDBs.
MDB's are a layer(probably several) of abstraction(s) above the concept of a port. Most messaging implementations will broker traffic across a single port,but likely a combination of data/control ports.
Think of the broker like a mail depot the letters come in and the broker puts them in the right mailbox while providing a number of other services(peer failover/communication, persistence, guaranteed delivery, message acknowledgment, etc.).
MDBs are the agents that subscribe to those abstract mailboxes. They really have no understanding of the underlying architecture. As far as they are concerned things are all happening locally in memory. Their only job is to adhere to the EJB standard and the container (typically through the application of more low level standards like JCA layered again over raw sockets) takes care of making sure the messages arrive at their destinations.
Maybe it would be helpful if you further elaborated on why you are concerned about how your MDBs relate to ports