grs commented on a change in pull request #1129:
URL: https://github.com/apache/qpid-dispatch/pull/1129#discussion_r615073245
##########
File path: src/adaptors/tcp_adaptor.c
##########
@@ -1257,13 +1489,17 @@ static void qdr_tcp_delivery_update(void *context,
qdr_delivery_t *dlv, uint64_t
void* link_context = qdr_link_get_context(qdr_delivery_link(dlv));
if (link_context) {
qdr_tcp_connection_t* tc = (qdr_tcp_connection_t*) link_context;
- qd_log(tcp_adaptor->log_source, QD_LOG_DEBUG, DLV_FMT"
qdr_tcp_delivery_update: disp: %"PRIu64", settled: %s",
+ qd_log(tcp_adaptor->log_source, QD_LOG_DEBUG,
+ DLV_FMT" qdr_tcp_delivery_update: disp: %"PRIu64", settled: %s",
DLV_ARGS(dlv), disp, settled ? "true" : "false");
//
// If one of the streaming deliveries is ever settled, the connection
must be torn down.
Review comment:
That is exactly my point. The same is true for the other direction, a
tcpListener CLOSED_WRITE should be propagated to the peer tcpConnector where it
will call read_close(). The CLOSED_WRITE at the tcpConnector will be propagated
to the tcpListener for it to call read_close(). Read and write streams are
chained in both directions.
I argue that the comment above is actually short circuiting this (as it
predates the API to handle read_close()/write_close() separately). Though it
may work for the ncat case, that short circuiting seems less clean than a
proper symmetric chaining.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
