activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: java.io.IOException: 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 <acmmailing@tweakers.net> 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<johnboyer99@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.
>>
>>
>>
>>
>



-- 
http://fusesource.com
http://blog.garytully.com

Mime
View raw message