activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Too many open files (v5.4.2)
Date Thu, 24 May 2012 13:53:50 GMT
Sorry, my bad. You are correct. It is just the server side 'socket'
close that is async, not the tear down of broker state relating to a
connection, so there is no client impact.

asyncSync close really just means that there is a thread pool handling
close rather than the transport thread, so the transport thread can
get on with being reused if socket.close blocks for a bit.

On 24 May 2012 14:12, Arjen van der Meijden <> wrote:
> 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<>  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:
>>> Sent from the ActiveMQ - User mailing list archive at


View raw message