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

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

Update:

After analyzing the proton frame logs at sender application P2 side, we 
observed that the proton is able to detect the idle-time-out expiry and sending 
a CLOSE frame to P1. But the CLOSE frame is not reached to P1 (due to the fact 
that this scenario is dropping all the packets between P1 and P2 interface to 
simulate the bad network) and eventually it is not letting the application 
layer know about this error until it receives EOS frame happens after the TCP 
re-transmission timeout  (after ~16 minutes). 

The time gap between the following two FRAME logs is about ~16 minutes which is 
in line with TCP re-transmission timeout in our environment. 

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

[0x8c4ea60]:  <- EOS
amqp:resource-limit-exceeded: local-idle-timeout expired (connection aborted)

I believe the proton library should handle such scenario in which if the CLOSE 
frame is sent due to idle-time-out error, it should trigger the 
on_transport_error callback to the handler. 

Please let me know your thoughts on this. 

Thanks.
Praveen Bodke 

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

Reply via email to