Excessive polling for status in Incidence Rates

[anthonysena]

Expected behavior

When viewing the results of an Incidence Rate, I expect that the polling is only done when there is a source actively generating.

Actual behavior

Polling for information happens even though nothing is running.

Steps to reproduce behavior

Generate an IR on a source. Once complete, navigate to the generation page. With Chrome Dev tools open, note the network traffic. On my side, the end point /WebAPI/ir/<id>/info is hit ~5 sec.

Side effect

I've observed that sources generated from an IR disappear from time-to-time and it may be related to this problem if there is a delay in getting a response from WebAPI. Just noting it here since it may be related.

[pavgra]

I expect that the polling is only done when there is a source actively generating.

@anthonysena , I'd not forget about a case when another user can kick off execution and we need to reflect this in a current user's window. Specifically for this situation, we continue polling even when a user hasn't initiated a new job and all current ones are completed

[anthonysena]

Fair enough @pavgra - let me move this to the 2.8 milestone for consideration for that release since this doesn't appear to cause any bugs (best I can tell).

You bring up a good point with respect to other users starting jobs. I'm wondering if we can leverage the existing notifications polling to handle this case across the app instead of having the analysis specific polling? Meaning: you poll when you are actively running one of your own jobs and then leverage the notifications polling to identify jobs that are kicked off by other users for the same analysis?

[pavgra]

Going via notifications is a bit tricky since in secure mode a user observes personalized notifications and doesn't see all the activities going in the system. I would discuss not a logical but technical way to improve the situation: web sockets.

[pavgra]

My overall proposal is to replace polling with websockets

[pbr6cornell]

Replacing polling with websockets sounds like a code re-design, which may be good idea, but perhaps best reserved for ATLAS 3.0, unless we believe current polling approach represents either a bug or a performance problem.