Do activemq-cpp connection questions.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
JRR
Reply | Threaded
Open this post in threaded view
|

Do activemq-cpp connection questions.

JRR
Hello,

I've read through the activemq-cpp tutorial at http://activemq.apache.org/cms/cms-api-overview.html and I've poked around the forums.

Do activemq-cpp connection have a timeout when the client is connecting to the broker? I ask because reading this post (http://activemq.2283324.n4.nabble.com/Async-Exception-multiple-threads-one-connection-tp2351214p2351217.html) comments on a connection being disconnected due to inactivity. Although that articles example is Java based as opposed to C++. I've looked through the connections class and I do not see anything relating to a connection timeout. Do activemqq-cpp connections have a timeout?

Aside from that what is the process or detecting if a connection is down and then reestablishing the connection. For example, suppose the broker is restarted, but the producer is not. How would the producer know if its connection went down? Is it just that the MessageProducer's send throws an exception?

In order to reestablish the connection is it a matter of reallocating everything, connection, session, message producer, etc?

Are there other tutorials, web sites, etc. that you could refer me to for more information on activemq-cpp usage? Perhaps these questions are covered there?

Thank your time,

-=John
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

tabish121@gmail.com
On Tue, 2011-11-29 at 08:22 -0800, JRR wrote:

> Hello,
>
> I've read through the activemq-cpp tutorial at
> http://activemq.apache.org/cms/cms-api-overview.html and I've poked around
> the forums.
>
> Do activemq-cpp connection have a timeout when the client is connecting to
> the broker? I ask because reading this post
> (http://activemq.2283324.n4.nabble.com/Async-Exception-multiple-threads-one-connection-tp2351214p2351217.html)
> comments on a connection being disconnected due to inactivity. Although that
> articles example is Java based as opposed to C++. I've looked through the
> connections class and I do not see anything relating to a connection
> timeout. Do activemqq-cpp connections have a timeout?
>
> Aside from that what is the process or detecting if a connection is down and
> then reestablishing the connection. For example, suppose the broker is
> restarted, but the producer is not. How would the producer know if its
> connection went down? Is it just that the MessageProducer's send throws an
> exception?
>
> In order to reestablish the connection is it a matter of reallocating
> everything, connection, session, message producer, etc?
>
> Are there other tutorials, web sites, etc. that you could refer me to for
> more information on activemq-cpp usage? Perhaps these questions are covered
> there?
>
> Thank your time,
>

If you use the failover transport then you don't have to deal with the
problem of reestablishing the connection, the client will do that for
you.  If you don't use that then you need to catch exceptions from the
client calls as well as register an onException handler to know that the
client connection has failed and then tear down and rebuild the CMS
objects.  

You can view the various configuration options for the transports and
client here:
http://activemq.apache.org/cms/configuring.html

Regards

--
Tim Bish
------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: tabish121
Blog: http://timbish.blogspot.com/



JRR
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

JRR
Hi Tim,

Thank you for the suggestion to use Failover. I even see from the simple_producer example, that they use failover to connect to localhost. I initially thought of failover as available if you had an alternative to failover too. Now I know better.

I was reading the options on http://activemq.apache.org/cms/configuring.html and I have a question about them. In the section for "Failover Transport Options" there are two delay options. What is the scale for these delay options? It just says "How long to wait..." or "Maximum time to wait...." Is the values scale seconds, milliseconds or some other value?

I see that one of the time values in the General Transport Options section indicates milliseconds, but I don't see any time scales elsewhere. Can I assume that all time values are in milliseconds for these parameters?

Thank you,

-=John
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

tabish121@gmail.com
On Tue, 2011-11-29 at 11:38 -0800, JRR wrote:

> Hi Tim,
>
> Thank you for the suggestion to use Failover. I even see from the
> simple_producer example, that they use failover to connect to localhost. I
> initially thought of failover as available if you had an alternative to
> failover too. Now I know better.
>
> I was reading the options on http://activemq.apache.org/cms/configuring.html
> and I have a question about them. In the section for "Failover Transport
> Options" there are two delay options. What is the scale for these delay
> options? It just says "/How long to wait.../" or "/Maximum time to
> wait.../." Is the values scale seconds, milliseconds or some other value?
>
> I see that one of the time values in the General Transport Options section
> indicates milliseconds, but I don't see any time scales elsewhere. Can I
> assume that all time values are in milliseconds for these parameters?
>
> Thank you,
>

All time values are in Milliseconds.

--
Tim Bish
------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: tabish121
Blog: http://timbish.blogspot.com/



JRR
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

JRR
Hello Tim,

I am playing with the simple producer and the fail over options. However, I am not getting the results I expected and I'm hoping you can share some insights.

I am using version 3.2.3 of the activemq-cpp library on a SuSE Linux machine.

I changed the simple producer example so that the broker URI is:
----------------------------------------
    std::string brokerURI =
        "failover:(tcp://127.0.0.1:61616"
        "?initialReconnectDelay=10"
        "&maxReconnectDelay=100"
        "&useExponentialBackOff=false"
        "&maxReconnectAttempts=1"
        "&startupMaxReconnectAttempts=1"
        "&timeout=100"
        ")";
----------------------------------------


And I added output to show me the brokerURI and it is as I expected:
----------------------------------------
Broker URI: failover:(tcp://127.0.0.1:61616?initialReconnectDelay=10&maxReconnectDelay=100&useExponentialBackOff=false&maxReconnectAttempts=1&startupMaxReconnectAttempts=1&timeout=100)
----------------------------------------

I wanted to test the scenario when starting the producer when the broker isn't running. With these setting, my expectation is that it would throw an exception when the factory created the connection, and I would see the  stack trace (as per the simple example).

However, what I found is that a connection object is created and returned (even though the broker is not running), and then the code blocks at the start() call that follows the connection create. I've confirmed this with GDB.

----------------------------------------
    // Create a Connection
    try{
        std::cout << "Connection before " << connection << "\n";
        connection = connectionFactory->createConnection();

        std::cout << "Connection after " << connection << "\n";
        std::cout << "Connection done. Starting it\n";

        connection->start();

    } catch( CMSException& e ) {
        e.printStackTrace();
        throw e;
    }
    std::cout << "Connection start done. Creating Session\n";
----------------------------------------


What is the corrrect way to do this? What I want is to use the failover method, but I don't want to wait forever. If the producer cannot initially connect, I'd like to eventually timeout and quit.
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

tabish121@gmail.com
On Tue, 2011-11-29 at 16:20 -0800, JRR wrote:

> Hello Tim,
>
> I am playing with the simple producer and the fail over options. However, I
> am not getting the results I expected and I'm hoping you can share some
> insights.
>
> I am using version 3.2.3 of the activemq-cpp library on a SuSE Linux
> machine.
>
> I changed the simple producer example so that the broker URI is:
> ----------------------------------------
>     std::string brokerURI =
>         "failover:(tcp://127.0.0.1:61616"
>         "?initialReconnectDelay=10"
>         "&maxReconnectDelay=100"
>         "&useExponentialBackOff=false"
>         "&maxReconnectAttempts=1"
>         "&startupMaxReconnectAttempts=1"
>         "&timeout=100"
>         ")";
> ----------------------------------------
>
>
> And I added output to show me the brokerURI and it is as I expected:
> ----------------------------------------
> Broker URI:
> failover:(tcp://127.0.0.1:61616?initialReconnectDelay=10&maxReconnectDelay=100&useExponentialBackOff=false&maxReconnectAttempts=1&startupMaxReconnectAttempts=1&timeout=100)
> ----------------------------------------
>
> I wanted to test the scenario when starting the producer when the broker
> isn't running. With these setting, my expectation is that it would throw an
> exception when the factory created the connection, and I would see the
> stack trace (as per the simple example).
>
> However, what I found is that a connection object is created and returned
> (even though the broker is not running), and then the code blocks at the
> start() call that follows the connection create. I've confirmed this with
> GDB.
>
> ----------------------------------------
>     // Create a Connection
>     try{
>         std::cout << "Connection before " << connection << "\n";
>         connection = connectionFactory->createConnection();
>
>         std::cout << "Connection after " << connection << "\n";
>         std::cout << "Connection done. Starting it\n";
>
>         connection->start();
>
>     } catch( CMSException& e ) {
>         e.printStackTrace();
>         throw e;
>     }
>     std::cout << "Connection start done. Creating Session\n";
> ----------------------------------------
>
>
> What is the corrrect way to do this? What I want is to use the failover
> method, but I don't want to wait forever. If the producer cannot initially
> connect, I'd like to eventually timeout and quit.

I would suggest that you try the latest version of the client, this
could be related to issues that were already fixed.  

Regards

--
Tim Bish
------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: tabish121
Blog: http://timbish.blogspot.com/



JRR
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

JRR
Hello Tim,

I tried the test using version 3.4.0 of ActiveMQ-CPP and the problem remains the same. The connection factory creates a connection even if there is no broker running, and I've set the parameters to not try forever. Then when start is invoked on the connection it blocks until the broker is started.

Moreover, as a debugging attempt, I tried without the default failover settings (infinite waits, etc). It appears that the initial behavior for connecting to the broker isn't working correctly, in that it does not appear to honor the startupMaxReconnectAttempts value.

Or, I'm doing something wrong.

Suggestions?

Thanks,

-=John
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

tabish121@gmail.com
In this case you best source of info is the code.  Stepping into the
FailovetTransport start method and the reconnect method may show what is
going wrong.
On Nov 30, 2011 12:40 PM, "JRR" <[hidden email]> wrote:

> Hello Tim,
>
> I tried the test using version */3.4.0/* of ActiveMQ-CPP and the problem
> remains the same. The connection factory creates a connection even if there
> is no broker running, and I've set the parameters to not try forever. Then
> when start is invoked on the connection it blocks until the broker is
> started.
>
> Moreover, as a debugging attempt, I tried without the default failover
> settings (infinite waits, etc). It appears that the initial behavior for
> connecting to the broker isn't working correctly, in that it does not
> appear
> to honor the startupMaxReconnectAttempts value.
>
> Or, I'm doing something wrong.
>
> Suggestions?
>
> Thanks,
>
> -=John
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Do-activemq-cpp-connection-questions-tp4119766p4123969.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
JRR
Reply | Threaded
Open this post in threaded view
|

Re: Do activemq-cpp connection questions.

JRR
Hi Tim,

I used gdb along with the code and I figured out the problem. It was indeed my
fault, an ID10T error on my part.

I constructed an invalid broker URI string.

My string was as follows:

    std::string brokerURI =
        "failover:(tcp://127.0.0.1:61616"
        "?initialReconnectDelay=10"
        "&maxReconnectDelay=100"
        "&useExponentialBackOff=false"
        "&maxReconnectAttempts=1"
        "&startupMaxReconnectAttempts=1"
        "&timeout=100"
        ")";


The problem is with the closing paren. It should be

    std::string brokerURI =
        "failover:(tcp://127.0.0.1:61616)" // close out the tcp paren here
        "?initialReconnectDelay=10"        // before adding query parameters
        "&maxReconnectDelay=100"
        "&useExponentialBackOff=false"
        "&maxReconnectAttempts=1"
        "&startupMaxReconnectAttempts=1"
        "&timeout=100";

Now... in my defense... the code in the simple producer example makes it look
like it is suppose to reside at the end. This is what's in the file
src/examples/producers/SimpleProducer.cpp

.....
    std::string brokerURI =
        "failover://(tcp://127.0.0.1:61616"
//        "?wireFormat=openwire"
//        "&connection.useAsyncSend=true"
//        "&transport.commandTracingEnabled=true"
//        "&transport.tcpTracingEnabled=true"
//        "&wireFormat.tightEncodingEnabled=true"
        ")";
....

So it LOOKS like we just uncomment these lines to add the query parameters.