You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by hildo <ed...@gmail.com> on 2018/06/23 04:06:59 UTC
Unable to listen to topic subscriptions with the same name
Hi. I am experiencing some unexpected behavior and I was wondering if anyone
here can shed some light on it. I have a sample application that can show
what I'm talking about. It can be accessed at this github repo
<https://github.com/hildo/azureSamples/tree/multipleTopics> (the
multipleTopics branch)
I have a Spring Boot application (app1 in the file structure) that listeners
to two Topics in Azure Service Bus: mytopic and myothertopc. Both topics
have a single subscription called TopicReceiver. So, there are two
Subscriptions over all and they share the same name, but for different
Topics. So, there is mytopic:TopicReceiver and myothertopic:TopicReceiver
When I attempt to listen to these subscriptions, only one listener
successfully connects. The other receives repeating error messages....
2018-06-23 13:47:00.120 INFO 24556 --- [windows.net:-1]]
org.apache.qpid.jms.JmsConnection : Connection
ID:fdf7a327-9378-4d30-836e-35f3da5d48fb:1 connected to remote Broker:
amqps://azuresamples-hillmep.servicebus.windows.net?amqp.idleTimeout=3600000
2018-06-23 13:47:00.120 INFO 24556 --- [ main]
o.s.j.c.CachingConnectionFactory : Established shared JMS
Connection: org.apache.qpid.jms.JmsConnection@129bc99
2018-06-23 13:47:00.176 INFO 24556 --- [ main]
o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080
(http) with context path ''
2018-06-23 13:47:00.182 INFO 24556 --- [ main]
azure.example.app1.Application : Started Application in 9.22
seconds (JVM running for 15.104)
2018-06-23 13:47:01.429 WARN 24556 --- [windows.net:-1]]
o.a.q.j.p.a.b.AmqpResourceBuilder : Open of
resource:(JmsConsumerInfo: { ID:fdf7a327-9378-4d30-836e-35f3da5d48fb:1:1:1,
destination = myothertopic }) failed: Cannot open a Topic client for entity
type Subscriber. TrackingId:720e7137-67c6-44fb-9b4d-e419be664544_B14,
SystemTracker:azuresamples-hillmep:topic:myothertopic~15|TopicReceiver,
Timestamp:6/23/2018 3:47:00 AM
TrackingId:8946c6d0ff674853ba2079b07f520046_G41, SystemTracker:gateway7,
Timestamp:6/23/2018 3:47:00 AM [condition = amqp:not-allowed]
2018-06-23 13:47:05.581 WARN 24556 --- [enerContainer-1]
o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
invoker failed for destination 'mytopic' - trying to recover. Cause: A
non-shared durable subscription is already active with name 'TopicReceiver'
2018-06-23 13:47:05.585 INFO 24556 --- [enerContainer-1]
o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
Connection
2018-06-23 13:47:06.654 WARN 24556 --- [enerContainer-1]
o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
invoker failed for destination 'myothertopic' - trying to recover. Cause:
Cannot open a Topic client for entity type Subscriber.
TrackingId:720e7137-67c6-44fb-9b4d-e419be664544_B14,
SystemTracker:azuresamples-hillmep:topic:myothertopic~15|TopicReceiver,
Timestamp:6/23/2018 3:47:00 AM
TrackingId:8946c6d0ff674853ba2079b07f520046_G41, SystemTracker:gateway7,
Timestamp:6/23/2018 3:47:00 AM [condition = amqp:not-allowed]
2018-06-23 13:47:06.654 INFO 24556 --- [enerContainer-1]
o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
Connection
2018-06-23 13:47:11.979 WARN 24556 --- [enerContainer-2]
o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
invoker failed for destination 'myothertopic' - trying to recover. Cause: A
non-shared durable subscription is already active with name 'TopicReceiver'
2018-06-23 13:47:11.980 INFO 24556 --- [enerContainer-2]
o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
Connection
2018-06-23 13:47:16.995 WARN 24556 --- [enerContainer-3]
o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
invoker failed for destination 'myothertopic' - trying to recover. Cause: A
non-shared durable subscription is already active with name 'TopicReceiver'
2018-06-23 13:47:16.996 INFO 24556 --- [enerContainer-3]
o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
Connection
^C2018-06-23 13:47:18.278 INFO 24556 --- [ Thread-4]
ConfigServletWebServerApplicationContext : Closing
org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@dc8451:
startup date [Sat Jun 23 13:46:51 AEST 2018]; root of context hierarchy
2
If I change either of the subscription names to something else, it all works
correctly. But it behaves like subscription names have to be unique
regardless of the topic against which have been created. If I only have the
single listener in the app, I don't see any error either.
This behavior didn't occur in 0.11.0 of the JMS library. It started at
0.20.0 and continues to the current version.
Is this a bug or is this expected behavior? Thanks for any info
Ed
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Unable to listen to topic subscriptions with the same name
Posted by Robbie Gemmell <ro...@gmail.com>.
On 23 June 2018 at 12:23, hildo <ed...@gmail.com> wrote:
> Thanks for that feedback. For my part, a point of frustration is that we're
> using this with Azure Service Bus and (unless this has changed?) we have to
> use durable subscriptions in order to receive messages from a Service Bus
> topic. None of these are shared subscriptions. I would prefer if I could
> just have non-durable subscriptions, allowing the consumers to setup / tear
> down their subscriptions dynamically, but Service Bus doesn't support that.
> Unless that's changed?
>
I'll need to direct you to Microsoft for questions about their products.
> The subscription name per client id seems to be limited to the client's JVM?
> We would have a number of topics across a number of applications which use
> the same subscription name and client ids against different topics and we're
> able to connect. However, that information is useful and I can ensure that
> the client ids can be made distinct to defend against that.
>
> Thanks for the information. It was very helpful.
>
The clients local checking is done per-connection, as you are only
allowed a single connection with a given ClientID in JMS. The client
sets the AMQP connection container-id to the provided ClientID, and
adds some information to request that the server gives it sole use of
this container-id or fail. This is a layered extension the JMS client
and various servers use, one which it sounds like Service Bus doesnt
support and so is letting you use different connections with the same
container-id. The client does not currently refuse to connect to such
servers, but it does mean you are outside JMS behaviour at that point
with those servers.
You shouldnt be using links with the same name ( the link is named
based on the subscription) on different connections with the same
container-id between two given peers in any case, thats actually
outside the AMQP spec.
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Unable to listen to topic subscriptions with the same name
Posted by hildo <ed...@gmail.com>.
Thanks for that feedback. For my part, a point of frustration is that we're
using this with Azure Service Bus and (unless this has changed?) we have to
use durable subscriptions in order to receive messages from a Service Bus
topic. None of these are shared subscriptions. I would prefer if I could
just have non-durable subscriptions, allowing the consumers to setup / tear
down their subscriptions dynamically, but Service Bus doesn't support that.
Unless that's changed?
The subscription name per client id seems to be limited to the client's JVM?
We would have a number of topics across a number of applications which use
the same subscription name and client ids against different topics and we're
able to connect. However, that information is useful and I can ensure that
the client ids can be made distinct to defend against that.
Thanks for the information. It was very helpful.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Unable to listen to topic subscriptions with the same name
Posted by Robbie Gemmell <ro...@gmail.com>.
For each given ClientID you are only allowed one durable subscription
with a particular name in JMS. The names are scoped per-ClientID, not
per-Topic. In particular, if there is an 'active' non-shared durable
subscriber using a given subscription name on the connection,
attempting to create another subscriber for that name should fail.
That seems to be what is happening here.
The 0.20.0 client onwards implemented JMS 2.0 and the additional
handling around shared subscriptions required that the client much
more closely validate the JMS subscription semantics, e.g you also
cant have a shared durable subscription with the same name as a
non-shared durable subscription.
On 23 June 2018 at 05:06, hildo <ed...@gmail.com> wrote:
> Hi. I am experiencing some unexpected behavior and I was wondering if anyone
> here can shed some light on it. I have a sample application that can show
> what I'm talking about. It can be accessed at this github repo
> <https://github.com/hildo/azureSamples/tree/multipleTopics> (the
> multipleTopics branch)
>
> I have a Spring Boot application (app1 in the file structure) that listeners
> to two Topics in Azure Service Bus: mytopic and myothertopc. Both topics
> have a single subscription called TopicReceiver. So, there are two
> Subscriptions over all and they share the same name, but for different
> Topics. So, there is mytopic:TopicReceiver and myothertopic:TopicReceiver
>
> When I attempt to listen to these subscriptions, only one listener
> successfully connects. The other receives repeating error messages....
>
> 2018-06-23 13:47:00.120 INFO 24556 --- [windows.net:-1]]
> org.apache.qpid.jms.JmsConnection : Connection
> ID:fdf7a327-9378-4d30-836e-35f3da5d48fb:1 connected to remote Broker:
> amqps://azuresamples-hillmep.servicebus.windows.net?amqp.idleTimeout=3600000
> 2018-06-23 13:47:00.120 INFO 24556 --- [ main]
> o.s.j.c.CachingConnectionFactory : Established shared JMS
> Connection: org.apache.qpid.jms.JmsConnection@129bc99
> 2018-06-23 13:47:00.176 INFO 24556 --- [ main]
> o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080
> (http) with context path ''
> 2018-06-23 13:47:00.182 INFO 24556 --- [ main]
> azure.example.app1.Application : Started Application in 9.22
> seconds (JVM running for 15.104)
> 2018-06-23 13:47:01.429 WARN 24556 --- [windows.net:-1]]
> o.a.q.j.p.a.b.AmqpResourceBuilder : Open of
> resource:(JmsConsumerInfo: { ID:fdf7a327-9378-4d30-836e-35f3da5d48fb:1:1:1,
> destination = myothertopic }) failed: Cannot open a Topic client for entity
> type Subscriber. TrackingId:720e7137-67c6-44fb-9b4d-e419be664544_B14,
> SystemTracker:azuresamples-hillmep:topic:myothertopic~15|TopicReceiver,
> Timestamp:6/23/2018 3:47:00 AM
> TrackingId:8946c6d0ff674853ba2079b07f520046_G41, SystemTracker:gateway7,
> Timestamp:6/23/2018 3:47:00 AM [condition = amqp:not-allowed]
> 2018-06-23 13:47:05.581 WARN 24556 --- [enerContainer-1]
> o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
> invoker failed for destination 'mytopic' - trying to recover. Cause: A
> non-shared durable subscription is already active with name 'TopicReceiver'
> 2018-06-23 13:47:05.585 INFO 24556 --- [enerContainer-1]
> o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
> Connection
> 2018-06-23 13:47:06.654 WARN 24556 --- [enerContainer-1]
> o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
> invoker failed for destination 'myothertopic' - trying to recover. Cause:
> Cannot open a Topic client for entity type Subscriber.
> TrackingId:720e7137-67c6-44fb-9b4d-e419be664544_B14,
> SystemTracker:azuresamples-hillmep:topic:myothertopic~15|TopicReceiver,
> Timestamp:6/23/2018 3:47:00 AM
> TrackingId:8946c6d0ff674853ba2079b07f520046_G41, SystemTracker:gateway7,
> Timestamp:6/23/2018 3:47:00 AM [condition = amqp:not-allowed]
> 2018-06-23 13:47:06.654 INFO 24556 --- [enerContainer-1]
> o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
> Connection
> 2018-06-23 13:47:11.979 WARN 24556 --- [enerContainer-2]
> o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
> invoker failed for destination 'myothertopic' - trying to recover. Cause: A
> non-shared durable subscription is already active with name 'TopicReceiver'
> 2018-06-23 13:47:11.980 INFO 24556 --- [enerContainer-2]
> o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
> Connection
> 2018-06-23 13:47:16.995 WARN 24556 --- [enerContainer-3]
> o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
> invoker failed for destination 'myothertopic' - trying to recover. Cause: A
> non-shared durable subscription is already active with name 'TopicReceiver'
> 2018-06-23 13:47:16.996 INFO 24556 --- [enerContainer-3]
> o.s.j.l.DefaultMessageListenerContainer : Successfully refreshed JMS
> Connection
> ^C2018-06-23 13:47:18.278 INFO 24556 --- [ Thread-4]
> ConfigServletWebServerApplicationContext : Closing
> org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@dc8451:
> startup date [Sat Jun 23 13:46:51 AEST 2018]; root of context hierarchy
> 2
>
> If I change either of the subscription names to something else, it all works
> correctly. But it behaves like subscription names have to be unique
> regardless of the topic against which have been created. If I only have the
> single listener in the app, I don't see any error either.
>
> This behavior didn't occur in 0.11.0 of the JMS library. It started at
> 0.20.0 and continues to the current version.
>
> Is this a bug or is this expected behavior? Thanks for any info
>
> Ed
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org