Experimental feature

Current problem

Jira DC have multiple nodes. When a user sign into Jira, a node will be picked by the load balancer. The following access and interaction of the user will stick to the selected node.

As a consequence for HDDB live log viewer, we can only view the log from the node we are on. There is no way to switch node and access the log we want to see.

This is a huge limitation for system admin who may need to check the log of arbitrary node.

Idea

Use the current node as a proxy to handle log loading and displaying for another node.

It should be handled transparently. The only thing users need to do is specifying which node they want to access. Then the log request will be sent to the target node and the target node will send back requested log to the user node.

This could be a feature for next major version.

Solution

The initial technical solution is using the existing HTTP rest service to implement inter-node communication for log retrieval. However, it is hard to:

  • discover ip address and port for each node

  • handle authentication to access HTTP service on another node

It turns out it is possible to leverage Jira’s cluster messaging mechanism to achieve what we want to do. Essentially we are using the cluster messaging as a protocol for log request and log retrieval.

There is a limitation though. A cluster message can not be longer than 200 chars. So each log entry has to be broken down into multiple small chunks for sending.

A proof of concept is developed to verify the solution. Below are screenshots:

Screen Shot 2024-03-18 at 3.57.37 pm-20240318-045746.png

The current node is node3 and it displays log from node4.

Screen Shot 2024-03-18 at 4.24.29 pm-20240318-052435.png

And if we access node4, it display log from node3.

Cost

It would take a few more man-weeks to turn the proof of concept into a product level feature.

Risk

It is only tested on a local two-node Jira cluster. More test will be done on a cluster with load balancer.

Using cluster messaging service might add some workload to cluster management. Database could be used to exchange log entries if it proves to be a concern.