I dont think any of the points on unsupported features below actually relate to what you are seeing, with it instead just being a difference in what the AMQP JMS Mapping does for passing JMS subscription details, versus the approach Service Bus is using/expecting.
>From what you outlined, it appears that ServiceBus uses a vendor-specific address format to pass both a topic name and a subscription name when attaching a receiving link, whereas the JMS client on the other hand attaches to the given topic address and uses receiver link naming to pass its subscription details, with this difference presumably being why you see a 'not-found' error from Azure when you dont include the subscription name in the receiver address. On 10 August 2017 at 12:01, 4 Integration <4integrat...@gmail.com> wrote: > I have found the answer: > It is not possible to create durable subscriptions dynamically with > QPid/AMQ v1.0 due to: > https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-java-how-to-use-jms-api-amqp#unsupported-features-and-restrictions > > Unsupported features and restrictions > > The following restrictions exist when using JMS over AMQP 1.0 with Service > Bus, namely: > > - Only one MessageProducer or MessageConsumer is allowed per Session. If > you need to create multiple MessageProducers or MessageConsumers in an > application, create a dedicated Session for each of them. > - Volatile topic subscriptions are not currently supported. > - MessageSelectors are not currently supported. > - Temporary destinations, i.e., TemporaryQueue, TemporaryTopic are not > currently supported, along with the QueueRequestor and TopicRequestor APIs > that use them. > - Transacted sessions and distributed transactions are not supported. > > If required then need to use Azure SB API > https://github.com/Azure/azure-service-bus-java > > Regards > Joacim > > > > > > On Tue, Aug 8, 2017 at 2:09 PM, 4 Integration <4integrat...@gmail.com> > wrote: > >> On the topic defined in Azure Service Bus "test.topic" I have a static >> subscription defined named "sub1". >> >> When publishing I use: >> env.put("topic.TOPIC", "test.topic"); >> >> When subscribing to "sub1" I have >> env.put("topic.TOPIC", "test.topic/Subscriptions/sub1"); >> >> The naming here seems required i.e. <<topic-name>>/Subscriptions/< >> <subscription-name>> >> >> Maybe some other naming required....or something. I will reach out to >> Azure forum also. >> >> I'll be back :) >> >> / Joacim >> >> >> >> On Tue, Aug 8, 2017 at 1:53 PM, Gordon Sim <g...@redhat.com> wrote: >> >>> On 08/08/17 12:37, Gordon Sim wrote: >>> >>>> You could try a further experiment with another see if we can rule out >>>> one or other of these >>>> >>> >>> E.g. if it is easy to get proton python client, you could use the >>> simple_recv.py example with -a my-namespace.servicebus.window >>> s.net:5671/test.topic and see what the protocol trace looks like with >>> that. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: users-h...@qpid.apache.org >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
