Use queue for resync requests. #12043
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 vaadin#11954
OlliTietavainenVaadin
approved these changes
Jul 30, 2020
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1.
Reviewable status:complete! all files reviewed, all discussions resolved
TatuLund
added a commit
that referenced
this pull request
Jan 5, 2021
#12043 changed resync message sending to be deferred to queue. Now also the setting of the semaphor in message handler needs to be deferred to its right place. Otherwise there is possibility for a timing glitch. I.e. MessageHandler is set to resync handling mode before message is actually send. Fixes: #12151
Ansku
pushed a commit
that referenced
this pull request
Jan 7, 2021
…12178) #12043 changed resync message sending to be deferred to queue. Now also the setting of the semaphor in message handler needs to be deferred to its right place. Otherwise there is possibility for a timing glitch. I.e. MessageHandler is set to resync handling mode before message is actually send. Fixes: #12151
Ansku
pushed a commit
that referenced
this pull request
Jan 22, 2021
…12178) #12043 changed resync message sending to be deferred to queue. Now also the setting of the semaphor in message handler needs to be deferred to its right place. Otherwise there is possibility for a timing glitch. I.e. MessageHandler is set to resync handling mode before message is actually send. Fixes: #12151
Ansku
added a commit
that referenced
this pull request
Jan 22, 2021
…12178) (#12184) #12043 changed resync message sending to be deferred to queue. Now also the setting of the semaphor in message handler needs to be deferred to its right place. Otherwise there is possibility for a timing glitch. I.e. MessageHandler is set to resync handling mode before message is actually send. Fixes: #12151 Authored-by: Tatu Lund <[email protected]>
mshabarov
pushed a commit
to vaadin/flow
that referenced
this pull request
May 19, 2022
…13733) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve
vaadin-bot
pushed a commit
to vaadin/flow
that referenced
this pull request
May 19, 2022
…13733) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve
vaadin-bot
pushed a commit
to vaadin/flow
that referenced
this pull request
May 19, 2022
…13733) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve
vaadin-bot
pushed a commit
to vaadin/flow
that referenced
this pull request
May 19, 2022
…13733) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve
mshabarov
pushed a commit
to vaadin/flow
that referenced
this pull request
May 19, 2022
…13733) (#13806) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve Co-authored-by: Tatu Lund <[email protected]> Co-authored-by: Artur <[email protected]>
mshabarov
pushed a commit
to vaadin/flow
that referenced
this pull request
May 19, 2022
…13733) (#13804) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve Co-authored-by: Tatu Lund <[email protected]> Co-authored-by: Artur <[email protected]>
mshabarov
pushed a commit
to vaadin/flow
that referenced
this pull request
May 20, 2022
…13733) (#13805) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve Co-authored-by: Tatu Lund <[email protected]> Co-authored-by: Artur <[email protected]>
|
This ticket/PR has been released with Vaadin 23.1.0.rc2 and is also targeting the upcoming stable 23.1.0 version. |
mshabarov
pushed a commit
to vaadin/flow
that referenced
this pull request
Jun 10, 2022
…13733) (#13805) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve Co-authored-by: Tatu Lund <[email protected]> Co-authored-by: Artur <[email protected]>
taefi
pushed a commit
to vaadin/flow
that referenced
this pull request
Jun 10, 2022
…13733) (#13805) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve Co-authored-by: Tatu Lund <[email protected]> Co-authored-by: Artur <[email protected]>
ZheSun88
pushed a commit
to vaadin/flow
that referenced
this pull request
Sep 21, 2022
…13733) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve
mshabarov
pushed a commit
to vaadin/flow
that referenced
this pull request
Sep 22, 2022
…13733) Process re-sync messages via normal message queue and use semaphore to protect re-sync process (i.e. do not allow other messages while performing re-sync). This PR is adopted from similar fixes for Vaadin 8. vaadin/framework#11791 vaadin/framework#12043 vaadin/framework#12178 This also changes the method `forceMessageHandling` in a way that the desire to resynchronise is registered before calling `endRequest`. If this is not done, `endRequest` may end up sending out a request itself and that then causes the re-sync request to fail because a request is already in flight. This ends up throwing an IllegalStateException at com/vaadin/client/communication/RequestResponseTracker.java. Fixes #13726 Co-authored-by: Artur <[email protected]> Co-authored-by: Pepijn Van Eeckhoudt @pepijnve
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
This change is