[ 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org