I think the specific bits I'm remembering were in 0.14, but I'm just on my phone so I can't really check just now.
Robbie On Jun 8, 2012 6:58 PM, "Fraser Adams" <[email protected]> wrote: > Hi Robbie, > this is with qpid 0.12 for both c++ broker and Java client runtime. > > To be fair this problem seems to be mostly occurring in a client I'm > writing that is periodically doing a QMF getObjects() which under the hood > is doing a JMS request/response pattern. I've got other clients that are > primarily doing JMS MessageListener stuff and they seem to be mostly OK, > though I have have had them throw the occasional: > > Exception in thread "Thread-4" java.lang.NullPointerException > at org.apache.qpid.client.**AMQSession_0_10.isQueueExist(** > AMQSession_0_10.java:1119) > at org.apache.qpid.client.**AMQSession_0_10.** > handleAddressBasedDestination(**AMQSession_0_10.java:1234) > at org.apache.qpid.client.**AMQSession.registerConsumer(** > AMQSession.java:2841) > at org.apache.qpid.client.**AMQSession.access$500(** > AMQSession.java:120) > at org.apache.qpid.client.**AMQSession$4.execute(** > AMQSession.java:2034) > at org.apache.qpid.client.**AMQSession$4.execute(** > AMQSession.java:2000) > at org.apache.qpid.client.**AMQConnectionDelegate_0_10.** > executeRetrySupport(**AMQConnectionDelegate_0_10.**java:314) > at org.apache.qpid.client.**AMQConnection.**executeRetrySupport(** > AMQConnection.java:614) > at org.apache.qpid.client.**failover.FailoverRetrySupport.** > execute(FailoverRetrySupport.**java:102) > at org.apache.qpid.client.**AMQSession.createConsumerImpl(** > AMQSession.java:1998) > at org.apache.qpid.client.**AMQSession.createConsumer(** > AMQSession.java:971) > > which is pretty evil :-( > > I think that for this particular application I might resort to a good old > fashioned ExceptionListener set on the Connection and roll my own > reconnection logic. > > Which version do you reckon this sort of thing is fixed in? > > You seem to have been a busy beaver wrt. the Java client runtime over the > last couple of releases (ISTR that you've sorted out the Message Selector > issues too?) I'll give 0.16 a whirl sometime, but unfortunately I'm going > to have to support from version 0.8 upwards so I probably shouldn't rely on > recent fixes unless there are show-stoppers. > > Cheers, > Frase > > > On 08/06/12 18:38, Robbie Gemmell wrote: > >> What client version? Older releases of the client were a bit racey in >> terms >> of doing things *while* reconnecting (when using the 0-10 protocol) that >> could allow stuff to happen that caused output along those lines. >> On Jun 8, 2012 12:49 PM, "Fraser >> Adams"<fraser.adams@**blueyonder.co.uk<[email protected]> >> > >> wrote: >> >> Hi all, >>> I've not had any response to this but I've dug a little further and I'm >>> pretty sure that there's actually a bug floating around - possibly in the >>> JMS client runtime in the Connection classes relating to automatic >>> reconnection/failover. >>> >>> As I say below I'm seeing broker errors "error Execution exception: >>> not-found: Unknown destination ...." where I get different numbers >>> reported >>> (possibly subscription names though I'm not completely sure) however I >>> think the broker error is actually a symptom not the problem. >>> >>> I have a JMS connection to the (qpid 0.12 c++) broker, which is >>> supposedly >>> set up for automatic reconnection using&retries='2147483647 >>> '&connectdelay='**5000' which *should* attempt reconnection every five >>> seconds more or less forever. >>> >>> The reconnection does generally seem to work and I've got a JMS based >>> QMF2 >>> console connected, however in one of my tests I've been starting and >>> stopping the broker in pretty rapid succession and I've been periodically >>> hitting the above problem. >>> >>> Digging further I've noticed JMS exceptions being thrown in my >>> application: >>> >>> JMSException caught in getObjects() Message consumer forcibly closed due >>> to error: org.apache.qpid.AMQException: ch=6 id=0 >>> ExecutionException(errorCode=****NOT_FOUND, commandId=45, classCode=4, >>> commandCode=10, fieldIndex=0, description=not-found: Unknown destination >>> 3 >>> (qpid/broker/SemanticState.****cpp:563), errorInfo={}) [error code 404: >>> not >>> found] >>> >>> <in a later call> >>> >>> JMSException caught in getObjects() Object org.apache.qpid.client.** >>> BasicMessageProducer_0_10@****58b51c29 has been closed >>> >>> <in a later call> >>> >>> JMSException caught in getObjects() Session has been closed >>> >>> >>> In another run I had: >>> >>> Exception in thread "IoReceiver - localhost/127.0.0.1:5672" >>> java.lang.NullPointerException >>> at org.apache.qpid.client.****AMQConnectionDelegate_0_10.** >>> closed(AMQConnectionDelegate_****0_10.java:285) >>> at org.apache.qpid.transport.****Connection.closed(Connection.*** >>> *java:568) >>> at org.apache.qpid.transport.****network.Assembler.closed(** >>> Assembler.java:110) >>> at org.apache.qpid.transport.****network.InputHandler.closed(** >>> InputHandler.java:202) >>> at org.apache.qpid.transport.****network.io.IoReceiver.run(** >>> IoReceiver.java:150) >>> at java.lang.Thread.run(Thread.****java:679) >>> Sleep 5 >>> >>> <in a later call> >>> >>> JMSException caught in getObjects() Object org.apache.qpid.client.** >>> AMQSession_0_10@19e09a4 has been closed >>> >>> <in a later call> >>> >>> JMSException caught in getObjects() Object org.apache.qpid.client.** >>> BasicMessageProducer_0_10@****79014e21 has been closed >>> >>> <in a later call> >>> >>> JMSException caught in getObjects() Session has been closed >>> >>> >>> >>> So this is suggesting to me that there's a bug somewhere in the JMS auto >>> reconnection logic that is failing to properly recreate the state. >>> >>> >>> Has anyone else encountered this? So is this a bug or am I doing >>> something >>> wrong? >>> >>> Cheers, >>> Frase >>> >>> >>> On 01/06/12 16:59, Fraser Adams wrote: >>> >>> Hi all, >>>> I'm running qpid c++ broker 0.12 and I've started seeing: >>>> >>>> error Execution exception: not-found: Unknown destination 9 >>>> (qpid/broker/SemanticState.****cpp:563) >>>> >>>> To be honest I've usually got the broker running fairly constantly but >>>> of >>>> late I've been doing testing that has needed a lot of stopping and >>>> starting >>>> and I've noticed the above error occasionally when doing a basic qpidd >>>> --auth no >>>> >>>> Any idea what's causing this? I've got nothing persisted, so seems kind >>>> of odd. >>>> >>>> Cheers, >>>> Frase >>>> >>>> >>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: [email protected].****org< >>> users-unsubscribe@qpid.**apache.org <[email protected]>> >>> For additional commands, e-mail: [email protected] >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
