[
https://issues.apache.org/jira/browse/AMQNET-572?focusedWorklogId=542605&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-542605
]
ASF GitHub Bot logged work on AMQNET-572:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 27/Jan/21 03:30
Start Date: 27/Jan/21 03:30
Worklog Time Spent: 10m
Work Description: brudo commented on pull request #3:
URL:
https://github.com/apache/activemq-nms-openwire/pull/3#issuecomment-767996287
[ThreadStatic] does ensure that each thread gets its own copy; but if it is
accessed from a thread pool, it will be initialized and reused there too, which
might create hard-to-find problems. I'll try to understand what it was
originally meant to accomplish, and see if there's another way (even if
slightly higher run-time cost).
Actually, chasing down through the code, it seems that FailoverTransport is
probably running a dedicated thread - unless client code has changed
TaskRunnerFactor.DefaultTaskRunnerFactory.dedicatedTaskRunner from the default
of true. I wonder if the use of [ThreadStatic] makes an assumption that it will
_always_ be dedicated.
It does look like I might need to do a separate PR anyway, so that I can
rebase without having to force-push. But based on review, I'm no longer
convinced that it's a quick case of reconcile conflicts and done.
Meanwhile, I could revert my merge commit from this branch as well, since it
caused a bad diff, with the whole FailoverTransport.cs appearing as a change -
the original conflict was arguably better!
A unit test for this functionality would require an SSL-configured broker to
test against, or possibly a few different SSL-configured brokers with different
protocols. I don't see any SSL-related unit tests at all.
----------------------------------------------------------------
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]
Issue Time Tracking
-------------------
Worklog Id: (was: 542605)
Time Spent: 4h 20m (was: 4h 10m)
> Failover crashes when AMQ Server enforces TLS 1.2
> -------------------------------------------------
>
> Key: AMQNET-572
> URL: https://issues.apache.org/jira/browse/AMQNET-572
> Project: ActiveMQ .Net
> Issue Type: Bug
> Reporter: Dan Taflin
> Priority: Critical
> Attachments: Archivos-1.zip, failoverSslContext.patch
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> When using the FailoverTransport with underlying SslTransports, and
> specifying Tls12 as the SslProtocol, the initial connection to the ActiveMQ
> server succeeds in establishing a TLS v1.2 session. But upon failover, when
> it tries to reconnect, the Tls12 specification is lost and the NMS client
> reverts to the default, which appears to be TLS 1.0.
> The consequence is that it is impossible to enforce TLS 1.2 on the server,
> because although the initial connection would succeed, subsequent ones crash
> the client.
> Here's a sample failover transport URL:
> {{failover:(ssl://server1.example.com:61616?transport.sslProtocol=Tls12,ssl://server2.example.com:61616?transport.sslProtocol=Tls12)}}
> I've traced the issue to the FailoverTransport.DoConnect() method, which,
> when obtaining the ConnectList in order to obtain a url to connect to,
> obtains a url without a querystring. So in the above example,
> transport.sslProtocol=Tls12 is gone. The source of this truncated url is the
> ConnectionControl command marshalled from the server.
> The solution would seem to be to create an SslContext class to keep track of
> the sslProtocol, similar to how the java version works. I have built a
> working prototype for us to use locally and would be willing to make it
> available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
