You could start by doing code inspection and looking to see if there is any code path where you could fail to close a connection once you open it, which wouldn't require access to the customer environment.
Was there anything unusual in the logs around the time the errors were seen? Finally, your stack trace from several days ago shows that com.spacetimeinsight.alerts.util.MessagingUtils.sendMessage() calls org.apache.activemq.ActiveMQConnection.createSession(). Do you create a new AMQ session for every message you send? Is there any caching/pooling being done? If you're starting a new connection for each message, that seems like an easy way to run out of connections if there was a sudden flurry of messages all at once... (It's also less efficient than pooling, so you'd get worse throughput if that's what you're doing.) Tim On Thu, Sep 18, 2014 at 6:10 AM, venkatesh <venkatesh.sti...@gmail.com> wrote: > Hello, > > This is happening in customer end and not in our local system to debug > here. > This is happened only once and issue got resolved when customer restarted > their server. > > But my asking is, What information i can gather from customer and what > customer needs to check at his end if this situation raises again in > future. > > regards, > Venkatesh > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/what-is-the-Root-cause-and-how-to-resolve-the-error-i-e-javax-jms-JMSException-No-buffer-space-avail-tp4685440p4685691.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
