[
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: [email protected]
For additional commands, e-mail: [email protected]
