Is there a way to set timeout for sending a message to broker.
I want to send large messages to ActiveMQ broker but I do not want it to take forever, so I was planning to set a timeout while sending message.
you can set connection.sendTimeout=some ms in URI while connecting to broker
Official document for sendTimeout says
Time to wait on Message Sends for a Response, default value of zero
indicates to wait forever. Waiting forever allows the broker to have
flow control over messages coming from this client if it is a fast
producer or there is no consumer such that the broker would run out
of memory if it did not slow down the producer. Does not affect Stomp
clients as the sends are ack'd by the broker. (Since ActiveMQ-CPP
2.2.1)
here is the documentation https://activemq.apache.org/components/cms/configuring
hope this helps!
Good luck!
Related
I have a producer send msg to a ActiveMQ broker, and a consumer subscribe from the same topic. I know that the broker can persist the msg, so as soon as the msg reaches the broker, it can be guaranteed available for the consumer. (right?)
But what happen if the network between producer and ActiveMQ broker is broken, in this case is there a way to guarantee the at-least-once sent? like, the producer itself can persist msg before sending to the ActiveMQ broker?
In order for the guarantee to be established the message must reach the broker, if the network is down then the burden is on you to capture the send error and retry the send at a later time. The ActiveMQ client offers no persistent storage for what it sends, you can use the failover transport and the client will retry the send on reconnect but it the application is shutdown and you haven't provided some means of recovery on restart then there isn't anything more the client can do.
We are getting the below error when we are posting a message to rabbitmq from a spring boot service. Also this is intermittent and we are not able to reproduce this.
[AMQP Connection 123.11.xxx.xx:5672] ERROR [] org.springframework.amqp.rabbit.connection.CachingConnectionFactory - Channel shutdown: channel error; protocol method: #method(reply-code=406, reply-text=PRECONDITION_FAILED - fast reply consumer does not exist, class-id=60, method-id=40)
Does anyone faced similar issue with rabbitmq .
Please help us with your inputs.
For anyone else that ended up here due to this error, in my case the issue was resolved when I ensured both of the following:
the publisher ("client") used the same channel for both publishing (to whatever normal queue you publish to) and for consuming from the RabbitMQ amq.rabbitmq.reply-to queue
the consumer ("server") used the same channel for both consuming (from whatever normal queue you published to above) and for publishing to the specified RabbitMQ reply-to queue
Unfortunately, I don't see this documented anywhere.
I had the exact same problem with direct reply mode and what I had to do was to:
Ensure that the consumer for the replies (not the requests) was running BEFORE publishing the request message.
Also, as the docs say:
The RPC client must consume in the automatic acknowledgement mode. This is because there is no queue for the reply message to
be returned to if the client disconnects or rejects the reply
message.
I also used the same model/channel for the publisher and consumer, as user joniba said, but I am not sure if that has helped indeed.
It most likely means the requestor has timed out and canceled the consumer on the direct replyTo queue. Or, the requesting application has been stopped.
If the requestor is also a Spring AMQP application, the default replyTimeout is 5000ms (5 seconds). If the server side takes longer than that, the requestor will timeout and you'll get this error on the server.
You can increase the replyTimeout property on the requesting RabbitTemplate.
EDIT
Spring AMQP 2.0.x (requires Spring Framework 5.x) uses longer-lived direct replyTo consumers so you shouldn't get these messages (but the client will still time out and you'll get a warning log on the client side and a log when the late delivery arrives).
I read following quote from ActiveMQ documentation here:
The downside to using synchronous message delivery is that the
producer is more likely to block if there is a slow consumer that he
is dispatching messages to.
But I don't understand how the producers, in general, can be blocked because of slow consumer, because my understanding is that a JMS client (producer) will send a message to a queue of a ActiveMQ instance (broker) and that's it, now producer is free or in other words producer thread which sent the message is free to complete/die. Then there will be some other JMS clients (consumers) listening for that queue, now as soon as message arrives to the broker, broker will send it to the listening consumers.
Now, in all this where producer is dependent upon consumer?
When a producer send a persistent message to the broker the broker must write that message to disk before sending back an acknowledge to the producer to let it know what it's message is safely stored away for later dispatch to a consumer. In the case of a slow consumer the producer might eventually run into a case where the broker has reached a resource limit and cannot store that message either on the Queue in memory or on disk, it all depends on the broker's configuration.
The the producer isn't so much tied to the consumer as it is to the resources on the broker needed to hold the message until it has been consumed.
I am using MQ 7.5.0.2 and Datapower client IDG7
When MQ send messages to Datapower, Datapower receive those messages using MQ front side handlers and also same way it do send messages using Backend URL
But the problem I am facing it when ever Datapower connects to MQ, Queue Input/Output count increases to (10 ~20) and remains same and the Handle state is INACTIVE.
When I see queue details using below commands it is displaying as below
display qstatus(******) type(handle)
QUEUE(********) TYPE(HANDLE)
APPLDESC(WebSphere MQ Channel)
APPLTAG(WebSphere Datapower MQClient)
APPLTYPE(SYSTEM) BROWSE(NO)
CHANNEL(*****) CONNAME(******)
ASTATE(NONE) HSTATE(INACTIVE)
INPUT(SHARED) INQUIRE(NO)
OUTPUT(NO) PID(25391)
QMURID(0.1149) SET(NO)
TID(54)
URID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
URTYPE(QMGR)
Can any one help me in this.It only clearing when ever i restart the queue manager but I dont want to restart the qmgr every time.
HSTATE in INACTIVE state indicates "No API call from a connection is currently in progress for this object. For a queue, this condition can arise when no MQGET WAIT call is in progress.". This is likely to happen if the application(DP in this case) opened the queue and then not issuing any API calls on the opened object. Pid 25391 - is this for an amqrmppa process? Is DP expected to consume messages on this queue continuously?
I'm dealing with a standalone MQ JMS application, our app need to "aware" that client already consumed the message producer put on the queue. Because client app is not responsible by us. So we cannot let them to write something like "msg.acknowledge();" thing on their side (msg.acknowledge() is not the right approach on my condition.). I search the history answer in the stackoverflow. Find following is quite the same what I want:
https://stackoverflow.com/questions/6521117/how-to-guarantee-delivery-of-the-message-in-jms
Do the JMS spec or the various implementations support delivery confirmation of messages?
My question is, is there any other way to archive this in the MQ API or JMS API? I need to do the coding only on the msg produce side, it is can be queue or topic.
Another question is in the JMS the acknowledge mode CLIENT_ACKNOWLEDGE, is that produce irrelevant? I always believe that this mode can block the application when call send() method until the client consume the message and call the msg.acknowledge(), but seems not like that. The produce just exit the app after message be delivered, and the message just store in the queue until client call the acknowledge(). Is that possible let the producer app hang there wait until the message be acknowledged by the client?
If my concept is not right, just correct me, thanks.
The main intention of message queuing is to decouple producer and consumer. Producer does not need to wait for the message to be consumed by the consumer, it can continue it's job. Ideally if producer needs to know if the message has been processed by consumer or not, it should wait for consumer to send a response message on another queue.
Message acknowledgement has nothing to do with producer. Message acknowledgement is the way a consumer tells the messaging provider to remove the message from a queue after the message has been delivered to an application.
There is auto acknowledge where the JMS providers (like MQ JMS), after delivering message to an application, tell the messaging provider to remove the message from queue. Then there is client acknowledge where, after receiving a message, the application explicitly tells the messaging provider to remove message from a queue.
Is there is a reason why the producer has to wait for consumer to receive the message? One way, though not elegant, could be: Once the message is sent, use the message id of the sent message and try to browse for that message. If message is not found, you can assume it has been consumed