[Bug] Significant Delay To Load More than 6 Tabs

[monokle]

Work Environment

|OS version (server) | Ubuntu 18.04.4 LTS | OS version (client) | Mac 10.14+/Windows10 | TheHive version / git hash | 3.4.2-1 | Cortex verison | 3.01-1 |ElasticSearch | 6.5.2 |Elastic4s | 6.5.1 |Package Type |From source | Browser type & version | Chrome v83.0.4103.116 |Hardware Specification. | 8cores with 32GB memory

Problem Description

The issue we experience is that whenever a given user attempts to open more than 6-10 tabs while authenticated to Hive, the remaining tabs take approximately a 50 seconds to load.

For example if I open 14 cases in 14 tabs, the first 6 will load immediately. The remaining 8 will be stuck loading for about 50 seconds and then all load simultaneously. I should note that the number sometimes varies 5-10 but seems in most cases to occur on 6.

Steps to Reproduce

1. Visit the Case manager console https://[yourdeployment.com]:900/index.html#!/cases
2. Open 6+ cases in separate tabs

Possible Solutions

I have attempted to change the setting in the application.conf file, specifically I edited the following values to be greater or lesser than their default values:

play.http.parser.maxMemoryBuffer= 1M
play.http.parser.maxDiskBuffer = 1G

I also added a snippet from the documentation

# Streaming
stream.longpolling {
  # Maximum time a stream request waits for new element
  refresh = 1m
  # Lifetime of the stream session without request
  cache = 15m
  nextItemMaxWait = 500ms
  globalMaxWait = 1s
}

It appears as though tab loading gets batched but I am unable to change the batch size (assuming that's what's happening). Any thoughts to help improve the speed of loading more than 6 tabs is appreciated. Thank you.

[nadouani]

Hello @monokle

Well TheHive is a single page application that does a significant amount of queries to make the UI reactive

• Your lists are reloaded whenever another session updates the data you are displaying
• The flow is updated on actions that happen on other's sessions

If you open 14 tabs, then whenever someone makes a change, all the 14 tabs will make calls to refresh themshelves.

I try to understand the use case where you need to open 14 tabs.

[monokle]

Thank you for the response and your response explains the behavior we're seeing. To your question, the use case here was an analyst opening say 14 cases so they could quickly move from one case to next as they resolve them. This occurs for example when we receive a large number of phishing reports but they were all false positives. In this event every case should be looked at but the decision to resolve is fairly quick.

Happy however to take feedback if this workflow was a misuse case. Thank you again.

[miyoyo]

Might be unearthing something a bit here, however, the explaination for this problem is quite simple:

As documented in the documentation for EventSource, only 6 simultaneous connections are ever allowed to a domain at once, since each tab opens one connection for long polling, anything beyond 6 tabs will cause issues. (Technically 5 tabs can also be an issue).

This is not due to the server being slow or "overloaded", if you have multiple browsers installed on your computer, or just multiple simultaneous hive users, there is no significant slowdowns, yet you can have over 20 (combined) tabs on a relatively weak server with no issues.

Fixing this issue is not trivial, as the problem here is the number of total connections. HTTP/2 could help if it shared a single connection across multiple tabs, but I cannot prove nor disprove that. Otherwise, timer-based polling instead of long polling would prevent the issue entirely, but it could require significant work to retrofit.

@nadouani, one use case for having many tabs open is queueing work, when you have to more than a few similar tickets, it's convenient to open them all up in tabs and just switching to the next tab as you finish reviewing one.