You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Fallon, Richard" <ri...@atos.net> on 2012/07/03 13:04:27 UTC
Java Reconnection failure when processing a Message
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
E:richard.fallon@atos.net
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.
_______________________________________________________
Re: Java Reconnection failure when processing a Message
Posted by rfallon <ri...@atosorigin.com>.
Rajith,
Thanks for the prompt response. I look forward to your feedback.
Richard
--
View this message in context: http://qpid.2158936.n2.nabble.com/Java-Reconnection-failure-when-processing-a-Message-tp7579188p7579195.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Reconnection failure when processing a Message
Posted by Rajith Attapattu <ra...@gmail.com>.
Based on your description, it seems my test is the same.
Anyways I'm happy that you have verified that it works with 0.16 release.
Thanks for confirming.
Regards,
Rajith
On Fri, Jul 6, 2012 at 8:25 AM, Fallon, Richard <ri...@atos.net> wrote:
>
> Hi Rajith,
>
> I retried with the 0.14 libraries and that failed with exactly the same problem. However I retried with 0.16 and that reconnects perfectly well. Which is great news for us.
>
> I don't have the source code available to me here, I could copy it out by hand if you really want it - but essentially all I am doing is stopping the broker at the point in time that my consumer receives a messge (using a MessageConsumer), and sleeps for 10s.
>
> I've rolled 0.16 into our applications and they are all reconnecting successfully.
>
> Richard
>
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> Sent: 04 July 2012 16:34
> To: users@qpid.apache.org
> Subject: Re: Java Reconnection failure when processing a Message
>
>
> 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 (rajith@redhat.com) the standalone reproducer you used?
>
> Regards,
>
> Rajith
>
> On Tue, Jul 3, 2012 at 7:10 PM, Rajith Attapattu <ra...@gmail.com> 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
>> <fr...@blueyonder.co.uk> 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
>>>> <richard.fallon@atos.net <ma...@atos.net>> 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:_richard.fallon@atos.net_ <ma...@atos.net>
>>>> 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: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org
>
>
> _______________________________________________________
> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: Java Reconnection failure when processing a Message
Posted by "Fallon, Richard" <ri...@atos.net>.
Hi Rajith,
I retried with the 0.14 libraries and that failed with exactly the same problem. However I retried with 0.16 and that reconnects perfectly well. Which is great news for us.
I don't have the source code available to me here, I could copy it out by hand if you really want it - but essentially all I am doing is stopping the broker at the point in time that my consumer receives a messge (using a MessageConsumer), and sleeps for 10s.
I've rolled 0.16 into our applications and they are all reconnecting successfully.
Richard
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: 04 July 2012 16:34
To: users@qpid.apache.org
Subject: Re: Java Reconnection failure when processing a Message
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 (rajith@redhat.com) the standalone reproducer you used?
Regards,
Rajith
On Tue, Jul 3, 2012 at 7:10 PM, Rajith Attapattu <ra...@gmail.com> 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
> <fr...@blueyonder.co.uk> 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
>>> <richard.fallon@atos.net <ma...@atos.net>> 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:_richard.fallon@atos.net_ <ma...@atos.net>
>>> 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: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org
_______________________________________________________
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Reconnection failure when processing a Message
Posted by Rajith Attapattu <ra...@gmail.com>.
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 (rajith@redhat.com) the standalone reproducer you used?
Regards,
Rajith
On Tue, Jul 3, 2012 at 7:10 PM, Rajith Attapattu <ra...@gmail.com> 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
> <fr...@blueyonder.co.uk> 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 <richard.fallon@atos.net
>>> <ma...@atos.net>> 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:_richard.fallon@atos.net_ <ma...@atos.net>
>>> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Reconnection failure when processing a Message
Posted by Rajith Attapattu <ra...@gmail.com>.
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
<fr...@blueyonder.co.uk> 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 <richard.fallon@atos.net
>> <ma...@atos.net>> 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:_richard.fallon@atos.net_ <ma...@atos.net>
>> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Reconnection failure when processing a Message
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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
> <richard.fallon@atos.net <ma...@atos.net>> 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:_richard.fallon@atos.net_ <ma...@atos.net>
> 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.
>
>
Re: Java Reconnection failure when processing a Message
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <ri...@atos.net>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
>
>
> [image: Picture (Metafile)]
> *Richard Fallon*
> Architect
> 01928 594109
> M:+447733312563
> E:*richard.fallon@atos.net* <ri...@atos.net>
> Atos.net
> [image: 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.
>
>