[
https://issues.apache.org/jira/browse/PROTON-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752818#comment-17752818
]
Clifford Jansen commented on PROTON-2748:
-----------------------------------------
This is the proposed behaviour for normal operation and asynchronous network
errors.
In normal operation the application may suspend/resume activity on a raw
connection by withholding/supplying read and raw buffers as desired. In the
absence of network errors, pending input bytes will be available for read
before the CLOSED_READ event and pending output bytes will be sent before a
CLOSED_WRITE event.
READ and READ_CLOSED activity will not be polled/requested of the OS by the raw
connection in the absence of read buffers. If there are no queued output
buffers for writing, the raw connection will be suspended until a future
pn_raw_connection_wake() or network error.
Async disconnect (RST) is always immediately detected and leads to DISCONNECTED
state and subsequent resource cleanup including close of the underlying socket
without further blocking.
pn_raw_connection_close() results in progression to DISCONNECTED state without
blocking (including resource cleanup). In particular, no acknowledgment of the
close operation is required or expected from the peer and the TCP connection is
cleaned up by the operating system according to its configured SO_LINGER policy.
> Raw connections do not always complete close operations
> -------------------------------------------------------
>
> Key: PROTON-2748
> URL: https://issues.apache.org/jira/browse/PROTON-2748
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: proton-c-0.39.0
> Environment: linux epoll
> Reporter: Clifford Jansen
> Assignee: Clifford Jansen
> Priority: Major
> Attachments: pn2748.patch
>
>
> The Proton raw_connection_t currently requires cooperation from the
> application layer to complete a close. There is a baked in assumption that
> the application will always eventually provide a read buffer. A second
> assumption is that the peer (not necessarily a Proton raw connection) will
> detect a read close on its side, and do a graceful close of it's write side
> "soon".
> These incorrect assumptions can leave the raw connection in a hung state
> waiting for non-existent wind up activity by the application or peer,
> respectively.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
