Long polling solves situations when the user is forced to periodically click on refresh of the table to see the current data. Long polling ensures page refresh automatically, without user interaction.
The easiest way to achieve automatic renewal is to periodically polling the client. The period of these requests must be as short as possible (seconds). This implies a major disadvantage of short polling and this is a large number of requests to the server.
Long polling works differently:
While holding a long polling request, it is periodically evaluated whether the entity has changed. This typically means that every 2 seconds, all deferred requests are evaluated for any change. To correctly detect that a change has occurred, it is necessary to maintain certain metadata from the previous run. These metadata are the time point of the last entity change (change / create detection) and the last known number of entities (delete detection). These metadata are stored in memory as a subscriber map, where the key is the entity identifier.
Each time a change is verified, each subscriber is marked with a timestamp when the last verification occurred. If the user navigates to another page, there will be no additional long polling requests. Thus, the deferred requests will expire and the time stamp will not be renewed at the customer. Every two hours, the LongPollingManager.clearUnUseSubscribers
method is automatically scheduled to remove any subscribers that have not been used in the last hour.
The biggest disadvantage of Websockets is the use of its own non-HTTP protocol. These ports can often be blocked by customers and therefore Websockets cannot be used.
For now is long polling implemented these agendas:
Do you really need WebSockets?
Using SSE Instead Of WebSockets For Unidirectional Data Flow Over HTTP/2
LongPollingManager
IdmIdentityController
SysSystemController