Description

Atlassian Jira and Confluence have Data Center (Cluster) editions. Most Data Center installations use a load balancer that uses session affinity to distribute work to nodes in the cluster. This can present a challenge when or automation that may be impacted by inter-node latency. For example, an issue created on one node may not immediately show up in a JQL search run on another node. The latency is usually very low (seconds) but any automation can be impacted in these cases. There can also be impacts to individual actions that are using multiple requests under the covers that may fail if they do not hit the same node. While a simplistic approach for scripts to put in sleep delays in the hopes of mitigating this problem, there are better ways.

Use Session Affinity in scripts

Both Jira Command Line Interface (CLI) and Confluence Command Line Interface (CLI) support session authentication. Any actions run as part of a run or runFrom action automatically take advantage of session authentication and therefore support session affinity based clusters - namely running all the actions in the script on the same node. In addition, you can use the cookies parameter to retain sessions between independent CLI actions within a script. Another alternative is to use the login action to get the session cookie and pass it using the login parameter on subsequent CLI calls.

The best approach is if your Data Center is configured to use IP hash or equivalent as discussed in Load balancer configuration options. This keeps automation script requests going to the same node automatically. 

IP hash

The load balancer calculates a hash value based on the client's IP address, and then uses that hash value to assign a node to the new session. This algorithm ensures that requests from the same IP address go to the same node as long as it is available.