Re: OFBiz in cluster, load balance, different availability zones

2018-03-07 Thread Paul Foxworthy
Hi Sergei, On 7 March 2018 at 23:58, biletni...@gmail.com wrote: > Maybe someone knows the reason why we use externalLoginKey and why not to > use cookie only? > My guess: your users can turn cookies off. So if you rely on them, you risk the application breaking for

Re: OFBiz in cluster, load balance, different availability zones

2018-03-07 Thread Jacques Le Roux
Did you have a look at the Tomcat SSO solution? It tough needs extension for cluster... https://issues.apache.org/jira/browse/OFBIZ-10123 Jacques Le 07/03/2018 à 13:58, biletni...@gmail.com a écrit : Redis is just a way how to store the session data, but the issue is not here. Again, for

Re: OFBiz in cluster, load balance, different availability zones

2018-03-07 Thread biletnikov
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

Re: [Discussion] Creating a unified service-library component

2018-03-07 Thread Taher Alkhateeb
Yes possibly folders, and more likely just file names. For example: service-library/ ├── ofbiz-component.xml └── services ├── accounting-services.xml ├── content-services.xml ├── humanres-services.xml ├── manufacturing-services.xml ├── marketing-services.xml ├──

Re: OFBiz in cluster, load balance, different availability zones

2018-03-07 Thread Paul Foxworthy
On 7 March 2018 at 17:53, Michael Brohl wrote: > How does an in-memory database like Redis hel with the setup of > clustering/load balancing? > Hi Michael, I think that was for non-sticky sessions. Cheers Paul Foxworthy -- Coherent Software Australia Pty Ltd PO

Re: [Discussion] Creating a unified service-library component

2018-03-07 Thread Paul Foxworthy
On 7 March 2018 at 16:57, Taher Alkhateeb wrote: > Yeah I am proposing one big component to house all services. The reason is > that it makes no sense in separating them because they are tightly coupled > and depend on each other heavily (because they share the full