Redis is just a way how to store the session data, but the issue is not here.
Again, for me the good cluster must be able to support non sticky sessions. It
means any new request can be sent to any available OFBiz instance and if one is
down, the next requests will be sent to another one and the session will be
In comparison ,to sticky session, the client session is bound to the certain
OFBiz instance and if it is down, you will loose the session. Also, if it will
be overloaded, you can not to change it.
So, it is better to avoid sticky sessions in spite of that they are more easier
to work with.
So, all what I discuss concerns NON sticky sessions.
As I said before, we have 3 session replication solutions for Catalina (as main
OFBiz web container) out of the box:
- Session replication via TCP IP broadcasting (as I see we have support it in
OFBiz /framework/base/config/ofbiz-containers.xml and find
This way does not good for nowdays cloud infrastructure, because of lack of
support for broadcasting packets. But it maybe reasonable if your launch
several instances on the one host (but I did not test it)
- Session replication via shared file system (PersistentManager + FileStore),
it can be considered if you run instances on the one server instances, but not
- Session replication via Rational Database (PersistentManager + JDBCStore), it
looks the best for me, because shared DB is quite good way for the integration.
I have implemented support for PersistentManager + FileStore and JDBCStore in
OFBiz, but I have not finished yet, because of some issues I am working on.
1, As OFBiz is built from multiple Catalina contexts (many web applications),
we have to use the
session replication feature per each context, and each one opens the
connection to DB. As result, for one instance we can have more than 20
connection to database from JDBCStore per each OFBiz instance. But possible
workaround is using JNDI and connection pool to the database globally in
Catalina, I am going to test it.
2. Although sessions are replicated fine, but we still have to stick with :
This parameter is kept per certain instance in the memory and as I understand
has a role of authentication when you jump from one OFBiz web context to
like when you Logged In to the Order module, you can open Accounting without
Logging because you pass externalLoginKey, which is used to find the UserLogin
you used in Order before and it makes the authentication works. (Maybe I wrong
here about externalLoginKey).
It is like a cookie extension.
As ExternalKey is kept per instance in memory, it is the problem for
So, I see 2 solutions here:
1. Avoid ExternalKey if it is possible, maybe cookie is enough.
2. Keep ExternalKey in the database.
Maybe someone knows the reason why we use externalLoginKey and why not to use
On 2018/03/07 01:07:20, Shi Jinghai <huaru...@hotmail.com> wrote:
> Or Redis with Redisson?
> 1. https://github.com/antirez/redis
> åä»¶äºº: biletnikov@ [mailto:gmail.com biletni...@gmail.com]
> åéæ¶é´: 2018å¹´3æ6æ¥ 20:53
> æ¶ä»¶äºº: email@example.com
> ä¸»é¢: OFBiz in cluster, load balance, different availability zones
> Hi all, I still support OFBiz 12.04 + some custom extensions for one
> Now, we need to launch OFBiz in a cluster or it is better to say on different
> machines in different availability zones in AWS infrastructure.
> The main problem arises here is the http session replications among all
> At least, in OFBiz 12.04 we have a clustering solution for Tomcat container
> using SimpleTcpCluster.
> It is the way when all instances must share sessions via broadcasting IP
> packets, although this way maybe good for clustering on the one server
> instances, but it will not work in cloud infrastructure and in different
> availability zones. Because broadcasting IP packets are very low level
> communication which is not supported in the cloud services.
> Another solutions, which Tomcat proposes for session replication are:
> - use shared file system and common directory to store and read sessions
> - use shared database to replicate sessions
> I am working on the support for these two solutions in Catalina container.
> However, I would like to ask you, maybe we have another solution in OFBiz to
> work with ?
> Thank you.