[
https://issues.apache.org/jira/browse/PROTON-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763236#comment-17763236
]
ASF GitHub Bot commented on PROTON-2748:
----------------------------------------
cliffjansen commented on code in PR #402:
URL: https://github.com/apache/qpid-proton/pull/402#discussion_r1320279795
##########
c/src/proactor/epoll_raw_connection.c:
##########
@@ -304,7 +305,7 @@ void pn_raw_connection_write_close(pn_raw_connection_t *rc)
{
pni_raw_write_close(rc);
}
-static pn_event_t *pni_raw_batch_next(pn_event_batch_t *batch) {
+static pn_event_t *pni_epoll_raw_batch_next(pn_event_batch_t *batch, bool
peek_only) {
Review Comment:
pni_raw_batch_has_events() was used as suggested elsewhere.
> 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
