[
https://issues.apache.org/jira/browse/PROTON-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541345#comment-16541345
]
Praveen Bodke commented on PROTON-1890:
---------------------------------------
Hello Robbie Gemmell,
With some modifications to credit window, now i am able to reproduce the issue.
Attaching the modified scheduled_send_03.cpp and server_direct.cpp programs.
Please let me know if you need any more information. I would be happy to
provide you.
Let me go through the scenario here.
STEP 1:
Two peers P1 and P2 have established the connection and following are the frame
information.
server listening on <P1-IP>:1239/examples
[0x225f360]: <- AMQP
[0x225f360]:0 <- @open(16)
[container-id="b3d1fa29-84eb-4c1e-bd1e-2a11123b2a64", hostname="10.1.14.102",
channel-max=32767, idle-time-out=15000]
[0x225f360]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x225f360]:0 <- @attach(18) [name="2b590c4a-e237-4522-81f1-8442f2f40844",
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]
[0x225f360]: -> AMQP
[0x225f360]:0 -> @open(16)
[container-id="816b5f5c-4b6d-4e50-8a3e-096963ec5e26", channel-max=32767,
idle-time-out=10000]
[0x225f360]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]
[0x225f360]:0 -> @attach(18) [name="2b590c4a-e237-4522-81f1-8442f2f40844",
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]
[0x225f360]:0 -> @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
link-credit=100, drain=false]
[0x225f360]:0 <- @attach(18) [name="2430291c-75ac-4a22-9e6d-dc5e179df431",
handle=1, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="X.X.X.X:1239/example", durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=0]
[0x225f360]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=1, delivery-count=0,
link-credit=200, drain=false]
P1 receiver credit window is set to 200, this means the P2 sender credit limit
is 200.
[0x225f360]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=1, delivery-count=0,
link-credit=200, drain=false]
P2 receiver credit window is set to 100
[0x225f360]:0 -> @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
link-credit=100, drain=false]
STEP 2:
P2 sends the messages continuously.. during this time frame, we drop all the
packets between two peers.
STEP 3:
P1 detects the idle-time-out expiry after sending the some empty frames.
[0x1a36360]:0 -> @flow(19) [next-incoming-id=2000, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=2000,
link-credit=100, drain=false]
[0x1a36360]:0 -> @disposition(21) [role=true, first=1958, last=1999,
settled=true, state=@accepted(36) []]
[0x1a36360]:0 -> (EMPTY FRAME)
[0x1a36360]:0 -> (EMPTY FRAME)
[0x1a36360]:0 -> @close(24) [error=@error(29)
[condition=:"amqp:resource-limit-exceeded", description="local-idle-timeout
expired"]]
[0x1a36360]: -> EOS
amqp:resource-limit-exceeded: local-idle-timeout expired
STEP 4:
P2 still in ESTABLISHED state and never disconnects.
[^PROTON-1890.zip]
> [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
> Attachments: PROTON-1890.zip
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
