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.
