timeouts

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

timeouts

Jen Andre
Hello,

I have a Java client listener that subscribes to a topic and waits for messages.  I'm noticing after 120 seconds of idle time  (no messages received) the connections time out (here's what I see in syslog messages for qpidd)

qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing

This is consistent with the debug messages I'm seeing on the client side:

IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by the connection, using the brokers max value 120

and


IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0 ConnectionHeartbeat()
IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0 ConnectionHeartbeat()
IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG [apache.qpid.transport.Connection] connection closed: conn:9ced8e


I'm a bit confused on how timeouts and heartbeats are supposed to work.    Does the client force the disconnect, or the server, or both, if the heartbeats are not received in a specific period of time?  Do both peers send heartbeats? (this seems to imply it does. http://qpid.apache.org/configure-broker-and-client-heartbeating.html).

I do notice that while I see a lot of RECV: heartbeat debug messages on the client side, I don't see any SEND: messages that indicates it's sending them to server.   If the client is supposed to send them to the server periodically to ensure the connection stays alive, how can I ensure this is happening? (setting system property amqj.heartbeat.delay seems to have no effect).

Thanks!
Jen




Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Rajith Muditha Attapattu
Hello Jean,

It appears that you are using the C++ broker and the java client.
Could you confirm which version you are using?

On Tue, Jan 5, 2010 at 12:47 PM, Jen Andre <[hidden email]> wrote:

>
> Hello,
>
> I have a Java client listener that subscribes to a topic and waits for
> messages.  I'm noticing after 120 seconds of idle time  (no messages
> received) the connections time out (here's what I see in syslog messages for
> qpidd)
>
> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>
> This is consistent with the debug messages I'm seeing on the client side:
>
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
> the connection, using the brokers max value 120
>
> and
>
>
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
> ConnectionHeartbeat()
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
> ConnectionHeartbeat()
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>
>
> I'm a bit confused on how timeouts and heartbeats are supposed to work.
> Does the client force the disconnect, or the server, or both, if the
> heartbeats are not received in a specific period of time?
Both the client and the broker could enforce a disconnect if they
don't see any activity during two consecutive heartbeat intervals.

 Do both peers
> send heartbeats? (this seems to imply it does.
Both peers do send a heartbeat.
The JMS client (0-10 version which you are using against the c++
broker) will echo a heartbeat in response to one sent by the broker.

> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
The link you provided is for the JMS Client (0-8 version) and the Java Broker.
At the moment it's slightly different from JMS Client (0-10) and c++
broker combination.

The amqj.heartbeat.delay is only effective for the 0-8 codepath.
If you need to set the idle timeout for the 0-10 client you need to
set it in the broker URL as follows

amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60''
Please note the idle_timeout is in secs and not in milisecs.

We are working on consolidating the configuration and behaviour of the
JMS client for both 0-8/9 and 0-10 versions.

> I do notice that while I see a lot of RECV: heartbeat debug messages on the
> client side, I don't see any SEND: messages that indicates it's sending them
> to server.   If the client is supposed to send them to the server
> periodically to ensure the connection stays alive, how can I ensure this is
> happening? (setting system property amqj.heartbeat.delay seems to have no
> effect).
>
> Thanks!
> Jen
>
>
>
>
>
> --
> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4256406.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[hidden email]
>
>



--
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: timeouts

JAkub Scholz
In reply to this post by Jen Andre
Hi,

I had a similar problem with the C++ broker and Java client from release 0.5
(with the Qpid API, JMS API didn't suffered with this problem). I tried to
download the latest source from trunk in SVN repository and compile the
library myself and it solved the problem for me.

Regards
JAkub Scholz

> -----Original Message-----
> From: Jen Andre [mailto:[hidden email]]
> Sent: Tuesday, January 05, 2010 6:48 PM
> To: [hidden email]
> Subject: timeouts
>
>
> Hello,
>
> I have a Java client listener that subscribes to a topic and waits for
> messages.  I'm noticing after 120 seconds of idle time  (no messages
> received) the connections time out (here's what I see in syslog
> messages for
> qpidd)
>
> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>
> This is consistent with the debug messages I'm seeing on the client
> side:
>
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set
> by
> the connection, using the brokers max value 120
>
> and
>
>
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
> ConnectionHeartbeat()
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
> ConnectionHeartbeat()
> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>
>
> I'm a bit confused on how timeouts and heartbeats are supposed to work.
> Does the client force the disconnect, or the server, or both, if the
> heartbeats are not received in a specific period of time?  Do both
> peers
> send heartbeats? (this seems to imply it does.
> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
>
> I do notice that while I see a lot of RECV: heartbeat debug messages on
> the
> client side, I don't see any SEND: messages that indicates it's sending
> them
> to server.   If the client is supposed to send them to the server
> periodically to ensure the connection stays alive, how can I ensure
> this is
> happening? (setting system property amqj.heartbeat.delay seems to have
> no
> effect).
>
> Thanks!
> Jen
>
>
>
>
>
> --
> View this message in context: http://n2.nabble.com/timeouts-
> tp4256406p4256406.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[hidden email]


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Jen Andre
This post has NOT been accepted by the mailing list yet.
In reply to this post by Rajith Muditha Attapattu
Yes, I am using both the c++ broker and the java library from 0.5.

Setting the idle_timeout in the AMQP url doesn't seem affect anything.
  I will try grabbing the latest from trunk as suggested by another
user.

I'm not sure which API I'm supposed to be using.  I tried both the
code in  org.apache.qpid.client.* and  org.apache.qpid.transport.* and
I get the same behavior.

Here some sample code.  Maybe you can tell me what I'm doing wrong
(192.168.10.128 is the IP address of the broker):


        String url =

String.format("amqp://%s:%s@%s/?brokerlist='tcp://%s:%d?idle_timeout='60''&clientid=%s&ssl=%s",
                    "guest", "guest", "192.168.10.128",
"192.168.10.128", 5672, "myid",
                    false);

            log.debug("url: " + url);

            AMQConnection c = new AMQConnection(url);

            try {

                final AMQSession session = (AMQSession)
c.createSession(false, AMQSession.AUTO_ACKNOWLEDGE);

                // make the queue name same as the binding key, make it durable

                AMQDestination queueDestination = new AMQTopic(new
AMQShortString("amq.topic"),
                        new AMQShortString("myBindingKey"),
                        false,
                        new AMQShortString("myBindingKey"),
                        true);


                c.setIdleTimeout(0);

                log.info("Binding to " + "myBindingKey");

                session.declareAndBind(queueDestination);

                MessageConsumer consumer =
session.createExclusiveConsumer(queueDestination);

                consumer.setMessageListener(new MessageListener() {

                    public void onMessage(Message arg0) {
                       System.out.println("Got message...");
                    }
                    }
                );


                c.start();

                Thread.sleep(1000 * 360); // sleep 360 seconds to trigger issue

                session.close();

            } finally {

                c.close();
            }


Thanks!
-Jen

On Tue, Jan 5, 2010 at 2:31 PM, Rajith Attapattu [via Apache Qpid
users] <[hidden email]> wrote:

> Hello Jean,
>
> It appears that you are using the C++ broker and the java client.
> Could you confirm which version you are using?
>
> On Tue, Jan 5, 2010 at 12:47 PM, Jen Andre <[hidden email]> wrote:
>>
>> Hello,
>>
>> I have a Java client listener that subscribes to a topic and waits for
>> messages.  I'm noticing after 120 seconds of idle time  (no messages
>> received) the connections time out (here's what I see in syslog messages
>> for
>> qpidd)
>>
>> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>>
>> This is consistent with the debug messages I'm seeing on the client side:
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
>> the connection, using the brokers max value 120
>>
>> and
>>
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>
>>
>> I'm a bit confused on how timeouts and heartbeats are supposed to work.
>> Does the client force the disconnect, or the server, or both, if the
>> heartbeats are not received in a specific period of time?
> Both the client and the broker could enforce a disconnect if they
> don't see any activity during two consecutive heartbeat intervals.
>
>  Do both peers
>> send heartbeats? (this seems to imply it does.
> Both peers do send a heartbeat.
> The JMS client (0-10 version which you are using against the c++
> broker) will echo a heartbeat in response to one sent by the broker.
>
>> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
> The link you provided is for the JMS Client (0-8 version) and the Java
> Broker.
> At the moment it's slightly different from JMS Client (0-10) and c++
> broker combination.
>
> The amqj.heartbeat.delay is only effective for the 0-8 codepath.
> If you need to set the idle timeout for the 0-10 client you need to
> set it in the broker URL as follows
>
> amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60''
> Please note the idle_timeout is in secs and not in milisecs.
>
> We are working on consolidating the configuration and behaviour of the
> JMS client for both 0-8/9 and 0-10 versions.
>
>> I do notice that while I see a lot of RECV: heartbeat debug messages on
>> the
>> client side, I don't see any SEND: messages that indicates it's sending
>> them
>> to server.   If the client is supposed to send them to the server
>> periodically to ensure the connection stays alive, how can I ensure this
>> is
>> happening? (setting system property amqj.heartbeat.delay seems to have no
>> effect).
>>
>> Thanks!
>> Jen
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/timeouts-tp4256406p4256406.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[hidden email]
>>
>>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[hidden email]
>
>
>
> ________________________________
> View message @ http://n2.nabble.com/timeouts-tp4256406p4256885.html
> To unsubscribe from timeouts, click here.
>
Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Robert Greig
Administrator
I would remove this line:

c.setIdleTimeout(0);

Robert

2010/1/5 Jen Andre <[hidden email]>:

>
> Yes, I am using both the c++ broker and the java library from 0.5.
>
> Setting the idle_timeout in the AMQP url doesn't seem affect anything.
>  I will try grabbing the latest from trunk as suggested by another
> user.
>
> I'm not sure which API I'm supposed to be using.  I tried both the
> code in  org.apache.qpid.client.* and  org.apache.qpid.transport.* and
> I get the same behavior.
>
> Here some sample code.  Maybe you can tell me what I'm doing wrong
> (192.168.10.128 is the IP address of the broker):
>
>
>        String url =
>
> String.format("amqp://%s:%s@%s/?brokerlist='tcp://%s:%d?idle_timeout='60''&clientid=%s&ssl=%s",
>                    "guest", "guest", "192.168.10.128",
> "192.168.10.128", 5672, "myid",
>                    false);
>
>            log.debug("url: " + url);
>
>            AMQConnection c = new AMQConnection(url);
>
>            try {
>
>                final AMQSession session = (AMQSession)
> c.createSession(false, AMQSession.AUTO_ACKNOWLEDGE);
>
>                // make the queue name same as the binding key, make it durable
>
>                AMQDestination queueDestination = new AMQTopic(new
> AMQShortString("amq.topic"),
>                        new AMQShortString("myBindingKey"),
>                        false,
>                        new AMQShortString("myBindingKey"),
>                        true);
>
>
>                c.setIdleTimeout(0);
>
>                log.info("Binding to " + "myBindingKey");
>
>                session.declareAndBind(queueDestination);
>
>                MessageConsumer consumer =
> session.createExclusiveConsumer(queueDestination);
>
>                consumer.setMessageListener(new MessageListener() {
>
>                    public void onMessage(Message arg0) {
>                       System.out.println("Got message...");
>                    }
>                    }
>                );
>
>
>                c.start();
>
>                Thread.sleep(1000 * 360); // sleep 360 seconds to trigger issue
>
>                session.close();
>
>            } finally {
>
>                c.close();
>            }
>
>
> Thanks!
> -Jen
>
> On Tue, Jan 5, 2010 at 2:31 PM, Rajith Attapattu [via Apache Qpid
> users] <[hidden email]> wrote:
>> Hello Jean,
>>
>> It appears that you are using the C++ broker and the java client.
>> Could you confirm which version you are using?
>>
>> On Tue, Jan 5, 2010 at 12:47 PM, Jen Andre <[hidden email]> wrote:
>>>
>>> Hello,
>>>
>>> I have a Java client listener that subscribes to a topic and waits for
>>> messages.  I'm noticing after 120 seconds of idle time  (no messages
>>> received) the connections time out (here's what I see in syslog messages
>>> for
>>> qpidd)
>>>
>>> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>>>
>>> This is consistent with the debug messages I'm seeing on the client side:
>>>
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
>>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
>>> the connection, using the brokers max value 120
>>>
>>> and
>>>
>>>
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>>> ConnectionHeartbeat()
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>>> ConnectionHeartbeat()
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>>
>>>
>>> I'm a bit confused on how timeouts and heartbeats are supposed to work.
>>> Does the client force the disconnect, or the server, or both, if the
>>> heartbeats are not received in a specific period of time?
>> Both the client and the broker could enforce a disconnect if they
>> don't see any activity during two consecutive heartbeat intervals.
>>
>>  Do both peers
>>> send heartbeats? (this seems to imply it does.
>> Both peers do send a heartbeat.
>> The JMS client (0-10 version which you are using against the c++
>> broker) will echo a heartbeat in response to one sent by the broker.
>>
>>> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
>> The link you provided is for the JMS Client (0-8 version) and the Java
>> Broker.
>> At the moment it's slightly different from JMS Client (0-10) and c++
>> broker combination.
>>
>> The amqj.heartbeat.delay is only effective for the 0-8 codepath.
>> If you need to set the idle timeout for the 0-10 client you need to
>> set it in the broker URL as follows
>>
>> amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60''
>> Please note the idle_timeout is in secs and not in milisecs.
>>
>> We are working on consolidating the configuration and behaviour of the
>> JMS client for both 0-8/9 and 0-10 versions.
>>
>>> I do notice that while I see a lot of RECV: heartbeat debug messages on
>>> the
>>> client side, I don't see any SEND: messages that indicates it's sending
>>> them
>>> to server.   If the client is supposed to send them to the server
>>> periodically to ensure the connection stays alive, how can I ensure this
>>> is
>>> happening? (setting system property amqj.heartbeat.delay seems to have no
>>> effect).
>>>
>>> Thanks!
>>> Jen
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/timeouts-tp4256406p4256406.html
>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:      http://qpid.apache.org
>>> Use/Interact: mailto:[hidden email]
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[hidden email]
>>
>>
>>
>> ________________________________
>> View message @ http://n2.nabble.com/timeouts-tp4256406p4256885.html
>> To unsubscribe from timeouts, click here.
>>
>
> --
> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4257648.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Rajith Muditha Attapattu
In reply to this post by JAkub Scholz
Jakub,

We don't support a Java Qpid API.
The supported API for java is JMS.

Regards,

Rajith

On Tue, Jan 5, 2010 at 3:29 PM, JAkub Scholz <[hidden email]> wrote:

> Hi,
>
> I had a similar problem with the C++ broker and Java client from release 0.5
> (with the Qpid API, JMS API didn't suffered with this problem). I tried to
> download the latest source from trunk in SVN repository and compile the
> library myself and it solved the problem for me.
>
> Regards
> JAkub Scholz
>
>> -----Original Message-----
>> From: Jen Andre [mailto:[hidden email]]
>> Sent: Tuesday, January 05, 2010 6:48 PM
>> To: [hidden email]
>> Subject: timeouts
>>
>>
>> Hello,
>>
>> I have a Java client listener that subscribes to a topic and waits for
>> messages.  I'm noticing after 120 seconds of idle time  (no messages
>> received) the connections time out (here's what I see in syslog
>> messages for
>> qpidd)
>>
>> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>>
>> This is consistent with the debug messages I'm seeing on the client
>> side:
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set
>> by
>> the connection, using the brokers max value 120
>>
>> and
>>
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>
>>
>> I'm a bit confused on how timeouts and heartbeats are supposed to work.
>> Does the client force the disconnect, or the server, or both, if the
>> heartbeats are not received in a specific period of time?  Do both
>> peers
>> send heartbeats? (this seems to imply it does.
>> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
>>
>> I do notice that while I see a lot of RECV: heartbeat debug messages on
>> the
>> client side, I don't see any SEND: messages that indicates it's sending
>> them
>> to server.   If the client is supposed to send them to the server
>> periodically to ensure the connection stays alive, how can I ensure
>> this is
>> happening? (setting system property amqj.heartbeat.delay seems to have
>> no
>> effect).
>>
>> Thanks!
>> Jen
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://n2.nabble.com/timeouts-
>> tp4256406p4256406.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[hidden email]
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[hidden email]
>
>



--
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Rajith Muditha Attapattu
In reply to this post by Jen Andre
On Tue, Jan 5, 2010 at 4:48 PM, Jen Andre <[hidden email]> wrote:

>
> Yes, I am using both the c++ broker and the java library from 0.5.
>
> Setting the idle_timeout in the AMQP url doesn't seem affect anything.
>  I will try grabbing the latest from trunk as suggested by another
> user.
>
> I'm not sure which API I'm supposed to be using.  I tried both the
> code in  org.apache.qpid.client.* and  org.apache.qpid.transport.* and
> I get the same behavior.

You are supposed to use the JMS API.
The classes you are using right now are in the implementation layer
and are subject to change without any notice btw versions.

> Here some sample code.  Maybe you can tell me what I'm doing wrong

I cut paste your code and added an exception listener to the
connection and I didn't see any timeouts.

If I did a kill -STOP <broker-pid> then I saw a the client dropping
the connection after 120 secs.

> (192.168.10.128 is the IP address of the broker):
>
>
>        String url =
>
> String.format("amqp://%s:%s@%s/?brokerlist='tcp://%s:%d?idle_timeout='60''&clientid=%s&ssl=%s",
>                    "guest", "guest", "192.168.10.128",
> "192.168.10.128", 5672, "myid",
>                    false);
>
>            log.debug("url: " + url);
>
>            AMQConnection c = new AMQConnection(url);
>
>            try {
>
>                final AMQSession session = (AMQSession)
> c.createSession(false, AMQSession.AUTO_ACKNOWLEDGE);
>
>                // make the queue name same as the binding key, make it durable
>
>                AMQDestination queueDestination = new AMQTopic(new
> AMQShortString("amq.topic"),
>                        new AMQShortString("myBindingKey"),
>                        false,
>                        new AMQShortString("myBindingKey"),
>                        true);
>
>
>                c.setIdleTimeout(0);
>
>                log.info("Binding to " + "myBindingKey");
>
>                session.declareAndBind(queueDestination);
>
>                MessageConsumer consumer =
> session.createExclusiveConsumer(queueDestination);
>
>                consumer.setMessageListener(new MessageListener() {
>
>                    public void onMessage(Message arg0) {
>                       System.out.println("Got message...");
>                    }
>                    }
>                );
>
>
>                c.start();
>
>                Thread.sleep(1000 * 360); // sleep 360 seconds to trigger issue
>
>                session.close();
>
>            } finally {
>
>                c.close();
>            }
>
>
> Thanks!
> -Jen
>
> On Tue, Jan 5, 2010 at 2:31 PM, Rajith Attapattu [via Apache Qpid
> users] <[hidden email]> wrote:
>> Hello Jean,
>>
>> It appears that you are using the C++ broker and the java client.
>> Could you confirm which version you are using?
>>
>> On Tue, Jan 5, 2010 at 12:47 PM, Jen Andre <[hidden email]> wrote:
>>>
>>> Hello,
>>>
>>> I have a Java client listener that subscribes to a topic and waits for
>>> messages.  I'm noticing after 120 seconds of idle time  (no messages
>>> received) the connections time out (here's what I see in syslog messages
>>> for
>>> qpidd)
>>>
>>> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>>>
>>> This is consistent with the debug messages I'm seeing on the client side:
>>>
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
>>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
>>> the connection, using the brokers max value 120
>>>
>>> and
>>>
>>>
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>>> ConnectionHeartbeat()
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>>> ConnectionHeartbeat()
>>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>>
>>>
>>> I'm a bit confused on how timeouts and heartbeats are supposed to work.
>>> Does the client force the disconnect, or the server, or both, if the
>>> heartbeats are not received in a specific period of time?
>> Both the client and the broker could enforce a disconnect if they
>> don't see any activity during two consecutive heartbeat intervals.
>>
>>  Do both peers
>>> send heartbeats? (this seems to imply it does.
>> Both peers do send a heartbeat.
>> The JMS client (0-10 version which you are using against the c++
>> broker) will echo a heartbeat in response to one sent by the broker.
>>
>>> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
>> The link you provided is for the JMS Client (0-8 version) and the Java
>> Broker.
>> At the moment it's slightly different from JMS Client (0-10) and c++
>> broker combination.
>>
>> The amqj.heartbeat.delay is only effective for the 0-8 codepath.
>> If you need to set the idle timeout for the 0-10 client you need to
>> set it in the broker URL as follows
>>
>> amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60''
>> Please note the idle_timeout is in secs and not in milisecs.
>>
>> We are working on consolidating the configuration and behaviour of the
>> JMS client for both 0-8/9 and 0-10 versions.
>>
>>> I do notice that while I see a lot of RECV: heartbeat debug messages on
>>> the
>>> client side, I don't see any SEND: messages that indicates it's sending
>>> them
>>> to server.   If the client is supposed to send them to the server
>>> periodically to ensure the connection stays alive, how can I ensure this
>>> is
>>> happening? (setting system property amqj.heartbeat.delay seems to have no
>>> effect).
>>>
>>> Thanks!
>>> Jen
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/timeouts-tp4256406p4256406.html
>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:      http://qpid.apache.org
>>> Use/Interact: mailto:[hidden email]
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[hidden email]
>>
>>
>>
>> ________________________________
>> View message @ http://n2.nabble.com/timeouts-tp4256406p4256885.html
>> To unsubscribe from timeouts, click here.
>>
>
> --
> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4257648.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>



--
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Jen Andre

I can't use the JMS API because of this bug:  http://old.nabble.com/-jira--Created:-(QPID-1875)-Can't-create-durable-queues-that-use-amq.topic-due-to-error-in-BindingURLParser.-td23726482.html.  I need to  create a durable queue bound to a topic.  If there some workaround let me know, I am happy to use the JMS API otherwise.
 
I was able to successfully build from trunk.  I changed nothing in my test program, but now I am no longer getting timeouts and I see the heartbeat replies in the log messages coming from my client:

2010-01-06 12:02:01,703 INFO  [Dispatcher-Channel-1] client.AMQSession$Dispatcher (AMQSession.java:2910) - Dispatcher-Channel-1 started
2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672] util.Logger (Logger.java:54) - RECV: [conn:1035079] ch=0 ConnectionHeartbeat()
2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672] util.Logger (Logger.java:54) - SEND: [conn:1035079] ch=0 ConnectionHeartbeat()
2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672] util.Logger (Logger.java:54) - FLUSH: [conn:1035079]


Something odd is happening -- I will try to narrow it down, since I want to use the 0.5 version if at all possible.

Rajith Attapattu wrote
On Tue, Jan 5, 2010 at 4:48 PM, Jen Andre <jandre@gmail.com> wrote:
>
> Yes, I am using both the c++ broker and the java library from 0.5.
>
> Setting the idle_timeout in the AMQP url doesn't seem affect anything.
>  I will try grabbing the latest from trunk as suggested by another
> user.
>
> I'm not sure which API I'm supposed to be using.  I tried both the
> code in  org.apache.qpid.client.* and  org.apache.qpid.transport.* and
> I get the same behavior.

You are supposed to use the JMS API.
The classes you are using right now are in the implementation layer
and are subject to change without any notice btw versions.


> Here some sample code.  Maybe you can tell me what I'm doing wrong

I cut paste your code and added an exception listener to the
connection and I didn't see any timeouts.

If I did a kill -STOP <broker-pid> then I saw a the client dropping
the connection after 120 secs.
 
Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Rajith Muditha Attapattu
On Wed, Jan 6, 2010 at 2:25 PM, Jen Andre <[hidden email]> wrote:
>
>
> I can't use the JMS API because of this bug:
> http://old.nabble.com/-jira--Created:-(QPID-1875)-Can't-create-durable-queues-that-use-amq.topic-due-to-error-in-BindingURLParser.-td23726482.html.
> I need to  create a durable queue bound to a topic.  If there some
> workaround let me know, I am happy to use the JMS API otherwise.

This is fixed in the upcomming 0.6 release.
I expect the release to be happening soon.

> I was able to successfully build from trunk.  I changed nothing in my test
> program, but now I am no longer getting timeouts and I see the heartbeat
> replies in the log messages coming from my client:

> 2010-01-06 12:02:01,703 INFO  [Dispatcher-Channel-1]
> client.AMQSession$Dispatcher (AMQSession.java:2910) - Dispatcher-Channel-1
> started
> 2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672]
> util.Logger (Logger.java:54) - RECV: [conn:1035079] ch=0
> ConnectionHeartbeat()
> 2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672]
> util.Logger (Logger.java:54) - SEND: [conn:1035079] ch=0
> ConnectionHeartbeat()
> 2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672]
> util.Logger (Logger.java:54) - FLUSH: [conn:1035079]
>
>
> Something odd is happening -- I will try to narrow it down, since I want to
> use the 0.5 version if at all possible.

The 0.5 release was was taken from rev 779632, while the proper
support for java client to echo heartbeats was added in rev 782633
So that explains why you didn't see it when you tried with the 0.5 release.
Could you test it out with the most recent RC for the 0.6 release?
We should be releasing that pretty soon.

>
> Rajith Attapattu wrote:
>>
>> On Tue, Jan 5, 2010 at 4:48 PM, Jen Andre <[hidden email]> wrote:
>>>
>>> Yes, I am using both the c++ broker and the java library from 0.5.
>>>
>>> Setting the idle_timeout in the AMQP url doesn't seem affect anything.
>>>  I will try grabbing the latest from trunk as suggested by another
>>> user.
>>>
>>> I'm not sure which API I'm supposed to be using.  I tried both the
>>> code in  org.apache.qpid.client.* and  org.apache.qpid.transport.* and
>>> I get the same behavior.
>>
>> You are supposed to use the JMS API.
>> The classes you are using right now are in the implementation layer
>> and are subject to change without any notice btw versions.
>>
>>
>>> Here some sample code.  Maybe you can tell me what I'm doing wrong
>>
>> I cut paste your code and added an exception listener to the
>> connection and I didn't see any timeouts.
>>
>> If I did a kill -STOP <broker-pid> then I saw a the client dropping
>> the connection after 120 secs.
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4262712.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[hidden email]
>
>



--
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Rajith Muditha Attapattu
In reply to this post by Rajith Muditha Attapattu
On Tue, Jan 5, 2010 at 2:30 PM, Rajith Attapattu <[hidden email]> wrote:

> Hello Jean,
>
> It appears that you are using the C++ broker and the java client.
> Could you confirm which version you are using?
>
> On Tue, Jan 5, 2010 at 12:47 PM, Jen Andre <[hidden email]> wrote:
>>
>> Hello,
>>
>> I have a Java client listener that subscribes to a topic and waits for
>> messages.  I'm noticing after 120 seconds of idle time  (no messages
>> received) the connections time out (here's what I see in syslog messages for
>> qpidd)
>>
>> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>>
>> This is consistent with the debug messages I'm seeing on the client side:
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
>> the connection, using the brokers max value 120
>>
>> and
>>
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>
>>
>> I'm a bit confused on how timeouts and heartbeats are supposed to work.
>> Does the client force the disconnect, or the server, or both, if the
>> heartbeats are not received in a specific period of time?
> Both the client and the broker could enforce a disconnect if they
> don't see any activity during two consecutive heartbeat intervals.
>
>  Do both peers
>> send heartbeats? (this seems to imply it does.
> Both peers do send a heartbeat.
> The JMS client (0-10 version which you are using against the c++
> broker) will echo a heartbeat in response to one sent by the broker.
>
>> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
> The link you provided is for the JMS Client (0-8 version) and the Java Broker.
> At the moment it's slightly different from JMS Client (0-10) and c++
> broker combination.
>
> The amqj.heartbeat.delay is only effective for the 0-8 codepath.
> If you need to set the idle timeout for the 0-10 client you need to
> set it in the broker URL as follows
>
> amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60''
> Please note the idle_timeout is in secs and not in milisecs.

Hi Jen,

I realized I made mistake here.
The idle_timeout is in milisecs and not in secs (I confused it with
the 0-8 client timeout which is in secs).
So if you put the timeout as 60, it would have been set to the brokers
default value of 120 secs.
I apologize for the mistake here and the correct URL should be
amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60000''

This is a bit ugly and it would be good if the timeouts are specified in secs.
I hope to change this behaviour in a future release by introducing a
property that will use secs.
The older idel_timeout property will remain for backwards compatibility

> We are working on consolidating the configuration and behaviour of the
> JMS client for both 0-8/9 and 0-10 versions.
>
>> I do notice that while I see a lot of RECV: heartbeat debug messages on the
>> client side, I don't see any SEND: messages that indicates it's sending them
>> to server.   If the client is supposed to send them to the server
>> periodically to ensure the connection stays alive, how can I ensure this is
>> happening? (setting system property amqj.heartbeat.delay seems to have no
>> effect).
>>
>> Thanks!
>> Jen
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4256406.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[hidden email]
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>



--
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

Martin Ritchie
In reply to this post by Jen Andre
2010/1/6 Jen Andre <[hidden email]>:
>
>
> I can't use the JMS API because of this bug:
> http://old.nabble.com/-jira--Created:-(QPID-1875)-Can't-create-durable-queues-that-use-amq.topic-due-to-error-in-BindingURLParser.-td23726482.html.
> I need to  create a durable queue bound to a topic.  If there some
> workaround let me know, I am happy to use the JMS API otherwise.

If you are wanting a durable queue bound to a topic then all you need
do is define your topic in JNDI
topic.JNDIName=TopicName

Then create a durable subscription:
session.createDurableSubscriber(topic,name)
The topic is the value retrieved from JNDI and name is a unique
identifier for your subscription.

There should be no need to define a custom URL in the JNDI property file.

Cheers

Martin

> I was able to successfully build from trunk.  I changed nothing in my test
> program, but now I am no longer getting timeouts and I see the heartbeat
> replies in the log messages coming from my client:
>
> 2010-01-06 12:02:01,703 INFO  [Dispatcher-Channel-1]
> client.AMQSession$Dispatcher (AMQSession.java:2910) - Dispatcher-Channel-1
> started
> 2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672]
> util.Logger (Logger.java:54) - RECV: [conn:1035079] ch=0
> ConnectionHeartbeat()
> 2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672]
> util.Logger (Logger.java:54) - SEND: [conn:1035079] ch=0
> ConnectionHeartbeat()
> 2010-01-06 12:04:00,829 DEBUG [IoReceiver - /192.168.10.128:5672]
> util.Logger (Logger.java:54) - FLUSH: [conn:1035079]
>
>
> Something odd is happening -- I will try to narrow it down, since I want to
> use the 0.5 version if at all possible.
>
>
> Rajith Attapattu wrote:
>>
>> On Tue, Jan 5, 2010 at 4:48 PM, Jen Andre <[hidden email]> wrote:
>>>
>>> Yes, I am using both the c++ broker and the java library from 0.5.
>>>
>>> Setting the idle_timeout in the AMQP url doesn't seem affect anything.
>>>  I will try grabbing the latest from trunk as suggested by another
>>> user.
>>>
>>> I'm not sure which API I'm supposed to be using.  I tried both the
>>> code in  org.apache.qpid.client.* and  org.apache.qpid.transport.* and
>>> I get the same behavior.
>>
>> You are supposed to use the JMS API.
>> The classes you are using right now are in the implementation layer
>> and are subject to change without any notice btw versions.
>>
>>
>>> Here some sample code.  Maybe you can tell me what I'm doing wrong
>>
>> I cut paste your code and added an exception listener to the
>> connection and I didn't see any timeouts.
>>
>> If I did a kill -STOP <broker-pid> then I saw a the client dropping
>> the connection after 120 secs.
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4262712.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[hidden email]
>
>



--
Martin Ritchie

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: timeouts

DA SILVA Antonio
In reply to this post by Rajith Muditha Attapattu

Hi all,

I have same prb with server c++ and client-010 dotnet.
After few seconds the connection is closed by the broker
if no messages are exchanged with him.

-C++ qpid broker 0.5 from release distrib,
-dotnet client-010 from trunk distrib.

Antonio.


Le 05/01/2010 20:30, Rajith Attapattu a écrit :

> Hello Jean,
>
> It appears that you are using the C++ broker and the java client.
> Could you confirm which version you are using?
>
> On Tue, Jan 5, 2010 at 12:47 PM, Jen Andre <[hidden email]> wrote:
>  
>> Hello,
>>
>> I have a Java client listener that subscribes to a topic and waits for
>> messages.  I'm noticing after 120 seconds of idle time  (no messages
>> received) the connections time out (here's what I see in syslog messages for
>> qpidd)
>>
>> qpidd[3472]: 2010-01-01 16:46:20 error Connection timed out: closing
>>
>> This is consistent with the debug messages I'm seeing on the client side:
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:32:10,126 WARN
>> [apache.qpid.transport.ClientDelegate] Ignoring the idle timeout 0 set by
>> the connection, using the brokers max value 120
>>
>> and
>>
>>
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:38:57,898 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:57,899 DEBUG
>> [apache.qpid.transport.Connection] RECV: [conn:9ced8e] ch=0
>> ConnectionHeartbeat()
>> IoReceiver - /192.168.10.128:5672 2010-01-05 12:40:58,618 DEBUG
>> [apache.qpid.transport.Connection] connection closed: conn:9ced8e
>>
>>
>> I'm a bit confused on how timeouts and heartbeats are supposed to work.
>> Does the client force the disconnect, or the server, or both, if the
>> heartbeats are not received in a specific period of time?
>>    
> Both the client and the broker could enforce a disconnect if they
> don't see any activity during two consecutive heartbeat intervals.
>
>  Do both peers
>  
>> send heartbeats? (this seems to imply it does.
>>    
> Both peers do send a heartbeat.
> The JMS client (0-10 version which you are using against the c++
> broker) will echo a heartbeat in response to one sent by the broker.
>
>  
>> http://qpid.apache.org/configure-broker-and-client-heartbeating.html).
>>    
> The link you provided is for the JMS Client (0-8 version) and the Java Broker.
> At the moment it's slightly different from JMS Client (0-10) and c++
> broker combination.
>
> The amqj.heartbeat.delay is only effective for the 0-8 codepath.
> If you need to set the idle timeout for the 0-10 client you need to
> set it in the broker URL as follows
>
> amqp:///test?brokerlist='tcp://anotherhost:5684?idle_timeout='60''
> Please note the idle_timeout is in secs and not in milisecs.
>
> We are working on consolidating the configuration and behaviour of the
> JMS client for both 0-8/9 and 0-10 versions.
>
>  
>> I do notice that while I see a lot of RECV: heartbeat debug messages on the
>> client side, I don't see any SEND: messages that indicates it's sending them
>> to server.   If the client is supposed to send them to the server
>> periodically to ensure the connection stays alive, how can I ensure this is
>> happening? (setting system property amqj.heartbeat.delay seems to have no
>> effect).
>>
>> Thanks!
>> Jen
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://n2.nabble.com/timeouts-tp4256406p4256406.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[hidden email]
>>
>>
>>    
>
>
>  


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[hidden email]