Problem with hazelcast with multiple server running on localhost postgres on same network
Description
Environment
Activity
Carlos Ruiz November 2, 2024 at 11:51 AM
Hi
I started developing this, and then noticed that a properties variable doesn’t add much value.
I think the easiest is to set the attribute auto-detection enabled to false in hazelcast-template.xml
In my experience every implementation using hazelcast for load balance requires a customized template, for example to set the discovery rules on AWS.
WDYT?
Regards,
Carlos Ruiz
Heng Sin Low October 30, 2024 at 11:58 AM
Ok, that’s fine for me.
Carlos Ruiz October 30, 2024 at 11:14 AM
I like the idea of a new key on idempiereEnv.properties HAZELCAST_CLUSTER_AUTO_DETECTION
But instead of making it part of the setup, we can make it “false” by default and it needs to be changed manually on idempiereEnv.properties by implementors using load balancer (or multi-server).
I mean, I would prefer not to touch the setup programs for something that will be used in specialized scenarios, WDYT?
Heng Sin Low October 29, 2024 at 2:23 AM
Perhaps we can make HAZELCAST_CLUSTER_AUTO_DETECTION as part of the setup and template ?
Carlos Ruiz October 28, 2024 at 7:22 PM
I see three possible solutions to this problem:
when localhost is detected as
ADEMPIERE_DB_SERVER, change the line 81 to<auto-detection enabled="false"/>- this is to make the server standalone, the only problem here would be to test two servers running on the same server against their local database, but I think that’s minor issue.If implementing the first is too complex (f.e. if ant template doesn’t support conditionals there), then maybe we can make the
<auto-detection enabled="false"/>the default, this is, we do the server standalone by default (which must be the most common case), and the hazelcast.xml file would need to be configured just on multi-server scenarios.Another possibility would be to set the cluster-name with the server IP address or hostname when detecting localhost, but this can bring other issues as the hostname and the IP address could be changed after idempiere setup and create another potential collision.
WDYT?
There is a problem with hazelcast when you have two servers within the same network, each one running against its own local database.
Our template is designed to make the hazelcast cluster-name dependent on the postgresql connection data, because in principle all servers connected to the same database must be part of the same hazelcast cluster.
The problem arise when two servers are connected to the localhost database.
The template says:
which is replaced in each server as:
the idea of cluster-name is that all servers that share the same connection to the same database are connected using hazelcast. But in this case, localhost is the database of each server, and these databases are different, but because the cluster-name is the same hazelcast tries to connect both servers and can have two scenarios, both problematic:
it can be that both servers share the same cache with hazelcast - which is wrong because they are connected to different databases
or can also crash one or both server when they have different hazelcast versions