in my previous blog I suggest to use jms or caching for a distributable SessionRegistry
but I found a more simple solution JGroups -
DistributedHashtable :JGroups gives us such a perfect simple class to distributed maps.
I implement two classes
first DistributableSessionInformation in fact nothing different from original SessionInformation there are points
DistributableSessionRegistryImpl is SessionRegistry via JGroups
you can set both jgroups file and cluster name
if you use init and destroy method it will be cluster enabled else local singleton cache
sample configuration
<bean id=”org.acegisecurity.concurrent.SessionRegistry”
class=”tr.com.oasis.babylon.acegi.DistributableSessionRegistryImpl” init-method=”init” destroy-method=”destroy”>
<property name=”channelName” value=”acegicluster1″/>
<property name=”clusterOptions” value=”udp.xml”/>
<property name=”distributable” value=”${distributable}”/>
</bean>
download distributable-acegi.zip for both source and binary
dependency :
http://www.jgroups.org
http://www.acegisecurity.org/
waiting for your comments
Update:
06.18.2007:small update for upload link and implementation for a small bug.
Hot Referers:
http://www.theserverside.com/blogs/thread.tss?thread_id=45789
www.dzone.com/links/distributable_acegi_via_jgroups.html
http://forum.springframework.org/showthread.php?t=40111
forum.springframework.org/showthread.php?p=126459
Related posts:
Sarath Babu Polavarapu said on Tuesday, February 17, 2009, 11:35
When I trying to execute the given java files..
It is giving multiple compile time errors in DistributableSessionRegistryImpl.java file.
One is like “The type DistributableSessionRegistryImpl must implement the inherited abstract method
SessionRegistry.getAllSessions(Object)”
Dan said on Monday, February 23, 2009, 16:10
Did you have any issues whenever you manually shutdown one of the server instances? If I gracefully shut down one of the clustered instances of Oracle Application Server, the HttpSessionDestroyedEvent fires off and removes the principal, but does not remove the Authentication object in the SecurityContextHolder, thus the user is still authenticated, but no longer has SessionInformation in the SessionRegistry. I took a look at the logic in the ConcurrentSessionFilter and it does not perform any action on null SessionInformation objects.
altuure said on Monday, February 23, 2009, 16:22
do you open session replication among the server instances?
This is very specific case that jgroups replicates the data but the server not.
It is better you check the configuration of the server.
altuure said on Monday, February 23, 2009, 16:24
hi Sarath,
I think this is a version specific problem , in other words my code and you project are possibly not using the same version
can you specify your spring-security version please ?
regards
Dan said on Monday, February 23, 2009, 17:07
I do have session replication enabled on the OC4J instances. Are you saying that I have to have this disabled? If I disable this, will this stop the HttpSessionDestroyedEvent from being fired off when I shut down a single instance of OC4J? Thanks!
altuure said on Monday, February 23, 2009, 17:11
session replication should be enabled, but since I haven’t run this on oracle, I am not sure what the problem might be
Dan said on Monday, February 23, 2009, 17:38
I added log statements to your source code otherwise I wouldn’t have even noticed it if I wasn’t checking log files. The Authentication object gets replicated even if I shutdown one instance of OAS. It does not get destroyed, therefore the user can continue to use the application with no DistributedSessionInformation in the DistributedSessionRegistryImpl (getSessionInformation returns null). However since there is no DistributedSessionInformation , the last refresh date will never get updated and the account will eventually expire. I’m going to double check my server configuration and then look into the Spring event flow to see why this event is being published when I shutdown an instance. Thanks!
Dan said on Monday, February 23, 2009, 19:06
After further research, this is a common problem with web servers. It seems that the session destroyed event is called for the sessions in the current node and is not global to the cluster. There is an easy solution in the JBoss link below. You can load a properties file to determine if a shutdown is occurring. The only issue with this is that one would have to remember to update the properties file before the instance was shut down and then again prior to the app server restart.
If you can come up with a better solution I would like to hear about it.
https://jira.jboss.org/jira/browse/JBSEAM-3172
http://www.mail-archive.com/users@tomcat.apache.org/msg42968.html
Sarath Babu Polavarapu said on Tuesday, April 21, 2009, 13:55
Hi Altuure,
I am using spring 1.2.6.jar and acegi-security-1.0.0-RC1.jar. Please let me know if I need to changes acegi security version. In your dependency list, it is being mentioned to use acegi 1.0.3. Can I have to reference URL to dowload this version Jar file.
Thanks,
Sarath.
altuure said on Thursday, April 23, 2009, 8:46
Hi Sarath,
I am not sure about these versions since it a very old post and project..
but you can download the jar files from
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/acegisecurity/acegi-security/1.0.3/
Regards
Mert Can Akkan
Sarath Babu Polavarapu said on Sunday, April 26, 2009, 16:53
Hi Mert,
Thanks for your response. As you addressed, the problem was version specific problem. When I have replaced acegi-security-1.0.7 (latest version, downloaded from spring website), problem got resolved. And I am able to run your TestCase.
However, in my legacy code, we are uisng acegi framework constant, “AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY”, which is available in previous jar file (acegi-security-1.0.0-RC1.jar). But when I have changed this jar file reference from acegi-security-1.0.0-RC1.jar to acegi-security-1.0.7.jar, it is displaying the compile time error: “AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY cannot be resolved”
Do you have any idea how to resolve this issue ?
Thanks, Sarath.
altuure said on Monday, April 27, 2009, 15:20
Hi Sarath,
As far as I remember the configuration of 1.0+ is mostly different than previous versions so you can look at upgrade guides and
http://www.acegisecurity.org/guide/springsecurity.html#form-config
Sagara said on Friday, May 29, 2009, 8:36
In JBoss 4.2.1.GA (JGroup 2.4.1-sp3) cluster i got some version mismatch problems for DistributedHashtable but after some slight modification with ReplicatedHashtable i got successful results . If any one facing to same problem ,refer this post http://ssagara.blogspot.com/2009/05/acegi-clustering-on-jboss.html