ChugR commented on a change in pull request #1129:
URL: https://github.com/apache/qpid-dispatch/pull/1129#discussion_r615061225
##########
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:
I disagree. This code patch is trying to fix DISPATCH-1878 where a
client sends data and closes the connection. The expectation is that the data
gets sent over the wire to where it's going and the propagates the close after
that. Any data will sent by the server will come back to the client. Then when
the server closes that close will be propagated to the client.
A tcpListener READ_CLOSED event must be propagated to the peer tcpConnector
as a write_close() control. Then the connector READ_CLOSE event becomes the
listener write_close() control.
Short circuiting that control flow will lose data.
--
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
