Solace shared subscription - Router does not support #share and #noexport subscriptions

Hi everyone

Im experimenting with the shared subscriptions feature. However, when I startup my consumer app, I get the following error:
——————————————————————-
Warning - SessionImpl: 15:29:47|Failed to Subscribe to topic #noexport/ottawa/weathersensor/yow/temperature ReturnCode is: SOLCLIENT_FAIL|null

Unhandled exception. Operation Error: ReturnCode = SOLCLIENT_FAIL Error Info: (Subcode=SharedSubscriptionsNotSupported, Error string=Router does not support #share and #noexport subscriptions on topic ‘#noexport/ottawa/weathersensor/yow/temperature’ in solClient_session_topicSubscribeExt for session ‘(c0,s1)_default’, Response code= 0 )
——————————————————————-
My consumer application is written in dotnet, using the latest client (10.26.0).

session.Subscribe(ContextFactory.Instance.CreateTopic(“#noexport/ottawa/weathersensor/yow/temperature”), true);

I have the latest solace running locally in a container.
I have also enable “allow-shared-subscriptions” on the client profile.

Any ideas?
Thanks
Shaun

Hi

I believe I found the issue.

My consumers where connecting using ws://. Then I changed it to tcp:// it worked.

Regards
Shaun

Hi @shaunvdberg , yes unfortunately shared subscriptions are not available for web client connections (WebSockets). This is mentioned in our docs here: https://docs.solace.com/Messaging/Direct-Msg/Direct-Messages.htm#web-messaging-clients

Glad you can use regular TCP connections though. Thanks for following up. You should accept your own answer…!

Actually… I just tested with our JCSMP Java client, and shared subs work over WebSockets. So… that’s weird. I’m requesting someone in R&D take a look at this.

Hi @shaunvdberg , just as a follow-up here… we’ve determined that the behaviour you experienced (.NET API unable to use shared subs over WebSockets) is indeed a bug, and will be fixed in an upcoming release of the API. For anyone reading this, there is a similar issue with our C (CCSMP) API. The current workarounds are either:

  • Use TCP ( tcp:// or tcps:// ) instead of WebSockets ( ws:// or wss:// )
  • Add the session property SessionProperties.GdWithWebTransport (for .NET) or SESSION_GUARANTEED_WITH_WEB_TRANSPORT,1 (for C)

I’ll update this thread when the fixed APIs are released. Thanks for bringing this to our attention! ??