I am experiencing MQ issue that if i start 1 application on 1MQ queue,it shows 1 listener on same queue but more than 1 session on MQ channel.Why sessions are created more than expected?We are using MQ connection through bindings file.
Below is the error:
There was an error when attempting to receive a message.com.ibm.mq.jms.SessionClosedException: MQJMS1024: session closed at com.ibm.mq.jms.MQSession.waitForStart(MQSession.java:2391) at com.ibm.mq.jms.MQMessageConsumer.receiveInternalQ(MQMessageConsumer.java:2388) at com.ibm.mq.jms.MQMessageConsumer.receiveQ(MQMessageConsumer.java:2235) at com.ibm.mq.jms.MQMessageConsumer.receive(MQMessageConsumer.java:4244) at com.tibco.plugin.share.jms.impl.JMSReceiver$SessionController.run(JMSReceiver.java:735)
You don't say what release of MQ you're using or the platform, which would be useful.
In general, for MQ V7+, the reason there is more than 1 session from the QCF is because WAS uses multiple sessions for management functions for the QCF itself. If you're using an XA resource, there are threads used for that also.
Related
I have a web application running on an App Service on Azure cloud.
On the back-end I'm using a tcp connection to our database (Neo4j graph db), the best practice is to open the tcp connection and keep it alive in order to be more reactive when we perform queries.
The issue I encountered is that the database is logging the exception "Connection reset by peer";
reading on the web I found out that maybe Azure has a TCP timeout configured by default, I read it to be set up to 4 minutes, which could be my issue root cause.
Someone knows how to configure the tcp KEEP ALIVE to always for App Services on Azure?
I found on the web how to do it in Google cloud but nothing about Azure cloud.
Thank you in advance.
OaicStef
From everything I can find that is not an adjustable setting. Here is the forum link that says it will not be changing and that is a couple years old at this point. https://social.msdn.microsoft.com/Forums/en-US/32b76114-67a4-4e6b-ac45-61b0f0a0829f/changing-the-4-minute-request-time-out-for-app-services?forum=windowsazurewebsitespreview
I think you are going to have to add logic to your app that tests the connection, if it has been closed then either reopen it or create a new one. I don't know what language you are using to make any suggestions there.
Edit
I will add that the total number of TCP connections that can be open on a single App Service is about 6k, at least on the S1. Keep that in mind because if you don't have pooling on the server side or you are not disposing of those then you will exhaust that the TCP pool and you will start getting errors. I recommend you configure an alert for that.
I don't understand the application of expiryTimeout field in Activemq PooledConnectionFactory. The java doc said "allow connections to expire, irrespective of load or idle time. This is useful with failover to force a reconnect from the pool, to reestablish load balancing or use of the master post recovery". please give me an example, a real scenario which expiryTimeout field effect in it.
The expiry timeout option is a bit of a legacy feature of the Pool that isn't all that useful in most applications these days. The way it works is that if you configure an expiration time then the Connection that is loaned out and is later closed will be completely closed and dropped should there be no other active users of the Connection, otherwise it stays alive until all active instances are closed, then the underlying Connection object is closed.
This works slightly differently than the Idle timeout which applies to Connection instances that are sitting unused in the pool and are closed after some length of time to release resources on the Broker side.
These days you are better off using a failover URI in the PooledConnectionFactory with broker support for rebalance of cluster clients enabled which would then dynamically redistribute the load in the broker cluster as opposed to the expiry timeout which only closes down Connection instances once everyone that is currently actively using them has released them by calling close on them.
I am using the Python Paho MQTT library and Mosquitto broker both with 3.1.1
If two clients connect with the same id (for whatever reason), both clients keep getting disconnected and then connect in a loop forever.
on_disconnect has a rc of 1 but connect has an rc of 0 (then it gets disconnected)
Is there anyway to detect that the issue is duplicated clientid?
Not yet. Hopefully this will be addressed in a future version of the spec.
I create a queue connection factory in Websphere using WebSphere MQ messaging provider.
Using JNDI to get this resource, and try to create queue connection in the same host.
The first time, everything works, but When I will to second time , it will throw a JMS Exception:
javax.jms.JMSException: Failed to create queue connection
at com.ibm.ejs.jms.JMSCMUtils.mapToJMSException(JMSCMUtils.java:141)
at com.ibm.ejs.jms.JMSQueueConnectionFactoryHandle.createQueueConnection(
JMSQueueConnectionFactoryHandle.java:90)
There is SO little information in the post it is hard to do anything but guess. First thing I'd look for is if the application or queue are set for exclusive use. Of course this assumes that you are opening the queue for input and that detail isn't mentioned in the question. Having the linked exception which would provide the actual WMQ reason and completion codes could tell you for sure but these also are not provided in the question.
Many shops consider it a Sev-1 defect if JMS code does not print linked exceptions. This is not a WMQ-specific thing but rather a case of printing out all the diagnostic information available regardless of the transport provider. In case you want more info on this, please see the WMQ Ifocenter JMS exception handling topic.
The Max Connection is there in WAS console. if connection getting more than Max connection and not release the resource (QueueConnection, QueueSender and QueueSession) than at the time of next connection it will fail to get the connection from connection pool. After restarting the Server only you can release the connection. this can be resolve by close all the resource(QueueConnection, QueueSender and QueueSession) properly in code.
I'll be developing stand-alone Java application being JMS client. I want to make sure that every time I send a message to a queue, I do not have to create session, connection etc.
I was thinking of using CachedConnectionFactory which comes with Apache Camel or using the solution Spring provides. Still, as far as I know the limitation of the former is that it is not suitable for transactions, and of the latter, that it may not behave correctly in case of failover.
On one post (http://stackoverflow.com/questions/8922339/how-to-pooling-the-jms-connection-in-a-standalone-java-applications) it was suggested to use Apache commons pool component, but I don't think creating such pool would be a trivial task anyway
Any comments on that?