I am trying to test a single component of a system that publishes messages to a JMS topic. It seems to run fine for a few hours before the connection is automatically closed and I get the following message in the log file:
WARN [org.hornetq.core.client] (hornetq-failure-check-thread) HQ212037: Connection failure has been detected: HQ119014: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
Is this the correct behavior as there are no clients or should the topic continue to publish messages regardless of how many clients are connected?
Related
I would like to add some conditional logic to our Java application code for attempting to create a JMS Topic Connection. I have seen problems in the past stemming from attempting to create a connection when the MQ server had been restarted or was currently down. One improvement I added was to check for the quiescent state, and another was to increase the timer before attempting reconnection to our durable topic queue.
Is there a way to confirm with the MQ server/topic/channel that it is up and running and a connection request can safely be made?
The best way to confirm that a queue manager (and the channel you are using to connect to the queue manager) is up and running is to attempt to connect to it.
If your connection attempt fails, you will get an MQ Reason code telling you exactly why. This is a much better way to confirm than any administrative command, because it also confirms that your application, and it's security context is correct and able to connect to the queue manager. It is completely possible to have an up-and-running queue manager but an application that is not yet correctly configured to use it. So connect from the application and if it works, the queue manager is up-and-running.
Your comment about having an increased timer before attempting to reconnect after a failure is well made. It doesn't help anyone if you hammer the queue manager with lots of repeated and close together connection attempts until it is ready to accept your connection, but still anything that is going to test the availability of the queue manager needs to ultimately connect to it, so very simply, just connect.
I have started exploring MQ series and I noticed Sender channel in RETRYING status after SHORTRTR are exhausted. I have also noticed client applications couldn't connect to MQ when Sender channel was in RETRYING status.
Is my understanding correct that client applications can't connect to MQ if Sender channel is in RETRYING status?
What happens client start connection with MQ and Sender channel is not RUNNING?
Does Sender channel status matter when client is initializing MQ connection?
The ability for a client application to connect is almost entirely unrelated to the state of a sender channel. (I say almost because theoretically you could use up all the resources in your queue manager by having loads of retrying senders and then maybe they could affect clients).
When a client application makes a connection to a queue manager, the network connection is first caught by the listener, and then a running channel of type SVRCONN is started. This is a different type from a SENDER channel, and so there is no requirement to have a SENDER channel running for the client connection to be successful.
Sender channel status does not matter for the client to be able to connect.
Lets' try to diagnose your two problems. Look in the queue manager AMQERR01.LOG (found in the data directory under \Qmgrs\<qm-name>\errors) and edit your question to add the errors you see in there. There should be errors that explain why the sender channel is retrying, and some to explain why the client cannot connect.
It is possible that the problem with the client not being able to connect is because it is not even reaching the queue manager machine - in which case there will be nothing about that in the queue manager error log. In this case, you should also look in the AMQERR01.LOG on the client machine, this time in the data directory just under the errors folder (as no queue manager name there). You should also have seen some sort of error message or MQRC Reason code from the client application - you should tell us that too.
I have an application using jms that sends data to an ActiveMQ Artemis queue. I got an exception with this message:
The transaction was rolled back on failover however commit may have been successful
This exception is basically telling me that the message may or may not have reached the queue so I don't know if I need to send the message again. Whats the best way to handle an exception like this when:
I cannot send duplicate messages to applications on the other end of the queue.
and
I cannot skip a message.
I can't state it better than the ActiveMQ Artemis documentation:
When sending messages from a client to a server, or indeed from a server to another server, if the target server or connection fails sometime after sending the message, but before the sender receives a response that the send (or commit) was processed successfully then the sender cannot know for sure if the message was sent successfully to the address.
If the target server or connection failed after the send was received and processed but before the response was sent back then the message will have been sent to the address successfully, but if the target server or connection failed before the send was received and finished processing then it will not have been sent to the address successfully. From the senders point of view it's not possible to distinguish these two cases.
When the server recovers this leaves the client in a difficult situation. It knows the target server failed, but it does not know if the last message reached its destination ok. If it decides to resend the last message, then that could result in a duplicate message being sent to the address. If each message was an order or a trade then this could result in the order being fulfilled twice or the trade being double booked. This is clearly not a desirable situation.
Sending the message(s) in a transaction does not help out either. If the server or connection fails while the transaction commit is being processed it is also indeterminate whether the transaction was successfully committed or not!
To solve these issues Apache ActiveMQ Artemis provides automatic duplicate messages detection for messages sent to addresses.
See more details about how to configure and use duplicate detection in the ActiveMQ Artemis documentation.
We are developing a solution using TIBCO-EMS, and we have a question about its behaviour.
When using CLIENT_ACKNOWLEDGE mode to connect, the client acknowledges the received message. We'd like to know for how long does TIBCO wait for acknowledgement, and if this time is configurable by the system admin.
By default, the EMS server waits forever for the acknowledgement of the message.
As long as the session is still alive, the transaction will not be discarded and the server waits for an acknowledgement or rollback.
There is however a setting within the server disconnect_non_acking_consumers where the client will be disconnected, if there are more pending messages (not acknowledged) then the queue limit does allow to store (maxbytes, maxmsgs). In this case, the server sends a connection reset to get rid of the client.
Sadly the documentation doesn't state this explicitly and the only public record I found was a knowledge base entry: https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-33925
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).