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 alive. 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 default-server-cluster there). 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 recommended. - 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 : externalLoginKey=EL29523626374 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 another : 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 clustering. 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 cookie only? Thanks. On 2018/03/07 01:07:20, Shi Jinghai <[email protected]> wrote: > Or Redis[1] with Redisson[2]? > > 1. https://github.com/antirez/redis > 2. > https://github.com/redisson/redisson/wiki/14.-Integration%20with%20frameworks#145-tomcat-redis-session-manager > > -----é®ä»¶åä»¶----- > å件人: biletnikov@ [mailto:gmail.com [email protected]] > åéæ¶é´: 2018å¹´3æ6æ¥ 20:53 > æ¶ä»¶äºº: [email protected] > 主é¢: OFBiz in cluster, load balance, different availability zones > > Hi all, I still support OFBiz 12.04 + some custom extensions for one > customer. > > 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 > machines. > 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. > >
