cas protocol behind an F5

[Niva Agmon]

Update 
The error on the one CAS client that doesn't work when we fail over seems to be on the client side. The other two test CAS clients (apache & Tomcat) are working as expected.
Still seeing the exception errors when recycling the IDP.

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Niva Agmon
Sent: Friday, September 9, 2016 4:31 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: cas protocol behind an F5

Applied Unicon's hazelcast and things look a little better, but still there is one CAS client that basically works only with one node and gets authorization denied when I fail over to the other node. 
I enabled hazelcast for both idp.session.StorageService & idp.cas.StorageService

The other issue with Hazelcast is that It throws exceptions when Tomcat is shutdown - looks like it's a timeout condition, but am not sure where it is setup -

"hz._hzInstance_1_dev.HealthMonitor" #56 daemon prio=5 os_prio=0 tid=0x5c4fa800 nid=0xe1cc waiting on condition [0x53376000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at java.lang.Thread.sleep(Thread.java:340)
        at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
        at com.hazelcast.internal.monitors.HealthMonitor$HealthMonitorThread.run(HealthMonitor.java:135)

"cached4" #51 prio=5 os_prio=0 tid=0x536d5c00 nid=0xe1c9 waiting on condition [0x53418000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x68d1fa88> (a java.util.concurrent.SynchronousQueue$TransferStack)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
        at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
......

This is our Hazelcast configuration:

<!-- Hazelcast storage configuration --> <bean id="hazelcast" class="com.hazelcast.core.Hazelcast" factory-method="newHazelcastInstance">
    <constructor-arg name="config">
        <bean class="com.hazelcast.config.Config">
            <property name="properties">
                <util:properties>
                    <prop key="hazelcast.logging.type">slf4j</prop>
                    <prop key="hazelcast.max.no.heartbeat.seconds">5</prop>
                </util:properties>
            </property>
            <property name="networkConfig">
                <bean class="com.hazelcast.config.NetworkConfig">
                    <property name="port" value="5701"/>
                    <property name="portAutoIncrement" value="true"/>
                    <property name="join" ref="tcpIpHazelcastJoinConfig"/>
                </bean>
            </property>
        </bean>
    </constructor-arg>
</bean>

<bean id="tcpIpHazelcastJoinConfig" class="com.hazelcast.config.JoinConfig">
    <property name="multicastConfig">
        <bean class="com.hazelcast.config.MulticastConfig">
            <property name="enabled" value="false"/>
        </bean>
    </property>
    <property name="tcpIpConfig">
        <bean class="com.hazelcast.config.TcpIpConfig">
            <property name="enabled" value="true"/>
            <property name="members" value="%{hz.cluster.members:--shib_node1----,---shib_node2---}"/>
        </bean>
    </property>
</bean>

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

<bean id="my.StorageService.cas"
        class="net.unicon.iam.shibboleth.storage.SingleHazelcastMapBackedStorageService">
    <constructor-arg value="cas" />
    <constructor-arg ref="hazelcast" />
</bean>

<bean id="my.StorageService.idpSession"
      class="net.unicon.iam.shibboleth.storage.SingleHazelcastMapBackedStorageService">
    <constructor-arg value="session" />
    <constructor-arg ref="hazelcast" />
</bean>


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Paul B. Henson
Sent: Tuesday, September 6, 2016 10:07 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: cas protocol behind an F5

On Tue, Sep 06, 2016 at 07:57:27PM +0000, Niva Agmon wrote:

> It looks like the nodes do connect, but I can only see the ticket on 
> one of the nodes (number 2), even though they are both configured the
> same:

Have you looked at Unicon's hazelcast storage backend? We've been using that since June and found it very reliable for clustering. It's currently an extra add-on but I think Scott is looking at possibly including it in the next release.

--
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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net