I also tried my test with the 0.10 release, but couldn't reproduce this issue. Perhaps I'm missing a crucial point. My example is more or less the same you pasted on the email, but it seems the client reconnects without an issue.
Are you able to email me ([email protected]) the standalone reproducer you used? Regards, Rajith On Tue, Jul 3, 2012 at 7:10 PM, Rajith Attapattu <[email protected]> wrote: > I tested with trunk and is unable to reproduce this issue. > Richard could you please confirm if you are still seeing this issue with > trunk? > (The code on trunk is what we would be releasing as 0.18) > > Rajith > > On Tue, Jul 3, 2012 at 2:59 PM, Fraser Adams > <[email protected]> wrote: >> Hi Richard/Rajith >> I don't know if this is related to what you are seeing, but I posted a few >> weeks ago in a post entitled >> >> "error Execution exception: not-found: Unknown destination 9 >> (qpid/broker/SemanticState.cpp:563)" >> >> 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) >> >> >> 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 >> >> 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. >> >> >> In response to that Robbie Gemmell posted >> >> " >> >> 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. >> >> " >> But mentioned that he thought that things had improved in qpid 0.14. >> >> Robbie might be able to shed some light on what you are seeing Richard, but >> you might want to try the 0.14 Java client runtime instead of the 0.10 one >> to see if that helps things. >> >> >> FWIW I ended up rolling my own reconnection via a JMS Connection >> ExceptionListener but as it turns out that approach is the most useful in my >> case anyway as I want to inform the user of a problem as well as instigate a >> reconnection. >> >> Cheers, >> Frase >> >> >> >> >> On 03/07/12 13:32, Rajith Attapattu wrote: >>> >>> Richard, >>> >>> I will have a look at this issue and get back to you. >>> If this bug still exists on trunk, we will fix this for the upcoming 0.18 >>> release. >>> >>> Regards, >>> >>> Rajith >>> >>> On Tue, Jul 3, 2012 at 7:04 AM, Fallon, Richard <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> Hello All, >>> >>> I have a problem when using the java client libraries (0.10). I >>> am connecting to a Qpid broker version 0.8. The problem I have is >>> easy to re-create and has significant impact upon message loss for >>> consuming applications. >>> >>> The problem can be summarised like so:- >>> >>> 1) Start a Qpid Broker >>> 2) Start a Java consumer >>> 3) Send a message to the broker that the consumer will pick-up >>> 4) Stop the Qpid Broker whilst the consumer is processing the >>> message >>> 5) The java consumer will NEVER reconnect >>> >>> >>> Contrast this to >>> 1) Start a Qpid Broker >>> 2) Start a Java consumer >>> 3) Stop the Qpid Broker >>> 4) The java consumer will always reconnect >>> >>> Or indeed contrast this to >>> 1) Start a Qpid Broker >>> 2) Start a Java consumer >>> 3) Send a message to the broker that the consumer will pick-up >>> 4) Stop the Qpid Broker AFTER the message has been processed >>> 5) The java consumer will always reconnect >>> >>> Obviously the impact of this is significant. We have clients who >>> are subscribing to messages and in the event of a Qpid broker >>> outage (if they are processing a message at the time of the >>> outage) they will never reconnect again –without restarting their >>> systems. Whereas other clients may reconnect perfectly well (so >>> long as they were not processing a message at the time of the >>> outage). The net result is message loss as messages are delivered >>> to the exchange whilst the end systems are not subscribing. >>> >>> I have recreated this in a number of environments, I first saw it >>> using Apache Camel, but have since recreated it with a simple >>> POJO. Unfortunately my code is on another network so I have not >>> attached the source for the moment. However detailed below is >>> some pseudo-code which should be easy to recreate. (I initially >>> saw this using Apache Camel –but have removed all Camel references >>> to focus on the issue). >>> >>> //Simple consumer class >>> class MyConsumer >>> { >>> public static void main(String[] args){ >>> >>> while(true) >>> { >>> try >>> { >>> //standard connection stuff >>> connect(); >>> //every time a message is received pause processing >>> receiveMessage(); >>> }//end try >>> catch(Throwable e) >>> { >>> logException(); >>> }//end catch >>> }//end while >>> }//end main >>> >>> public static void receiveMessage(){ >>> >>> while(true) >>> { >>> Message message = messageConsumer.receive(TIMEOUT); >>> >>> if(message!=null{ >>> >>> //got message >>> Thread.sleep(10000); >>> >>> }//end if >>> }//end while >>> }//end receive >>> >>> }//end class >>> >>> >>> The problem appears to be in the invoke method of >>> org.apache.qpid.transport.Session. After a MessageAccept method >>> has been received the application state is such that a sync is >>> never required and the client code never attempts to access the >>> broker again. No exception is thrown up the stack so the client >>> code can’t do anything about it. It just loops round internally >>> forever. >>> >>> I have added some code to force the issue in the invoke() method >>> of org.apache.qpid.transport.Session which comes after the >>> existing code >>> >>> if(m.getEncodedTrack() == Frame.L4){ >>> } >>> >>> //here’s my code >>> >>> if ( state ==DETACHED && !needSync ) >>> { >>> throw new SessionException(“This exception allows clients to know >>> there has been a problem”); >>> } >>> >>> My concern with my “fix” is that I obviously do not understand the >>> full lifecycle methods and different states that the session >>> instance may be in. >>> >>> Could you advise if >>> a) You are aware of this and whether it has been fixed in a >>> later version >>> b) Whether my proposed “fix” will have other adverse side >>> affects? >>> c) Should I send this to a different forum? >>> >>> >>> >>> Thanks for your help >>> >>> >>> Richard >>> >>> >>> >>> Picture (Metafile) >>> *Richard Fallon* >>> Architect >>> 01928 594109 >>> M:+447733312563 <tel:%2B447733312563> >>> E:[email protected]_ <mailto:[email protected]> >>> Atos.net >>> Picture (Metafile) >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Atos and Atos Consulting are trading names used by the Atos group. >>> The following trading entities are registered in England and >>> Wales: Atos IT Services UK Limited (registered number 01245534), >>> Atos Consulting Limited (registered number 04312380) and Atos IT >>> Solutions and Services Limited (registered number 01203466) The >>> registered office for each is at 4 Triton Square, Regents Place, >>> London, NW1 3HG.The VAT No. for each is: GB232327983 >>> >>> This e-mail and the documents attached are confidential and >>> intended solely for the addressee, and may contain confidential or >>> privileged information. If you receive this e-mail in error, you >>> are not authorised to copy, disclose, use or retain it. Please >>> notify the sender immediately and delete this email from your >>> systems. As emails may be intercepted, amended or lost, they are >>> not secure. Atos therefore can accept no liability for any errors >>> or their content. Although Atos endeavours to maintain a >>> virus-free network, we do not warrant that this transmission is >>> virus-free and can accept no liability for any damages resulting >>> from any virus transmitted. The risks are deemed to be accepted by >>> everyone who communicates with Atos by email. >>> >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
