By using only one JMS Queue, is it possible for an application to consume and produce on it ?
Or it needs to use two JMS Queue ? One for consuming and other for producing.
Thanks you in advance.
Yes it is perfectly valid to have one application to produce and consume messages from the same Q.
Be careful with the transaction demarcation, ie "commit" the transaction after sending the message in order for the message to be "visible" to the consumer, including the consumer in your your application
Related
I need to build scalable application that have several Java applications (Spring RabbitMQ producers) that consume messages from other applications by HTTP protocol, calculating priority of message, and send them in to 'priority queue' that matches the params.
So far under load of hundreds of messages per second, one application works just fine, but there is need to scale up applications.
The problem is that I don't really understand how does RabbitMQ producers work with 'priority queues'. I've been searching information in RabbitMQ documentation and I found docs that says that every producer needs to get acks to make sure that messages have proceed successfully.
So the questions are
Docs says that priority of messages calculated under hood AMQP protocol, so do RabbitMQ will send acks to producer after the position for messages will be selected or before
How does messages will be treated if assume that we have 2 producers that produce 2 different messages with same priority to the same 'priority queue'
I will be appreciated for any hint that will help me with that!
I have a queue with one producer and two consumers using CLIENT_ACKNOWLEDGE. The two consumers share the connections, but they live in different threads so each uses its own session.
What happens if consumer A does not acknowledge the last message received? In which scenario the message will be re-delivered and consumed by consumer B? Is it when the session consumer A is using is closed? Do I need some configuration on JMS provider to dictate what happens in such a scenario?
I don't think this situation is directly addressed in the JMS specification so the answer will ultimately depend on what JMS broker you're using. However, having worked on multiple JMS brokers in the past I would say that generally speaking any message that has been dispatched by the broker to a consumer but which hasn't yet been acknowledged by that consumer will be cancelled back to the broker and will be made available for redelivery once the consumer in question is closed.
I am pretty new to RabbitMQ, I want to to consume multiple messages from RabbitMQ so that work can be done parallely also sending acknowledgement only when any of the actor has finished it's task so as not to loose messages. How should I proceed, I want to use spring support for AKKA.
Can I use an actor as a consumer or it should be a plain consumer that can consume multiple messages without sending acknowledgement for any of the message or it should be that I have multiple classes/threads working as consumer instantiated to listen a single message at a time than calling actor (but that would be as if it had no actor or parallelism via AKKA model).
I haven't worked with RabbitMQ per se, but I would probably designate one actor as a dispatcher, that would:
Handle RabbitMQ connection.
Receive messages (doesn't matter if one-by-one or in a batch for efficiency).
Distribute work between worker actors, either by creating a new worker for each message, or by sending messages to a pre-created pool of workers.
Receive confirmation from worker once task is completed and results are committed, and send acknowledgement back to RabbitMQ. Acknowledgment token may be included as a part of worker's task, so no need to track the mappings inside the dispatcher.
Some additional things to consider are:
Supervision strategy: who supervises the dispatcher? Who supervises the workers? What happens if they crash?
Message re-sends when running in a distributed environment.
Iam working on ActiveMQ application where iam using a consumer which uses Session.CLIENT_ACKNOWLEDGE.
Iam sending the messages received from queue in consumer to a webservice.Assume if i don do message.acknowledge() all the messages sent to webservice are back on the queue in enqueued state.
My question is how to retrieve the messages again from the queue and use it.I used retroactive=true and tried redelivery also but all of them are failing.
How to avoid this.
if you use message.acknowledge() all consumed messages are not available again in the same queueu because the are considered as delivered!
can you explain why you need to consume again the messages already consumed.
retroactive is for consumers who was offline and when starting connection to receive messages sent before the connection.
You need to setup the prefetch policy for the consumer to 400 in this case.
You can read to understand the concept http://activemq.apache.org/what-is-the-prefetch-limit-for.html
If you want to treat messages one by one with counter you need to set prefetch to 1 and acknowledge each message when you treat 200 you don't acknowledge.
We're using a Tibco client implementation of the JMS API. We have a MessageListener with an onMessage() implementation.
Is there a way with the Tibco client to inspect past (received) messages in the queue? (I realise this totally ignores the logical concept of a queue - I wondered if the queue implementation provided this workaround.)
No. Not for "past" messages.
Messages acknowledged by the receiver are removed from the queue - as their "function" is already done.
You could have a Listener configured to persist your messages in some DB or file - but for future messages.
A client uses a QueueBrowser object to look at messages on a queue without removing them.
#hawkeye Its not possible to browse messages from the past... At any point of time , you can browse destinations only for the pending messages.
There is no way for you browse all the received messages as EMS server usually deletes the message once it has delivered ( acknowledged) for the given delivery mode.
One possible way is to a send copy of the messages to another queue (without any receivers) before actually confirming the messages.
Also it depends on your acknowledgement mode and logic involved.