If you have short lived connections: Try adding
'?transport.closeAsync=false' to your connection construct, i.e.
something like this:
<transportConnector name="stomp"
uri="stomp://0.0.0.0:61613?transport.closeAsync=false" />
We have many very short lived stomp producers and due to the
asynchronous disconnect code, it would take a while before the
connections where actually cleaned up on the server side. And that would
leave the 'files' (tcp sockets) open longer than necessary, thus causing
us hitting the ulimit.
You probably still need the 10240 limit, but with that parameter, you
should be save with short lived connections like in our scenario.
If you just have long lived connections, that's obviously not going to
help. In that case you just need to keep increasing the setting (or
adding ActiveMQ instances in a network).
And then your question remains.
Best regard,
Arjen
On 18-5-2012 19:20 johneboyer wrote:
Yes. After further research yesterday, we did
http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ increase
the number of files parameter to *10240*. We have hundreds of open STOMP
connections and expect this number to continue to grow in the coming months.
/So, I guess the question we have now is how to optimize this setting in
future/. I realize this question is out-of-scope for this forum, but it
would be nice if the ActiveMQ team could provide some best practices in this
area when a broker has hundreds or even thousands of open connections.
Thanks,
John Boyer
--
View this message in context:
http://activemq.2283324.n4.nabble.com/java-io-IOException-Too-many-open-files-v5-4-2-tp4643701p4644813.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
