I found this RabbitMQ "extension" listed here: http://www.rabbitmq.com/direct-reply-to.html, I set the RabbitTemplate's "replyQueue" with amq.rabbitmq.reply-to I tried it with an already function RPC call, and it had functioned, but now it just times out.
Any help is appreciated!
When using a fixed reply queue (whether user-specified or the amq.rabbitmq.reply-to) you have to configure a <reply-listener/> - see the Spring AMQP documentation. for the amq.rabbitmq.reply-to you should set the reply container's acknowledge to NONE (which is no-ack in RabbitMQ speak).
CORRECTION: The RabbitTemplate does not currently support Direct reply-to for sendAndReceive() operations; you can, however, specify a fixed reply queue (with a reply-listener). Or you can use rabbitTemplate.execute() with a ChannelCallback to consume the reply from that "queue" (and publish).
I have created a JIRA issue if you wish to track it.
1.4.1 and above now supports direct reply-to.
Related
I implemented a RabbitMQ Direct-Reply-To functionality based on the answer from Gary Russell (the second one)
Problem with RabbitMQ Direct reply-to with Spring.
Now, everything is working as intended, but when Im checking the messages on the RabbitMq Overview, around half of the messages is "Unroutable (Drop)". While I dont see any messages, that are not answered, I'm still worried and want to resolve this problem or are those messages just Unroutable because I'm using the Direct-Reply-To Exchange?
Greetings
Jan
I am currently exploring de-duplication strategies within Active MQ. Artemis supports duplicate detection, but I'm not sure about ActiveMQ 5
Is it possible to prevent a message from being placed on a queue if it currently exists on the queue in ActiveMQ 5?
Messages which are no longer on the queue and have been so in the past will be allowed back on the queue.
The underlying capability I am trying to achieve is flow control in which multiple messages of the same value are not placed on the queue as to remove duplicate processing.
Based on the documentation, I have tried using the message property defined _AMQ_DUPL_ID, but I am still experiencing duplication. I suspect this may not be supported in ActiveMQ 5 and am unsure what alternative option is. I'm open to suggestions.
NOTE: The Active MQ instance being used is provided by Amazon MQ.
As you suspect, ActiveMQ 5.x doesn't support automatic duplicate detection. This is only supported in ActiveMQ Artemis. That said, messages are not removed from the broker's duplicate ID cache when the message is consumed from the queue. This is because in most cases a duplicate sent after the message is consumed is still considered a duplicate.
You may be able to implement some kind of duplicate detection in a broker plugin, but I have no idea of Amazon MQ supports adding custom plugins. It's more likely that you'll have to implement duplicate detection in the clients themselves.
We are migrating from Tibco to start using ActiveMQ Artemis. There are several ack settings that are available on Tibco, but we haven't found anything that's simply similar to this in Artemis. We are using the amqpnetlite .NET library to interface with Artemis, and as part of our code using DistributionMode to either move or copy based on the boolean value we are assigning to a configuration flag that we are calling as UseAutoAcknowledge. I haven't found much documentation about DistributionMode but for one that isn't very clear here - http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-messaging-v1.0.html.
My question is if DistributionMode is set to move - does Artemis send an acknowledgement to the client and doesn't when it is set to copy?
I can't talk to Tibco but I can try to explain AMQP DistributionMode. Essentially the DistributionMode is a setting as to the behaviour of the receiver - a receiver with a move mode is expecting the messages to be sent only to it, not to other receivers - this is the normal behaviour of a consumer on a queue. A receiver with a copy mode is expecting other receivers to also receive the message (like a queue browser, or - sort of - like a subscriber to a topic). In a traditional Client-Broker topology, the DistributionMode is only really interesting when receiving messages from the Broker, and is unlikely to have effect when sending messages to the Broker.
Acknowledgement is separate from the DistributionMode. AMQP has the concept of Disposition which is similar to but not the same as Acknowledgement. Disposition is ultimately the action that the sender will apply at the completion of the message transfer (and so interacts with DistributionMode for messages sent by the Broker). Conceptually for each message transfer a Broker might decide that the transfer has completed successfully; that it has failed - but in a way that retrying might succeed; that it has failed in a way that will not succeed on retry; or some other more subtle outcome. Here the behaviour at the Broker is probably different depending upon whether the DistributionMode was move or copy (the specification left this vague to allow flexibility in implementations). If the receiver is asking for messages to be moved, and it declares that the transfer was unsuccessful, a broker is likely to make that message available for all competing consumers. If the receiver was asking for copy, then it never held an exclusive lock on the message, and so the choice is only whether to retry sending the copy to that same consumer.
Perhaps the simplest thing here is if you can describe the behaviour that you desire, and experts on Apache Artemis can weigh in on if/how that can be achieved.
I'm quite new to camel so excuse me if this is obvious.
We're trying to set up a camel route (in talend esb) which does the following:
receive a Message by JMS
db update
send the message to another system by JMS using request/reply
use the information in the reply to do another db update
This is all in one route.
What I have found out is that the route doesn't accept any more Messages in 1. while it is waiting for the reply in 3.
I have tried to use the "asyncConsumer" parameter on the JMS component but that didn't help.
How can I design the route so that it can process a second (and more) Message while it is still waiting for a reply in 3. ?
Thanks,
Laci
The parameter Petter explained will help but you will still block threads. Another approach is to design the integration as two separate routes. In the first route you receive the jms message, update the db and send out the second message.
If you use InOnly on the producer of this route and set a JMSReplyTo as well as preserveMessageQuo=true then camel will send out the message but not wait for a reply.
Then you use a second route that listens on the reply to queue you specified and does the second db update. This way you do not block any threads.
Use the concurrentConsumers attribute. It will enable multiple threads to handle your load. Note that you have to specify the number of threads. This can be a bit complex with all options, so be sure to read the Camel JMS documentation properly.
example
from("jms:myQueue?concurrentConsumers=10")
You may want to specify concurrentConsumers on the reply queue for the request reply as well:
.inOut().to("jms:requestQueue:foo?concurrentConsumers=10")
The last part Requires version 2.10.3 though.
Messaging middleware solutions (JMS, Tibco, etc.) allow publish/subscribe with "topic" filtering using wildcards to subscribe to all messages of a certain "topic", e.g. SUBSCRIBE("ACCOUNT.*") topic allows you to subscribe to both "ACCOUNT.WITHDRAW" message and "ACCOUNT.CHECKBALANCE" message.
The problem is that such subscription also receives my own published messages.
I'm looking for a mechanism, similar to, say, UDP multicast loopback which can be turned ON or OFF by the transport layer without messing with the data being sent.
Is there a common, declarative (no custom code, configuration only) way to configure the middleware not to receive messages which that very same service instance has published? Ideally, this should also be able to filter out everything published by ALL servers (nodes) of the same "kind".
Thanks in advance.
The JMS API contains this option for TopicSubscribers, e.g. TIBCO EMS let's you create a consumer with the "noLocal" property. That means no messages published over the same connection, get consumed by clients on the same connection.
e.g. take a look here how to create a topic subscriber with the "noLocal" option:
https://docs.tibco.com/pub/enterprise_message_service/7.0.1-march-2013/doc/html/tib_ems_api_reference/api/javadoc/javax/jms/TopicSession.html
No one is answering, so I'll chime in (in a hand-wavey way).
I believe there's nothing in the JMS spec around controlling whether you get your own sent messages back on a topic receiver. So any capability like this would be a non-portable vendor feature. Especially for your second requirement (based on "kind" of JMS client versus some control based on the same connection doing the sending/receiving).
If you've got no flexibility to modify code or message content (properties), I think you've got no portable solutions. And likely no solution at all for that second "kind" requirement.
If you want to investigate vendor-specific options, you'll need to tell us which vendor you're interested in. You may get nothing, but there's no way to know without asking.