Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Hi. I've a suspicion is that this is the same underlying cause as #1928 (an issue I'd only seen on one machine in a particular situation, so I'd classified it non-critical). But I don't think I can look at this current trace properly this week - i.e. to try to make find a definite sequence that gives this current trace to make a stronger claim. The idea is that in this case the Stream receives a read+write event, and both the read and the write trigger error handling. Either the stream is queued twice for reconnection by a StreamConnectorTask, or reconnected and also queued (once) via StreamConnectorTask.
(For issue #1928 itself I was preparing a patch for that (PR#1934), but had a idea to rework that using a different approach, which is why I'd held that one back in draft state. i.e. change it to add return codes to the handlers, OnTLSHandShake, OnRead, OnReadWhileHandshaking, OnReadTimeout etc rather than changing the poller).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1