qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fallon, Richard" <richard.fal...@atos.net>
Subject Java Reconnection failure when processing a Message
Date Tue, 03 Jul 2012 11:04:27 GMT

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

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
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){

//standard connection stuff
//every time a message is received pause processing
}//end try
catch(Throwable e)
}//end catch
}//end while
}//end main

public static void receiveMessage(){

Message message = messageConsumer.receive(TIMEOUT);


//got message 

}//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

Could you advise if 
a)	You are aware of this and whether it has been fixed in a later
b)	Whether my proposed "fix" will have other adverse side affects?
c) 	Should I send this to a different forum?

Thanks for your help


 <<Picture (Metafile)>> 
Richard Fallon
01928 594109
 <<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.

View raw message