You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "SebastianR." <Se...@de-gmbh.com> on 2008/08/14 14:07:25 UTC
NMS: Strange behavior when re-connecting after connection abort
Hello,
First of all my setup:
NMS: Yesterdays HEAD SVN revision
Broker: external broker running on ActiveMQ 4.1.1
.Net Framework: 2.0
IDE: MS Visual Studio 2008 with C# as programming language
I recognize very strange behaviour when it comes to a connection failure. To
show this I wrote a little test program, which reproduces this behaviour.
The code is the following:
using System;
using System.Collections.Generic;
using System.Text;
using Apache.NMS;
using Apache.NMS.ActiveMQ;
namespace ExceptionTest
{
class Program
{
static private IConnectionFactory m_Factory;
static private IConnection m_Connection;
static private ISession m_SenderSession;
static private ISession m_ReceiverSession;
static private IDestination m_SenderQueue;
static private IDestination m_ReceiverQueue;
static private IMessageProducer m_Producer;
static private IMessageConsumer m_Receiver;
static void Main(string[] args)
{
Init();
try
{
for (int i = 1; i <= 50; i++)
{
ITextMessage msg =
m_SenderSession.CreateTextMessage(i.ToString());
Console.WriteLine("Before Sending: " + i.ToString());
m_Producer.Send(msg);
Console.WriteLine("After Senden: " + i.ToString());
}
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
Console.ReadLine(); // Here I plug in the network cable
//Optional Re-Connect (refered to as variant 1)
//m_Connection.Stop();
//m_ReceiverSession.Dispose();
//m_SenderSession.Dispose();
//m_Connection.Dispose();
//Init();
while (true)
{
ITextMessage msg = (ITextMessage) m_Receiver.Receive(new
TimeSpan(0,0,0,2));
m_ReceiverSession.Commit();
if(msg != null)
{
Console.WriteLine("Message: " + msg.Text);
}
else
{
Console.WriteLine("No Message available !");
break;
}
}
Console.ReadLine();
}
static private void Init()
{
try
{
m_Factory = new ConnectionFactory(new
Uri("tcp://192.168.3.79:61616"));
m_Connection = m_Factory.CreateConnection("de", "power");
m_ReceiverSession =
m_Connection.CreateSession(AcknowledgementMode.Transactional);
m_SenderSession =
m_Connection.CreateSession(AcknowledgementMode.AutoAcknowledge);
m_SenderQueue = m_SenderSession.GetQueue("outbound");
m_ReceiverQueue = m_ReceiverSession.GetQueue("outbound");
m_Producer = m_SenderSession.CreateProducer(m_SenderQueue);
m_Receiver =
m_ReceiverSession.CreateConsumer(m_ReceiverQueue);
m_Connection.Start();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
}
}
Basically the program’s application flow is the following:
1. Initiate NMS components
2. Send or better try to send 50 messages --> here is where I pull the
network plug to abort the connection
3. OPTIONAL (variant 1, commented out in the code above): Close the
connection and re-connect (initialize again)
4. Receive as many messages as possible
The important things are logged to the console (sending and receiving
messages, exceptions).
Now there are the following testcases:
Without step 3. and without manual connection abort, everything is fine.
Without step 3. and with manual connection abort by pulling the network
plug, I receive an exception (as expected). After going on with the receive
part (without any reconnecting method, as said before), I receive all
messages until the connection abort, even the message on which the exception
(an Apache.NMS.ActiveMQ.BrokerException) is thrown. So although the program
only reaches the “Before Sending ..”-statement, I receive this message -->
very strange
With step 3. and without manual connection abort, everything is fine.
With step 3. and with manual connection abort, I receive no message at all,
although some have been send correctly to the queue before connection abort.
Actually I know they are in the queue, because I wrote a separate Java
programm, a queuebrowser, which lists all correctly sent messages (also
again including the message the exception was thrown on). --> very strange
I recognized however, if I send a message into the queue before the failing
receive try (but after the re-connect) the queuebrowser lists those messages
too, but I still can’t receive any of them. Only way to get out all the
messsages in the queue is restarting the program at let it run without any
connection abort.
Has anyone watched such behavior or knows the reason for this ?
Regards, Sebastian
--
View this message in context: http://www.nabble.com/NMS%3A-Strange-behavior-when-re-connecting-after-connection-abort-tp18980283p18980283.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: NMS: Strange behavior when re-connecting after connection abort
Posted by "SebastianR." <Se...@de-gmbh.com>.
Hiram Chirino wrote:
>
> A connection will hold on to messages that's trying to deliver to it's
> client until the broker detects that the connection has failed.
>
> In the last case is you main thread blocked somewhere?
>
>
Nope, the programm shuts down correctly, probably because at the receive
method a timeout is set.
I tested somehting else: Instead of a transacted receive session I used a
autoacknowledged receive session and get with the same test case following
results:
Without step 3. + without connection abort: Everything is fine, except that
sometimes the first two messages are interchanged, which means I receive
them in the following order: 2,1,3,4,5,6,....
Without step 3. + with connectino abort: Everything is fine, or better to
say as expected. I receive an exception as expcected and when I try to
receive the messages I get all messages which were sent correctly and I NOT
get the message the exception was thrown on (at least an improvement here).
With step 3. + without connection abort: I receive no messages at all. Could
there be a problem with the broker at this point, because this seems very
unusual ?
With step 3. + with connection abort: I also receive no messages at all.
One things to mention here: My seperate Java-QueueBrowser-App doesn't list
any messages at any point of time, even if there are messages in the queue
because seconds later I receive them with the console application. The
receiving mode (autoacknowledged or transacted) seems to influence this
behavior.
However what would be the relevant broker settings that could have something
to do with this behavior ?
Furthermore what exactly does this mean "A connection will hold on to
messages that's trying to deliver to it's client until the broker detects
that the connection has failed." ? When the broker doesn't realize a
connection loss the queue somehow hangs, because it still tries to deliver
the messages to the client ?
Regards, Sebastian
--
View this message in context: http://www.nabble.com/NMS%3A-Strange-behavior-when-re-connecting-after-connection-abort-tp18980283p19026820.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: NMS: Strange behavior when re-connecting after connection abort
Posted by Hiram Chirino <hi...@hiramchirino.com>.
A connection will hold on to messages that's trying to deliver to it's
client until the broker detects that the connection has failed.
In the last case is you main thread blocked somewhere?
On Thu, Aug 14, 2008 at 8:07 AM, SebastianR.
<Se...@de-gmbh.com> wrote:
>
> Hello,
>
> First of all my setup:
> NMS: Yesterdays HEAD SVN revision
> Broker: external broker running on ActiveMQ 4.1.1
> .Net Framework: 2.0
> IDE: MS Visual Studio 2008 with C# as programming language
>
> I recognize very strange behaviour when it comes to a connection failure. To
> show this I wrote a little test program, which reproduces this behaviour.
> The code is the following:
>
> using System;
> using System.Collections.Generic;
> using System.Text;
> using Apache.NMS;
> using Apache.NMS.ActiveMQ;
>
> namespace ExceptionTest
> {
> class Program
> {
> static private IConnectionFactory m_Factory;
> static private IConnection m_Connection;
> static private ISession m_SenderSession;
> static private ISession m_ReceiverSession;
> static private IDestination m_SenderQueue;
> static private IDestination m_ReceiverQueue;
> static private IMessageProducer m_Producer;
> static private IMessageConsumer m_Receiver;
>
> static void Main(string[] args)
> {
> Init();
> try
> {
> for (int i = 1; i <= 50; i++)
> {
> ITextMessage msg =
> m_SenderSession.CreateTextMessage(i.ToString());
>
> Console.WriteLine("Before Sending: " + i.ToString());
> m_Producer.Send(msg);
> Console.WriteLine("After Senden: " + i.ToString());
> }
> }
> catch (Exception e)
> {
> Console.WriteLine(e.ToString());
> }
>
> Console.ReadLine(); // Here I plug in the network cable
>
> //Optional Re-Connect (refered to as variant 1)
> //m_Connection.Stop();
> //m_ReceiverSession.Dispose();
> //m_SenderSession.Dispose();
> //m_Connection.Dispose();
> //Init();
>
> while (true)
> {
> ITextMessage msg = (ITextMessage) m_Receiver.Receive(new
> TimeSpan(0,0,0,2));
> m_ReceiverSession.Commit();
>
> if(msg != null)
> {
> Console.WriteLine("Message: " + msg.Text);
> }
> else
> {
> Console.WriteLine("No Message available !");
> break;
> }
> }
> Console.ReadLine();
> }
>
> static private void Init()
> {
> try
> {
> m_Factory = new ConnectionFactory(new
> Uri("tcp://192.168.3.79:61616"));
> m_Connection = m_Factory.CreateConnection("de", "power");
> m_ReceiverSession =
> m_Connection.CreateSession(AcknowledgementMode.Transactional);
> m_SenderSession =
> m_Connection.CreateSession(AcknowledgementMode.AutoAcknowledge);
> m_SenderQueue = m_SenderSession.GetQueue("outbound");
> m_ReceiverQueue = m_ReceiverSession.GetQueue("outbound");
> m_Producer = m_SenderSession.CreateProducer(m_SenderQueue);
> m_Receiver =
> m_ReceiverSession.CreateConsumer(m_ReceiverQueue);
> m_Connection.Start();
> }
> catch (Exception e)
> {
> Console.WriteLine(e.ToString());
> }
> }
> }
> }
>
>
> Basically the program's application flow is the following:
> 1. Initiate NMS components
> 2. Send or better try to send 50 messages --> here is where I pull the
> network plug to abort the connection
> 3. OPTIONAL (variant 1, commented out in the code above): Close the
> connection and re-connect (initialize again)
> 4. Receive as many messages as possible
>
> The important things are logged to the console (sending and receiving
> messages, exceptions).
>
> Now there are the following testcases:
>
> Without step 3. and without manual connection abort, everything is fine.
>
> Without step 3. and with manual connection abort by pulling the network
> plug, I receive an exception (as expected). After going on with the receive
> part (without any reconnecting method, as said before), I receive all
> messages until the connection abort, even the message on which the exception
> (an Apache.NMS.ActiveMQ.BrokerException) is thrown. So although the program
> only reaches the "Before Sending .."-statement, I receive this message -->
> very strange
>
> With step 3. and without manual connection abort, everything is fine.
>
> With step 3. and with manual connection abort, I receive no message at all,
> although some have been send correctly to the queue before connection abort.
> Actually I know they are in the queue, because I wrote a separate Java
> programm, a queuebrowser, which lists all correctly sent messages (also
> again including the message the exception was thrown on). --> very strange
> I recognized however, if I send a message into the queue before the failing
> receive try (but after the re-connect) the queuebrowser lists those messages
> too, but I still can't receive any of them. Only way to get out all the
> messsages in the queue is restarting the program at let it run without any
> connection abort.
>
> Has anyone watched such behavior or knows the reason for this ?
>
> Regards, Sebastian
>
> --
> View this message in context: http://www.nabble.com/NMS%3A-Strange-behavior-when-re-connecting-after-connection-abort-tp18980283p18980283.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com