clustering with HazelcastStorageService

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Thursday, April 28, 2016 5:02 PM
> 
> Multiple instances of storage services are certainly supported, that's why the
> properties are all separate to allow for different storage plugins in each use
> case.
> 
> If that's a useful trick to optimize this particular implementation so it can
> apply some sort of setting globally, that is likely the best way to accomodate
> it.

Okay, so it sounds like from your perspective on the idp side, if a storage back end wants to be able to categorize all of the things it is storing as belonging to the same storage client (everything is a session, everything is part of the replay cache, everything is a CAS session, etc), the best way to do it is to design it to instantiate a separate instance of itself for each use case, eg in global.xml:

    <bean id="cpp.edu.sessionHazelcastStorageService"
          class="net.unicon.iam.shibboleth.storage.HazelcastMapBackedStorageService">
        <constructor-arg name="hazelcastInstance" ref="hazelcast" />
    </bean>

    <bean id="cpp.edu.replayHazelcastStorageService"
          class="net.unicon.iam.shibboleth.storage.HazelcastMapBackedStorageService">
        <constructor-arg name="hazelcastInstance" ref="hazelcast" />
    </bean>

    <bean id="cpp.edu.casHazelcastStorageService"
          class="net.unicon.iam.shibboleth.storage.HazelcastMapBackedStorageService">
        <constructor-arg name="hazelcastInstance" ref="hazelcast" />
    </bean>


And in idp.properties:

idp.session.StorageService = cpp.edu.sessionHazelcastStorageService
idp.replayCache.StorageService = cpp.edu.replayHazelcastStorageService
idp.cas.StorageService = cpp.edu.casHazelcastStorageService

Is that a correct interpretation of what I think you're saying?

Thanks much…

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768