clustering with HazelcastStorageService

Paul B. Henson henson at
Thu Apr 28 03:39:52 EDT 2016

On Thu, Apr 28, 2016 at 12:08:48AM -0700, Paul B. Henson wrote:

> Hmm, I would have thought the session cache would have instantiated one
> instance of a storage engine for the entire idp, but it sounds like
> you're saying it actually instantiates an instance for each individual
> session? Or am I misunderstanding? I'm not quite sure what you mean by

Yep, I took a peek through the code and it does look like that's the
case, each idp session creates a new separate instance of the storage
backend just for the data needed for that session.

I'm not that familiar with hazelcast to say how much my abstract concern
regarding inefficiency would translate into a practical implementation
issue. Jonathan, any thoughts? Theoretically the hazelcast backend could
create a single map for all the session storage needs and share it between
all of the separate instances rather than create a new map for each one
of them, but I don't know if the additional complexity would be worth
it. The issue would be knowing which instances were sessions, if things
other than sessions also had random context names. That would be easy
enough to fix by making session contexts "session-<randomid>" rather
than just "<randomid>" but that's getting a bit ahead of the discussion.


Paul B. Henson  |  (909) 979-6361  |
Operating Systems and Network Analyst  |  henson at
California State Polytechnic University  |  Pomona CA 91768

More information about the users mailing list