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 <acmmail...@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<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. >> >> >> >> > -- http://fusesource.com http://blog.garytully.com
