One session per subscriber (scalability)

[frawolff]

Hi (again),

Is it sustainable to have one session per subscriber when you can expect more than 100,000 concurrent durable subscribers  (in a clustered environment with a distributed topic)?

Having multiple subscribers managed by a same session seems to be an issue with transaction isolation (commit/rollback operations are session wide).

On the other hand, because a session is a "single-threaded context" (JMS API doc), having 100,000 different sessions could potentially lead to the same number of threads. Is JBM / HornetQ using a configurable, limited thread pool to handle such a large number of concurrent sessions?

Thanks for any clarification.

[gaohoward]

I think you can have a thread pool of your own, and assign a certain number of sessions to each thread.

Howard

[ataylor]

Is it sustainable to have one session per subscriber when you can expect more than 100,000 concurrent durable subscribers  (in a clustered environment with a distributed topic)?

HornetQ is pretty scalable, thats something we focused on from the begining, however at the end of the day whether its sustainable or not is as much to do with processor power, memory, disk speed, network speed, cluster size etc as it is with HornetQ.

Having multiple subscribers managed by a same session seems to be an issue with transaction isolation (commit/rollback operations are session wide).

Its only an issue if you want to have transactions isolated across a consumer instead!

On the other hand, because a session is a "single-threaded context" (JMS API doc), having 100,000 different sessions could potentially lead to the same number of threads. Is JBM / HornetQ using a configurable, limited thread pool to handle such a large number of concurrent sessions?

Any threads created by HornetQ at both the client side and the server side are controlled by a Thread pool which is configurable.

[frawolff]

Thanks a lot for your quick answers Yong and Andy, I really appreciate.