qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Praveen Bodke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PROTON-1890) [c++] implement idle_timeout and heartbeats
Date Wed, 11 Jul 2018 18:26:01 GMT

    [ https://issues.apache.org/jira/browse/PROTON-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540489#comment-16540489
] 

Praveen Bodke commented on PROTON-1890:
---------------------------------------

Thank you Robbie Gemmell for clarifying the heartbeat information. We really appreciate that. As
you pointed out "improper usage if it ties up the container thread", this was the real issue
in sample program.  Thanks for that.

I have modified the program to have a different thread to send messages to a queue and the
proton container thread to read from the queue only if it has a sufficient credit available. With
this change, the proton is working great and detecting the idle-time-out expiry.

Can you also clarify if there are any plans to improve the proton container to have a separate
thread to listen for all the underlying proton errors and inform the application to close
if necessary? 

---------------------

I am detailing the information about my test in case if some one is interested.

Steps to reproduce: 

The test scenario is to check if the proton application is timesout if it did not hear from
the peer

1. Two peers P1 (scheduled_send_03) and P2 (scheduled_send_03) have established the connection
properly

    Following is the Frame information. (P1 idle time out is 30 seconds and P2 idle time
out is 30 seconds)

   The advertised idle_time_out in open frame is generally half of the configured idle time
out.

 

[0x89873d0]:  -> AMQP

[0x89873d0]:0 -> @open(16) [container-id="a578196f-c4c1-415a-a055-032dc91b1635", hostname="X.X.X.X",
channel-max=32767, idle-time-out=15000]

[0x89873d0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]

[0x89873d0]:0 -> @attach(18) [name="8dc9567d-6840-4e03-931e-cd2df90b6378", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [address="example", durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]

[0x89873d0]:  <- AMQP

[0x89873d0]:0 <- @open(16) [container-id="2a746915-26a9-4d33-ba7d-a2586d8a5452", channel-max=32767,
idle-time-out=15000]

[0x89873d0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]

[0x89873d0]:0 <- @attach(18) [name="8dc9567d-6840-4e03-931e-cd2df90b6378", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]

[0x89873d0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, drain=false]

 

P1 Netstat

----------

netstat -apn | grep 1239

tcp      116      0 X.X.X.X:48132           X.X.X.X:1239            ESTABLISHED
32682/./scheduled_s

 

2. enabled the traffic rule to drop the messages from both P1 and P2 interfaces

3. P1 is sending data messages continuously in a while loop

4. No packets arrived at P2, so P2 started sending empty frames. P2 detected the idle-time-out
error and closed the connection. Note that messages from P2 is not reaching P1.

 

server listening on X.X.X.X:1239/examples

[0x130d360]:  <- AMQP

[0x130d360]:0 <- @open(16) [container-id="a578196f-c4c1-415a-a055-032dc91b1635", hostname="X.X.X.X",
channel-max=32767, idle-time-out=15000]

[0x130d360]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]

[0x130d360]:0 <- @attach(18) [name="8dc9567d-6840-4e03-931e-cd2df90b6378", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [address="example", durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]

[0x130d360]:  -> AMQP

[0x130d360]:0 -> @open(16) [container-id="2a746915-26a9-4d33-ba7d-a2586d8a5452", channel-max=32767,
idle-time-out=15000]

[0x130d360]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]

[0x130d360]:0 -> @attach(18) [name="8dc9567d-6840-4e03-931e-cd2df90b6378", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]

[0x130d360]:0 -> @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, drain=false]

[0x130d360]:0 -> (EMPTY FRAME)

[0x130d360]:0 -> (EMPTY FRAME)

[0x130d360]:0 -> (EMPTY FRAME)

[0x130d360]:0 -> @close(24) [error=@error(29) [condition=:"amqp:resource-limit-exceeded",
description="local-idle-timeout expired"]]

[0x130d360]:  -> EOS

amqp:resource-limit-exceeded: local-idle-timeout expired

 

5. P1 tcp is in still ESTABLISHED state

netstat -apn | grep 1239

tcp        8      0 X.X.X.X:48132           X.X.X.X:1239           
ESTABLISHED 32682/./scheduled_se

 

 P1 is still sending messages without realizing that the underlying socket on the other end
is closed. proton layer is  not throwing on_transport_error callback.

> [c++] implement idle_timeout and heartbeats
> -------------------------------------------
>
>                 Key: PROTON-1890
>                 URL: https://issues.apache.org/jira/browse/PROTON-1890
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: cpp-binding
>    Affects Versions: 0.16.0
>            Reporter: Praveen Bodke
>            Priority: Major
>
> This is similar issue reported in PROTON-1782 for ruby. 
> We are facing this issue in cpp binding and i am able to reproduce the issue with scheduled_send_03.cpp
example. The test scenario is to drop all the packets from both the interfaces after the successful
connection. The only change i made to this example is to send messages continuously inside
the send() method. The other end is detecting the error as it is sending the empty frames
and no response is heard.
> The proton is not sending the heartbeat messages (empty frames) as the sender is busy
in sending the data frames. Is it not necessary to send empty frames even if the data frames
are sent?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message