There might be pending requests in the queue when a resync request is
made (e.g. through a theme change). This can cause conflicts if the
resync request is handled immediately. Therefore the resync request
should also be added to the queue and only get resolved when
doSendInvocationsToServer() gets triggered again.
Fixes #11954
Fixing issue with Push stopping working in some circumstances (#11791)
* Fixing issue with Push stopping working in some circumstances
If new request is attempted when resynchronization is ongoing, the Push will stop working. This patch fixes the issue by aborting handleJson if resynch is already ongoing.
This PR supercedes https://github.com/vaadin/framework/pull/11786
Fixes #11702, #7719
* Call onResynchronize() in MessageHandler
* Optimizing
* Add grace period for showing the reconnect dialog
* Try to reconnect once immediately
* Stop reconnecting when application is stopped
* Make it possible and easy to replace the reconnect dialog
Change-Id: I6695e7473859827db9dd64cbd373696aeb5d27a5
Use same reconnect logic for Push as for XHR (#17075)
* No longer queue message separately in PushConnection
* Use XHR for client to server communication when using long polling (or streaming)
* Websocket is used for communication in both directions
Note that using XHR for client to server responses at the same time
as a push connection is open means we must take into account on the
client side that we may receive message in the wrong order. This
will be addressed in the following change.
Change-Id: I97706db3481379593e71dc5bb552727a0486692b
* XhrConnection internally manages the URI to send to
* send(JsonObject) now only takes the payload
* retry logic for status 0 removed for now
Change-Id: Ieca25df0ebe06773139b2bec7e9a2586df77b24d
Use counter in client to server messages to avoid duplicate handling (#11733)
An server message id counter is included in every client to server message and an
expected id is included in every server to client message. This makes it safe to
re-send any message when the client is not 100% sure the server has received the
message, without having to worry about double handling on the server side.
Change-Id: I840cc04829fc2491f35a0e6f98f07eaf46b1ea42