On 29 May 2018 at 21:00, Gordon Sim <g...@redhat.com> wrote: > On 29/05/18 20:24, Rob Godfrey wrote: >> >> On Tue, 29 May 2018 at 19:45, akabhishek1 >> <mailbox.abhishek.ku...@gmail.com> >> wrote: >> >>> HI Robbie, >>> >>> Thanks a lot for details. I am able to reproduce this issue with your >>> finding, i am facing same idle timeOut issue for every 10m. >>> >>> As MessageProducer have no internal operation which will tell us that >>> MessageProducer is active or not. DO we have any library or facility >>> available which will refresh MessageProducer in every 10m for idle >>> scenario? >>> >> >> Since the "idling" after 10 minutes is a ServiceBus specific "feature" >> then >> I would not expect any client library (except perhaps for those written by >> Microsoft) to handle this scenario. > > > The problem with the JMS API specifically though, is that there is no way to > be notified that a producer has been closed or even to test whether it has > been closed... >
There is no explicit way, but methods on the producer throw a JMS ISE if used when it is closed, there are plenty of getters. >>> If not available then we have to write some custom logic to handle this >>> scenario. >>> >> >> Yes - I think the best option here is for you to write your own custom >> logic here. You could, for instance, write a wrapper around >> MessageProducer that keeps track of the last time a message was sent and >> if >> that time was > 10 minutes ago could close the wrapped MessageProducer and >> create a new one. > > > Does the send() method throw a recognisable error if the underlying producer > link has been detached? > > Your solution sounds like a good one for the case in question. More > generally though, JMS users would probably need a way to handle links closed > for less predictable reasons. > The client has an notification system for use in its tests, which can be used to listen for such events as they occur. Using it would tie application code to the client impl, entirely at odds with using the vendor neutral JMS API, and the listener implementation is also subject to change, so for both those reasons I wouldnt really recommend an application using it. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
