[
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
