There are 2 homogeneous clusters and these fall under a common domain.
cluster1 has different app servers than cluster2.
How to manage session between these clusters?
How to authenticate cluster1-app-server created sessionId(session) in cluster2-app-server
or Is there a common place I can create jsessionId(session) and make it not a container specific implementation?
hazlecast or tomcat gives session replication/management inside a homogeneous cluster.
How to take this between clusterS ?
Any data point is much appreciated.
Is shiro suited for this?
Shiro works well within one machine, it keeps a session in memory. Having it authenticate the same session to another place would require setting tokens on the session, which the other machine recognizes and you would have to write custom code for that.
I think you are better of by using some kind of single signon server like CAS.
http://jasig.github.io/cas/4.0.0/index.html
Related
Why?
For educational purposes. I think it would be really nice for my audience to actually "see" it work like that.
Setup
A dockerized Spring boot REST API (serving up customer information)
A dockerized Cassandra cluster consisting of three connected nodes, holding customer data with a replication factor of two.
Suggestions
Showing which IP address or container name served my request
Showing which IP address or container name held the data that was used to show my request.
If I were to run these nodes on three seperate physical machines, maybe which machine held my data?
Something else you have in mind that really shows the distributed capabilities of Cassandra
Can this be achieved in docker logs or something in Spring data Cassandra that I am not aware of?
I don't know about Spring Data, but in normal Java driver you can get execution information from ResultSet via getExecutionInfo, and call function getQueriedHost from it. If you're using default DCAware/TokenAware load balancing policy, then you reach at least one of the nodes that hold your data. The rest of information you can get via Metadata class from which you can get a list of token ranges owned by hosts, generate a token for your partition key, and lookup in the token ranges.
P.S. See Java driver documentation for more details.
We have configured our application servers (two or three), to work as clients with a Hazelcast cluster (one or two members), for session persistence.
At first, we configured it as a two nodes of application servers with the embedded setup of Hazelcast, then we moved on to the client-server scenario.
On the embedded model, the console showed plenty of information related to the cache objects, replicating between nodes and moving from one instance to another when necessary.
On the Client-Server model we see both clients and members registered on the Hazelcast console, and we get basic information (versions, memory consumption, etc). But we cannot see session information (maps) travel and replicate.
We are pretty sure Hazelcast is working, because we have forced some intrincate combinations of client and member shutdowns that ensure that information recovered by next client must come from the surviving member, and data has traveled from cluster member to cluster member before going down to the client.
So, being convinced we are doing something wrong with the configuration, we humbly ask: Did anyone configure this before (sure, because it seems a very common configuration goal), and did you have similar problems? Did you solve them? How?
You need to enable the statistics for caches to monitor them in the Management Center. Use the element or setStatisticsEnabled() method in declarative or programmatic configuration, respectively, to enable the statistics of maps you want to see on Management Center.
I am trying to develope an application with tomcat running in several computers of same LAN trying representing several nodes and each of them runs an application with a single shared session(Ex. shared document editor such as google docs.). in my understanding so far I need a single shared session and several users need to update the doc symultaneously and each others updates are reflected on each others we interfaces almost imidietly. Can I acheve this with with tomcat's clustering feature. http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#Configuration_Example or is this just a faluir recovery system.
Tomcat's clustering feature is meant for failover - if one node fails, user can carry on working while being transparently sent to another node without a need to log in again.
What you are trying to achieve is a totally different scenario and I think using session for this is just wrong. If you go back to Google Doc example, how would you achieve granting (revoking?) document access to another user? What do you do when session times out - create the document again? Also, how would you define which users would be able to access selected documents?
You would need to persist this data somewhere (DB?) anyway so implement or reuse some existing ACL system where you could share information about users and document permissions.
I am looking into a distributed, replicated session store for multiple Jetty instances. There will be a load balancer (probably nginx and/or haproxy) in front of the Jetty instances.
Specifically, I would like to:
Be able to restart (or crash) one single Jetty instance and have our services available and users still logged in.
Be able to restart (or crash) one single session store instance and have our services available and users still logged in.
The number of sessions will most likely fit on one single machine.
What solutions do you recommend for this? What are your expieriences? Please vote for your favourite option below.
There seems to be a Terracotta session clustering implementation. Haven't tried it myself, but it seems to fit my needs.
I would like to know any experience with the Tomcat Session Cluster solution. Is it production level? Does it scale? Can I use it in a server farm? Do you recommend any other solution for a session cluster? (Ex: database, terracota, jgroups, etc.)
Another alternative would be the memcached-session-manager, a session failover solution for tomcat: http://code.google.com/p/memcached-session-manager/
I created this project to get the best of performance and reliability and to be able to scale out by just adding more tomcat and memcached nodes.
Cheers,
Martin
From all the documentation I've read, it will work fine for a few number of instances but then become an issue.
We use Tomcat as our backend servers but design our applications to use as little session information as possible (basically just logins). Then we front the Tomcats with a load balancer like Apache or Nginx (the later which I'm favoring recently) and use sticky sessions. If a server goes offline (which is unlikely) then the user simply needs to login again, which depending on how you set it up could be transparent to them.
When I was looking to do more session based clustering, Terracotta looked very impressive. But stateless design makes scaling much easier.