0

I am using Azure service bus topic/subscriptions with sessions. I am setting a hardcoded value for the sessionId as I want to control processing of incoming messages.

So even if there are more than one eligible subscribers which can process this message only one will get the sessionlock and process it. I release the lock by closing the session once it is done processing so that new messages can be picked up by any of the processors. My only concern here is, is there any downside of closing the session after completion of message processing?If I close session, will the processor with closed session be able to open session and process the message at later?

TIA

Scooby
  • 635
  • 3
  • 9
  • 21

1 Answers1

0

Sessions are usually intended for groups of messages and not a single message. When you want those messages to be processed in order (FIFO) a single subscriber should handle that subscription until messages in the session are all processed. And then, what you do, closing a session, is fine as it will expire eventually. Not to mention that your subscriber could start processing another session rather than waiting for an "empty" session to time out.

In case you have a single message per session, I would advise against using sessions to begin with.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Thanks for your response. I know I am not using the sessions as intended. My use case is to restrict number of messages processed in our distributed system to 1 at a time. We have long running operations which can take upto 8 hours or more. So i am using a hard coded sessionId which I will attach with the message so that even if more messages gets sent to the subscription, only one message will be processed. Does that makes sense? I have other messages which go to other subscriptions and do not have such restrictions. – Scooby Jun 10 '20 at 03:10
  • Is that a session ID per message? – Sean Feldman Jun 10 '20 at 03:34
  • To give little more context about my system. We have incoming messages and every message has a messageType. I am using session only for one messagetype and for that I use the same sessionId for all the messages. Every message type is in its own subscription. – Scooby Jun 10 '20 at 18:13
  • If messages of the same message type are handled via the same subscription, what prevents you to have designated subscribing endpoints, having a subscriber processor per message type? Is the number of message types unbound or too big? Are those messages different in their structure and kick-off different type of processing or it's identical? – Sean Feldman Jun 11 '20 at 05:02
  • Messages different in their structure and kick-off different type of processing. – Scooby Jun 11 '20 at 10:42
  • In that case, I'm not convinced sessions is the right approach. You have distinct messages with different processing and serial processing requirement. I would go with a processor per message type and keep concurrency to one if that's what required. – Sean Feldman Jun 12 '20 at 04:30
  • I would go with a processor per message type - I have that. However, if I keep concurrency to one, and have 5 nodes in the distributed system, then potentially I can process 5 calls which I do not want. I want 1 call to be processed across the system irrespective of nodes avaiable. – Scooby Jun 12 '20 at 19:06
  • Concurrency is not the only way to implement concurrent consumers. If the 5 nodes share the same queue, then you're scaling out processing. Another option, going back to sessions, is to assign **the same** session ID to the messages of the same type. Session ID could be the message type. Then you don't have to worry that more than 1 node will be processed concurrently messages of the same type. You'll be able to run not only all of your nodes but also have a concurrency on each node. If the number of message types will increase, you'd be able to process them concurrently and scale-out. – Sean Feldman Jun 13 '20 at 19:36
  • Hi Sean, I think I did not explain what I am doing clearly because I am doing exactly what you are suggesting :). I am using one sessionID for all the messages of a messageType that require the above mentioned processing. However using messageType as sessionId is a good suggestion. I an using hard-coded guid. So coming back to my original question, in this case should i be closing the session after processing a message? Currently, I am marking it as complete. – Scooby Jun 14 '20 at 16:01
  • 1
    Got it. If you complete, you complete the message. When you Close, you close the session. In your case, it wouldn't really matter as your entire session is a single message. Usually, you'd close a session to indicate you're no longer processing it and another consumer could pick it up if move messages in that session arrive. – Sean Feldman Jun 16 '20 at 04:39