I am trying to send message to a JMS queue, however I get this error:
13:48:00,686 WARN [SimpleConnectionManager] A problem has been detected with the connection
to remote client 5c4o15e-ymtiah-hy5hsfkr-1-hy5hsg3i-4, jmsClientID=b-k8gsh5yh-1-rkfsh5yh-
haitmy-e51o4c5. It is possible the client has exited without closing its connection(s) or the
network has failed. All associated connection resources will be cleaned up.
One of the suggestions on the we o how to fix this was to change the periodicity of client pings to:
<attribute name="clientLeasePeriod" isParam="true">20000</attribute>
<attribute name="validatorPingPeriod" isParam="true">20000</attribute>
<attribute name="validatorPingTimeout" isParam="true">10000</attribute>
But it still didn't help.
Do you have any suggestions on how to fix this or what might cause the connection failure to a client?
Ensure that you have closed the TopicSession and TopicConnection object in your producer, or in your case QueueConnection and QueueSession objects.
Related
The following code is trying to send a message on a queue using JMS.
connection = jmsConnectionFactory.createConnection();
connection.start();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Destination destination = session.createQueue(queueName);
MessageProducer producer = session.createProducer(destination);
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
It works most of the time but while running a stress tests where many messages were sent in parallel, I found once the exception below:
Caused by: javax.jms.IllegalStateException: The producer is closed
at org.apache.activemq.ActiveMQMessageProducer.checkClosed(ActiveMQMessageProducer.java:195)
at org.apache.activemq.ActiveMQMessageProducerSupport.setDeliveryMode(ActiveMQMessageProducerSupport.java:136)
The exception is thrown in the setDeliveryMode().
I have seen other posts about the same issue, but in my case I am not using shared sessions, nor shared connections.
I am running ActiveMQ 5.14.5.
Looking at the code for org.apache.activemq.ActiveMQMessageProducer the closed variable (which is checked by the checkClosed() method at the top of the stack-trace) is initialized as false so something else has to be setting it to true for this exception to be thrown. From what I can see it is only set to true when the producer itself, the originating session, or originating connection is closed. It's possible that the connection and/or session is being closed in the background due to some other failure and this exception with the producer is the first visible symptom of that problem.
In any case, without at least some additional details about your code or ideally a minimal, reproducible example it's not really possible to draw a reliable conclusion.
I'm using rabbitMQ Golang client for pub and sub message between two servers, but I often get bug: "client unexpectedly closed TCP connection". My rabbitMQ client is running normaly, but after distance of time it stop.
Who can help me how check catch this error and reconnect / fix this error.
Thanks so much
Try with increased connection timeout
Check your firewall configuration
The channel adapter is for one way communication.
But while using TcpSendingMessageHandler, the adapter is expecting a reply. and the following message is thrown same is the case with TcpOutboundGateway.
TcpNetConnection : Read Exception [Connection ID] Socket Exception : software caused connection abort: recv failed
Please help me to overcome this issue.
The sending adapter is not expecting a reply; it is possible, however, that the application has collaborating channel adapters (a receiving adapter that uses the same connection).
Even if there is no listener, we have to read from the socket so we can log that an unexpected reply was received. If we don't read from the socket, the peer could end up blocking when the buffers fill up.
What problem is this causing you?
This is typically only logged at DEBUG or TRACE level.
I do use failover transport feature by using the following pattern in the broker URL
failover:(tcp://host:port)
Init code goes as follow:
factory = new PooledConnectionFactory(BROKER_URL);
connection = factory.createConnection();
connection.start();
the put message code looks more or less like this:
session = connection.createSession( false, Session.AUTO_ACKNOWLEDGE );
Destination destQueue = new ActiveMQQueue(queue);
MessageProducer producer = session.createProducer(destQueue);
TextMessage msg = session.createTextMessage(message);
producer.send(msg);
When a failover occurs -
[org.apache.activemq.transport.failover.FailoverTransport] Transport (broker) failed, reason: , attempting to automatically reconnect: java.net.SocketException: recv failed: Connection aborted by peer
and got reconnected after
[org.apache.activemq.transport.failover.FailoverTransport] Failed to connect to [broker] after: 10 attempt(s) continuing to retry.
08:55:29,596 INFO [org.apache.activemq.transport.failover.FailoverTransport] Successfully reconnected to broker
do I have to reinitiate a connection? Or to be more specific, do I have to do anything with the connection object to be able to produce/consume message after the failover?
thanks
The whole point of the failover transport is to handle the reconnection for you. The logs you've shown indicate a successful reconnect cycle where the transport has continued to retry to connect to a broker and eventually did so.
We are trying to write a message to a broker queue. But the whole request fails when it tries to commit the JMS transaction & then it tries to rollback each subsequent time. We use oracle XA drivers. Not sure where to post this issue: MQ forums or Oracle forum. So thought would give a try here. Can someone help resolve this please.
Error:
[9/25/12 17:10:06:871 EDT] 0000003e XATransaction E J2CA0027E: An exception occurred while invoking commit on an XA Resource Adapter from dataSource JMS$QCF$JMSManagedConnection#23, within transaction ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54), data(00000139ff43ef2500000001000043106c82332ef6bc723402e84f341fb357080ddd4d1b00000139ff43ef2500000001000043106c82332ef6bc723402e84f341fb357080ddd4d1b000000010000000000000000000000000001)}: javax.transaction.xa.XAException: The method 'xa_commit' has failed with errorCode '-7'.
at com.ibm.mq.jmqi.JmqiXAResource.commit(JmqiXAResource.java:407)
at com.ibm.ejs.jms.JMSManagedSession$JMSXAResource.commit(JMSManagedSession.java:1702)
at com.ibm.ejs.j2c.XATransactionWrapper.commit(XATransactionWrapper.java:463)
at com.ibm.ws.Transaction.JTA.JTAXAResourceImpl.commit_one_phase(JTAXAResourceImpl.java:305)
at com.ibm.ws.Transaction.JTA.RegisteredResources.flowCommitOnePhase(RegisteredResources.java:2916)
at com.ibm.ws.Transaction.JTA.TransactionImpl.commitXAResources(TransactionImpl.java:2533)
at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:1687)
at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1647)
at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1582)
at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:247)
at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:168)
at com.ibm.ws.Transaction.JTA.UserTransactionImpl.commit(UserTransactionImpl.java:293)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1009)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:255)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1002)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:901)
at org.springframework.scheduling.commonj.DelegatingWork.run(DelegatingWork.java:61)
at com.ibm.ws.asynchbeans.J2EEContext$RunProxy.run(J2EEContext.java:264)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.ws.asynchbeans.J2EEContext.run(J2EEContext.java:1137)
at com.ibm.ws.asynchbeans.WorkWithExecutionContextImpl.go(WorkWithExecutionContextImpl.java:195)
at com.ibm.ws.asynchbeans.CJWorkItemImpl.run(CJWorkItemImpl.java:187)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1560)
.
[9/25/12 17:10:06:880 EDT] 0000003e RegisteredRes W WTRN0052E: An attempt by the transaction manager to call one phase commit on a transactional resource has resulted in an XAER_RMFAIL error. The resource was com.ibm.ws.Transaction.JTA.JTAXAResourceImpl#1d07bf1#{XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54), data(00000139ff43ef2500000001000043106c82332ef6bc723402e84f341fb357080ddd4d1b00000139ff43ef2500000001000043106c82332ef6bc723402e84f341fb357080ddd4d1b000000010000000000000000000000000001)}
[9/25/12 17:10:06:887 EDT] 0000003e DefaultMessag W org.springframework.jms.listener.DefaultMessageListenerContainer handleListenerSetupFailure Setup of JMS message listener invoker failed for destination 'queue:///RANDOM QUEUE?targetClient=1' - trying to recover. Cause: Heuristic completion: outcome state is mixed; nested exception is javax.transaction.HeuristicMixedException
Here's the cause and resolution
Quote-
The cause of these errors is usually the result of a WebSphere MQ
messaging provider JMS Connection being closed off by WebSphere
Application Server because the Aged timeout for the Connection has
expired.
Resolution-
To resolve this issue, ensure that the JMS Connection Factory being
used by the application has the Connection Pool property Aged timeout
set to zero. This will prevent JMS Connections being closed when they
are returned to the Free Pool, and so ensures that any outstanding
transactional work can be completed
It is sometimes also caused by the faulty DataDirect Driver and is reported and fixed by IBM, see this.
Earlier we had multiple JMS sessions. That was probably the cause of the issue in one of the environments. So we had to change to 2 diff. sessions & now it works!
Julian:
My scenario is slightly different from yours. Earlier we had:
A request message was put on the queue. This queue was picked up & processed. Then we saved to the DB & then generated another message & put it on another broker queue & then sent a response to the first message. All this was 1 flow.
Now we changed that to 2 diff. flows : Request --> Process --> Save to DB --> Reply
and then another flow to put on Broker queue.
Hope this helps