You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Stephen McCants <st...@hcs.us.com> on 2013/07/13 00:41:59 UTC

Shiro Single Sign On with localRestartable in one Tomcat instance

Hi All,
     I'm using Shiro with ehCache and BigMemory Go.  I have a setup 
similar to the one describe by "f a v" in this thread:

http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p5563334.html

That works well for me.  However, I have an additional requirement: we 
need to be able to stop and restart Tomcat without losing sessions.
     To accomplish that I'm looking at using "localRestartable". That is 
why I pulled in BigMemory Go. However, I ran into this error with my 
initial configuration:

/Caused by: net.sf.ehcache.config.InvalidConfigurationException: The 
disk path for this cache manager has been auto-generated due to a path 
conflict with another cache manager. You must define a specific unique 
disk path for this manager in order to use restartable caches./

So I moved the disk stores to different locations, resulting in two 
slightly different ehcache configurations.

Here is the first ehcache.xml:

/<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"//
//        xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"//
//        monitoring="autodetect" dynamicConfig="true" name="WebTL">//
//
//        <diskStore path="java.io.tmpdir" />//
//
//        <cacheManagerPeerProviderFactory//
//class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"//
//                properties="peerDiscovery=automatic,//
//                        multicastGroupAddress=230.0.0.1,//
//                        multicastGroupPort=4446, timeToLive=1"//
//                propertySeparator="," />//
//
//        <cacheManagerPeerListenerFactory//
//class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" 
/>//
//
//        <cache name="shiro-activeSessionCache" maxElementsInMemory="600"//
//                eternal="true" memoryStoreEvictionPolicy="LFU">//
//                <cacheEventListenerFactory 
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" />//
//                <persistence strategy="localRestartable"/>//
//        </cache>//
//
//        <defaultCache maxElementsInMemory="100" eternal="true"//
//                overflowToDisk="true" memoryStoreEvictionPolicy="LFU">//
//        </defaultCache>//
//</ehcache>/

Here is the second ehcache.xml:

/<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"//
//        xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"//
//        monitoring="autodetect" dynamicConfig="true" name="ORMCREST">//
//
//        <diskStore path="C:\temp" />//
//        <!-- <diskStore path="java.io.tmpdir" /> -->//
//
//        <cacheManagerPeerProviderFactory//
//class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"//
//                properties="peerDiscovery=automatic,//
//                        multicastGroupAddress=230.0.0.1,//
//                        multicastGroupPort=4446, timeToLive=1"//
//                propertySeparator="," />//
//
//        <cacheManagerPeerListenerFactory//
//class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" 
/>//
//
//        <cache name="shiro-activeSessionCache" maxElementsInMemory="600"//
//                eternal="true" memoryStoreEvictionPolicy="LFU">//
//                <cacheEventListenerFactory 
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" />//
//                <persistence strategy="localRestartable"/>//
//        </cache>//
//
//        <defaultCache maxElementsInMemory="100" eternal="true"//
//                overflowToDisk="true" memoryStoreEvictionPolicy="LFU">//
//        </defaultCache>//
//</ehcache>/

If I switch the comments on the diskStore tags above, then I'll go back 
to the error I had before.

The above configuration, as shown, does work.

Here are my questions:

1) Does it make sense to try and have the two ehCaches share the same 
diskStore?  It seems to me that it would be desirable to have only one 
written cache, so they would stay in sync.  However, maybe that is not 
necessary and only trouble.

2) Is this configuration going to get me in trouble?  Will I end up with 
a user authenticated in one WebApp and not the other?  (Briefly testing 
it, it seems to work correctly - SSO with persistence through a restart.)

3) Is there a way to have only one ehCache shared by the to WebApps?  Is 
that worth the trouble?

Thanks for your help!

Sincerely,
Stephen McCants

-- 
Stephen McCants
Senior Software Engineer
Healthcare Control Systems
1-877-877-8795 x116