You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2018/11/27 17:15:00 UTC
[jira] [Commented] (QPIDJMS-435) Failover reconnection fails when
using Azure Sas token authentication
[ https://issues.apache.org/jira/browse/QPIDJMS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700737#comment-16700737 ]
Timothy Bish commented on QPIDJMS-435:
--------------------------------------
This isn't a bug in the JMS client. You are using a non-standard means of authentication which conflicts with how the JMS client operates and as such will need to work out some means of handling this case. It may come down to needing to handle connection drops yourself and tearing down and rebuilding the JMS resources yourself instead of using the failover features. The failover mechanism is doing exactly what it was designed to do which is to recover and recreate all the JMS resources transparently.
> Failover reconnection fails when using Azure Sas token authentication
> ---------------------------------------------------------------------
>
> Key: QPIDJMS-435
> URL: https://issues.apache.org/jira/browse/QPIDJMS-435
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.37.0
> Reporter: David De Franco
> Priority: Major
> Attachments: log.txt
>
>
> For authenticating connections with the Azure Service Bus we use sasl mechanism ANONYMOUS. After a connection is opened, before any other activity, we send a sas token to a special queue. This works fine as long as the connection is not remotely closed.
> When the connection is remotely closed it cannot be restored by the FailoverProvider because of recovery of an active session on the connection. When the session is recovered it starts listening on an unauthenticated connection.
> This also prevents re-authenticating the connection by sending the sas token again. See attached log.
> Is it possible to prevent the recovery of the session? We already moved the re-authentication after the try-with-resources statement where the session is created. This way we assumed the session would be closed, preventing recovery.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org