Are you sure the client even notices this?
From our experience, I'm fairly certain that only the server side of
the connections where still open when we ran into this IOException.
I.e. isn't the correctly and completely closed (in Stomp-communication
terms from the client perspective) connection put into a queue to later
completely remove all connection information, close the server side of
the socket, etc?
Actually, if there would be a last communication towards the client, I'd
expect the non-asynchronous method of closing to be quicker per single
client rather than adding a delay. Especially under load. Queueing for
asynchronous processing normally suggests some form of unknown and
highly variable latency.
I can see two advantages of asynchronous closing. Firstly, it'll reduce
time a thread spends on a single connection by pushing part of that work
into a backend processing thread. Which in the end should result in a
reduced amount of threads being active at any time.
And secondly it can group several close/cleanup-operations in one go and
thus reduce the overhead per cleanup.
But reduced delay for the close-confirmation towards a client wouldn't
be anything I'd expect from a asynchronous background operation.
So while synchronous closing may increase the load for the broker by
pushing this work into the communication threads and increasing the
relative overhead for each cleanup/close. It shouldn't really be a
disadvantage to the client side. Or am I missing a step?
Best regards,
Arjen
On 24-5-2012 12:01 Gary Tully wrote:
yes, closeAsync=false can help reduce the number of open sockets if
the broker is busy at the cost of delaying the close response to the
client, but you need to really ask your computer that question; in
other words, do an empirical test.
On 23 May 2012 21:57, johneboyer<johnboye...@gmail.com> wrote:
Thank you Gary very much for your suggestions!
Incidentally, we do have a lot of short lived STOMP producers. Should we
also set /transport.closeAsync=false/ as suggested by Arjen earlier?
Regards,
John Boyer
--
View this message in context:
http://activemq.2283324.n4.nabble.com/java-io-IOException-Too-many-open-files-v5-4-2-tp4643701p4652133.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
