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

Solace Event Broker
1

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

2

Hi

I believe I found the issue.

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

Regards
Shaun

3

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…!

4

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.

5

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! ??

6

Hi again @shaunvdberg ..! I’ve just got a notification from our Support team that this issue has been fixed in .NET API 10.28.1. There’s no release note that mentions this (we’ll get that in there) but the fix should be there. Please try this new version.

Thanks!