[ 
https://issues.apache.org/jira/browse/DISPATCH-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324027#comment-17324027
 ] 

ASF GitHub Bot commented on DISPATCH-1878:
------------------------------------------

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


> Client app not getting a response through tcpListener
> -----------------------------------------------------
>
>                 Key: DISPATCH-1878
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-1878
>             Project: Qpid Dispatch
>          Issue Type: Bug
>          Components: Protocol Adaptors
>    Affects Versions: 2.0.0
>            Reporter: Fernando Giorgetti
>            Assignee: Charles E. Rolke
>            Priority: Major
>         Attachments: D-1878 @e148c.svg, 
> DISPATCH-1878_fail-pn-raw-closed-before-ingress-stream-set-up.svg, 
> dispatch-1878-trace.html
>
>
> I have a tcp-echo server running locally through:
> podman run -d --rm --name tcpecho -p 9090:9090 quay.io/skupper/tcp-go-echo
> And I have a router configured with a tcpConnector to localhost at port 9090 
> and a tcpListener at port 9999.
> I am able to use nc (netcat) to send data to the tcp-echo directly (port 
> 9090) or through
> the router (port 9999), if I run "nc 127.0.0.1 9999" and the send the data.
> But if I run it as:  "echo abcd | nc 127.0.0.1 9999" I am not seeing a 
> response, but if 
> I use port 9090 (original port) instead of 9999 (router tcpListener), then I 
> get the
> response correctly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to