Chat for Service Management utilizes websockets as a communication method between the chat widget and Jira, to provide instant reception of messages while minimizing bandwidth usage. In environments where websockets are unavailable, the connection to Jira will gracefully downgrade (with a warning in the browser's console window) to simple periodical polling mechanism, which is guaranteed to work without any special setup. This polling, while also providing a nearly instant message reception time, consumes more network bandwidth and may (in extreme cases) use up Jira's connection pool, therefore it is preferrable to configure your environment for websockets.
Setting up websockets in production environment requires a bit of setup, because typically Jira backend is located behind a proxy server. Required proxy configurations for Nginx, Apache and AWS ELB are described below. If you are using a different proxy, please consult its documentation regarding websockets forwarding.
In addition to the usual Jira setup for Nginx proxy, you will need to configure Nginx proxy to enable websockets forwarding (in bold):
In the example above, http://jirahost is a Jira backend URL - you should obviously replace it with the actual address of your Jira.
To narrow down websockets tunelling, you can use
/com-spartez-support-chat/ws/ as the "location" and only provide websockets support for that -
/com-spartez-support-chat/ws/ is the base address of all chat's websocket endpoints within your Jira. However, it is ok to set this support globally to all proxied addresses in Jira.
In addition to the above, it is crucial that the proxy keeps the websocket connection open even when it is idle - this is controlled by the proxy_read_timeout directive - the default of which is 60 seconds. Chat keeps the websocket open by sending a "keepalive" message every 30 seconds. It is important to not set the timeout directive to less than 30 seconds. For example, you can set it to 10 minutes:
For more information about proxying websockets by Nginx, go to its documentation: http://nginx.org/en/docs/http/websocket.html.
In addition to the usual Jira setup for Apache proxy, you will beed to configure Apache proxy to enable websockets forwarding.
Firstly, you need to enable the mod_proxy_wstunnel module:
Then, set up Apache for websockets forwarding:
In the example above, is a Jira backend URL - you should obviously replace it with the actual address of your Jira. The
/com-spartez-support-chat/ws/ is the base address of all chat's websockets endpoints within JIRA - you should not change this part.
The ProxyPass statement from the config above should be the first ProxyPass in your configuration, if you have multiple ProxyPass directives, so that it does not get overriden.
In addition to the above, it is crucial that the proxy keeps the websocket connection open even when it is idle - this is controlled by the ProxyWebsocketIdleTimeout directive. Chat keeps the websocket open by sending a "keepalive" message every 30 seconds. It is important to not set the timeout directive to less than 30 seconds. For example, you can set it to 10 minutes:
For more information about proxying websockets by Apache, go to its documentation: https://httpd.apache.org/docs/trunk/mod/mod_proxy_wstunnel.html
Amazon AWS Elastic Load Balancer
- Set up JIRA for ELB, as documented in these instructions.
- When selecting the load balancer to use, pick the "Network" Load Balancer (not the "Application" or "Classic" one). "Network" load balancer is the one that natively supports websockets.
- set up security group for your Jira AWS instance, so that access to the port, on which JIRA listens for connections from the load balancer, is accessible.
- make sure that the health checks of targets user in the load balancer's target group pass (instance is considered "healthy").
- make sure that your Jira base URL points to the DNS name of your load balancer.
As per Atlassian Data Center installation documentation, the suggested load balancer is Apache. The documentation provides a sample load balancer configuration, which however will not be sufficient for enabling websockets connections to your cluster - with the sample configuration, websockets requests will fail with error 404 and chat communication will fall back to short polling.
To enable websockets connections, you need to apply changes to the sample configuration (added entries are in bold):
Crucial parts of the modified config are:
mod_proxy_wstunnel module must be loaded and enabled
additional load balancer for websockets is added - in the sample above it is called balancer://jiracluster-ws. This balancer is almost identical as the original one, but the protocols are changed from http to ws. After adding or removing a cluster node, it has to be added or removed from both the original and the "jiracluster-ws" load balancer configurations.
websocket requests (the ones going to
/com-spartez-support-chat/ws/) are passed to the added load balancer
Cloud version of Chat does not require any configuration to work with websockets.
This page has no comments.