[
https://issues.apache.org/jira/browse/PROTON-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763244#comment-17763244
]
ASF GitHub Bot commented on PROTON-2748:
----------------------------------------
cliffjansen commented on code in PR #402:
URL: https://github.com/apache/qpid-proton/pull/402#discussion_r1320289915
##########
c/src/proactor/epoll_raw_connection.c:
##########
@@ -318,12 +319,18 @@ static pn_event_t *pni_raw_batch_next(pn_event_batch_t
*batch) {
unlock(&rc->task.mutex);
if (waking) pni_raw_wake(raw);
- pn_event_t *e = pni_raw_event_next(raw);
- if (!e || pn_event_type(e) == PN_RAW_CONNECTION_DISCONNECTED)
- rc->batch_empty = true;
Review Comment:
This logic was solely there to identify edge cases where the epoll-specific
code could not be sure if the state machine was up to date. In which case a
non-application call to pni_raw_batch_next() would update the state machine but
a resulting event would have to be put back into the collector.
The new pni_raw_batch_has_events() updates the state machine and has no side
effects to the event stream, so the check for batch_empty is no longer needed.
> 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
