Relevant Versions:
This information pertains to Artifactory version 5.5 and above, up to but not including 6.0.
Artifactory has been using Hazelcast mainly for locking during write operations and sharing UI sessions between nodes. To increase the stability of the write-lock method between the nodes of your Artifactory Enterprise cluster, we recommend disabling Hazelcast. You might also want to disable UI session sharing.
For each function, you can use the following directions to replace Hazelcast with a new method for reasons described below.
1. Write Lock
Instead of Hazelcast, your database can handle write-locks. Depending on the number of nodes you have, this alternative might also result in an increase in performance for this functionality.
Instructions:
-
Shutdown all of your nodes (see Notes below for details).
-
Optional: Increase your database connections both in Artifactory (pool.max.idle) and in your database. The collective, maximum number of database connections for all of your nodes should be less than your database’s maximum. In other words:
[pool.max.active] * [number of nodes] < [Max DB connections]
More information on database monitoring and tuning can be found here. -
For each of your nodes, set the following property at artifactory.system.properties:
artifactory.locking.provider.type=db -
Start each node, beginning with the primary.
Notes:
-
We recommend a brief period of downtime during your transition to database write-locking. This will avoid a scenario in which some of your nodes will be using the new locking mechanism while others are still using the old system. Should this occur, your cluster will break into two groups, which could cause one group to interfere with the other or, worse, data corruption issues. For example, while one node is uploading binaries to an a/b/bin.txt file, another might delete the a/b directions. Without a full-cluster lockdown, this could result in a situation where that file exists without its directories.
-
Your new database locking mechanism will add its own connection pool, defaulting to the pool.max.active value. However, you might need to adjust your database connection limit to accept more connections. When doing so, you should base your concurrent connections per node calculation on the number of configured connections per node multiplied by the number of nodes in your cluster. Your database should accept the number of configured connections per-node multiplied by the number of the nodes in the cluster.
By default, Artifactory versions 6.2 and above uses a database locking mechanism to provide added robustness and stability.
2. Session Sharing
Session sharing can be configured locally, with the tradeoff being that you’ll have to enable sticky sessions (aka, session affinity) for your load balancer. With this change, all propagation of internal massages between nodes will be refactored and accomplished via REST, which will allow you to place this mechanism behind an SSL-backed web server and avoid unencrypted communication over TCP if SSL/TLS is enabled on each node or on the load balancer.
Instructions:
- Enable sticky sessions for your load balancer. An example of how to do this for the AWS ELB is available here.
- Set the property artifactory.map.provider.type=jvm at artifactory.system.properties:
- Restart each node.