[
https://issues.apache.org/jira/browse/DISPATCH-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324064#comment-17324064
]
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_r615103944
##########
File path: src/adaptors/tcp_adaptor.c
##########
@@ -288,18 +338,87 @@ static int handle_incoming_impl(qdr_tcp_connection_t
*conn, bool close_pending)
qd_message_set_q2_unblocked_handler(msg, qdr_tcp_q2_unblocked_handler,
conn_sp);
conn->instream = qdr_link_deliver(conn->incoming, msg, 0, false, 0, 0,
0, 0);
- qd_log(tcp_adaptor->log_source, QD_LOG_DEBUG,
"[C%"PRIu64"][L%"PRIu64"] Initiating message with %i bytes", conn->conn_id,
conn->incoming_id, count);
+ qd_log(log, QD_LOG_DEBUG,
+ "[C%"PRIu64"][L%"PRIu64"][D%"PRIu64"] Initiating ingress stream
message with %u bytes",
+ conn->conn_id, conn->incoming_id, conn->instream->delivery_id,
length);
+ conn->incoming_started = true;
+
+ // Handle deferment of write side close.
+ sys_mutex_lock(conn->activation_lock);
+ if (conn->read_eos_seen && !conn->raw_closed_write) {
+ // to-raw-conn EOS was seen before the from-raw-conn instream
delivery existed.
Review comment:
From a trace the other day.
```
TCP Adaptor half-closed hang after 1500 connections
on the server side connection [C3110] is tcpConnector connection:
* connection opens
* client data 5 bytes is written
* client connection stream to server is closed (EOS)
* server connection does WRITE_CLOSE (same as original client does
open-write-close to tcpListener)
* server replies with 21 bytes
* server caches the 21 bytes since "Waiting for credit before initiating
ingress stream message"
there's no message to put the bytes into yet
* server application closes after writing the 21 byte reply
* with server connection WRITE_CLOSED and READ_CLOSED the
CONNECTION_DISCONNECTED comes along
* handle_disconnected tears everything down and the cached bytes never get
written into stream message
* There's a bug since the server connection should stay up long enough to
write the cached bytes to the stream message
TCP_ADAPTOR (debug) [C3110][L6219] (server outgoing) Created link to
amqp:/_topo/0/D-1878/temp.RHkTIA2kerAComs
TCP_ADAPTOR (trace) [C3110] handle_incoming qdr_tcp_deliver for server
connection. read_closed:F, flow_enabled:F
TCP_ADAPTOR (debug) [C3110][L6218] Waiting for credit before initiating
ingress stream message
TCP_ADAPTOR (debug) [C3110] pn_raw_connection_write_buffers wrote 5 bytes
TCP_ADAPTOR (info) [C3110] EOS
here the adaptor calls write_close() to server connection when EOS is
seen
TCP_ADAPTOR (debug) [C3110] handle_outgoing calling
pn_raw_connection_write_close(). rcv_complete:T, send_complete:T
TCP_ADAPTOR (debug) [C3110][L6218] qdr_tcp_offer: NOOP
TCP_ADAPTOR (debug) [C3110][L6218] qdr_tcp_get_credit: NOOP
TCP_ADAPTOR (debug) [C3110][L6218] (server outgoing) qdr_tcp_second_attach
TCP_ADAPTOR (debug) [C3110][L6218] qdr_tcp_get_credit: NOOP
TCP_ADAPTOR (debug) [C3110] PN_RAW_CONNECTION_CLOSED_WRITE
adaptor connector to server is now write closed
TCP_ADAPTOR (debug) [C3110] PN_RAW_CONNECTION_WRITTEN
pn_raw_connection_take_written_buffers wrote 5 bytes. Total written 5 bytes
TCP_ADAPTOR (debug) [C3110] pn_raw_connection_take_read_buffers() took 1,
freed 0
TCP_ADAPTOR (debug) [C3110] PN_RAW_CONNECTION_READ Read 21 bytes. Total read
21 bytes
TCP_ADAPTOR (debug) [C3110] PN_RAW_CONNECTION_READ Read 0 bytes. Total read
21 bytes
server echos the 5 bytes with a prefix to make it 21 bytes. Then server
closes connection.
TCP_ADAPTOR (debug) [C3110][L6219] PN_RAW_CONNECTION_CLOSED_READ
TCP_ADAPTOR (trace) [C3110] handle_incoming PNRC_CLOSED_READ for server
connection. read_closed:T, flow_enabled:F
adaptor still has no place to put the 21 bytes
TCP_ADAPTOR (debug) [C3110][L6218] Waiting for credit before initiating
ingress stream message
raw connection is write- and read-closed. it shuts down and the 21 bytes
never went to tcpListener client
TCP_ADAPTOR (info) [C3110] PN_RAW_CONNECTION_DISCONNECTED
TCP_ADAPTOR (debug) [C3110][L6218] handle_disconnected - close outstream
TCP_ADAPTOR (debug) [C3110][L6219] handle_disconnected - detach incoming
TCP_ADAPTOR (debug) [C3110][L6218] handle_disconnected - detach outgoing
TCP_ADAPTOR (debug) qdr_tcp_activate: no connection context
TCP_ADAPTOR (debug) [C3110] qdr_add_tcp_connection_CT 127.0.0.1:9090 (2)
TCP_ADAPTOR (debug) [C3110] qdr_del_tcp_connection_CT 127.0.0.1:9090
deleted. bytes_in=21, bytes_out=5, opened_time=28, last_in_time=28,
last_out_time=28. Connections remaining 1
```
--
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:
[email protected]
> 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: [email protected]
For additional commands, e-mail: [email protected]
