Unexpected message id from the client (sync ids different) #12640
Comments
|
Currently I find this issue ~10-20 per day in my logfile. Unfortunately I have no idea where this is coming from. The problem is that everytime a error message is shown to the user... |
|
I activated the debug logging, and got the following (unfortunately no special information):
|
|
Additional info: Once today I got the following message:
and some milliseconds after "Unexpected message id from the client. Expected sync id: 2, got 1. more details logged on DEBUG level." the following:
|
|
Without only this information it would feel like one server message to the client is lost as the server should for each response send a syncId that it expects the client to have in the next request. In short: Without any way to reproduce this is really hard to investigate. @Legioth would you have any ideas on how @thomaskiesl could try to investigate the issue on their end? |
|
Does anyone have an idea how to find this out? I got this message every day multiple times? Additional logging? |
|
There's supposed to be some additional information about the message payload after There are a couple of possible causes for why old sequence numbers would show up unexpectedly. Finding out the cause is usually very difficult without a good way of reproducing.
|
|
@Legioth I recevie for example the following info within the debug file: |
|
I'm experiencing this issue too, same vaadin version |
|
Also getting this on Vaadin 14.7.0. Upon getting this it leads to an internal error page on the UI. I was able to replicate it by setting up a Chrome network throttling profile with a Download of 100 kbits/s, Upload of 50 kbits/s and a latency of 500. Then I quickly clicked on a paged table's paginator so that it would change pages and data being fetched and from time to time clicked on a row on the table. After a minute or so the UI went blank while the server log showed Before that I also see some messages in the logs. Issue seems to be related to #9778 |
mshabarov
moved this to 🔖 Normal Priority (P2)
in Vaadin Flow bugs & maintenance (Vaadin 10+)
|
I'm using Vaadin 24.2.3 with Java 21, SpringBoot 3.2 and Spring Framework 6.1 (on macOS Ventura 13.5) and still see this issue: Any news on this? Cheers, |
|
Same problem here on JDK17, vaadin 24.1.11, SB3.1 - fairly trivial application. 20% of e2e-Tests fail randomly with something similar to |
|
Same issue for me on vaadin version= 24.2.6 and springboot=3.0.6 |
|
Same issue for me. |
|
We have the same issue. It randomly occurs after logging in when opening the first UI after Login. Interestingly the Message Start output ist empty. When debugging I see that the rpcArray is empty which causes the debug output to be empty.
It just happens on one application and I can't find the difference that causes it. |
|
We have the same issue. Java: 17 |
|
Same Issue here, makes the Web basically unusable... |
|
Any updates on this? Many of my users are not happy with this situation!? |
mshabarov
added
Impact: High
Severity: Major
and removed
Impact: Low
Severity: Minor
labels
mshabarov
moved this from 🔖 Normal Priority (P2)
to 🔖 High Priority (P1)
in Vaadin Flow bugs & maintenance (Vaadin 10+)
|
Thanks, we can rule out most of these items for our situation given that it's rather sporadic. Naive thought: if server is at id 30 and client sends id 32, can it not be implemented so that the server in response can ask for a resend of 31? Slippery slope I know. |
That's basically what we suspect we would have to end up doing with two additions:
|
To be precise, the buffer would not fully eliminate the need for resync occasionally, but would reduce likelihood of the occurrence. I would assume it would reduce with great amount as what I have seen, in most typical cases it would be enough to retain just the previous one in the memory. Naturally, the size of buffer could be configurable. |
|
No need to configure anything. The buffer can just contain everything that hasn't yet been "confirmed" through receiving another message from the other side with an incremented id. Maybe there should also be some upper bound to catch weird cases where more messages are produced without anyone handling but I still don't see why it would need to be configurable. |
|
After migrating from V24.3 to V24.5 I'm getting this error more frequently It never occurred when I was in V24,3. Since it is more frequent but not always, I do not know what is causing this issue after the upgrade |
|
The complete error stakc is
|
|
I'm trying to upgrade from 24.3.7 to 24.5.1 and this problem breaks the login page. I see something like |
…avigation (#19983) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state.
…avigation (#19983) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state.
…avigation (#19983) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state.
…avigation (#19983) (#20449) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state. Co-authored-by: Marco Collovati <[email protected]>
…avigation (#19983) (#20448) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state. Co-authored-by: Marco Collovati <[email protected]>
…avigation (#19983) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state.
…avigation (#19983) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state.
…avigation (#19983) (#20455) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state.
…avigation (#19983) (CP: 2.11) (#20456) * fix: delay session expiration handling to prevent canceling ongoing navigation (#19983) Attempts to fix the synchronization issue related to the usage of the Login reported in #12640. The Login component sends the UIDL request for the login event to the server and concurrently submits the form. If processing the form submission performs a session ID change and a request redirect, the UIDL requests might fail with a session expiration response. The Flow client then can cancel the first redirect because it reloads the page due to the session expiration. Lastly, the beacon request hits again a valid session, but a resynchronization is triggered because the previous UIDL request was rejected. This change delays a bit the session expiration handling on Flow client, to allow a potential redirect to complete without being cancelled. However, the client application is immediately set in TERMINATED state. * fix
|
We also see this in our production systems, and I want to share our findings. It happens rarely, not reproducible, but since we have so many users, we see it several times per hour. The bigger part comes during end of session, the RPC typically contains "UNLOAD":true (as written above by ssindelar). This is probably nothing which affects users. But we also have a significant number of events when this happens in the middle of users' work. Server e.g. receives id=91, but expects id=90. We have hacked code into ServerRpcHandler, when this situation is detected, we temporarily unlock the session, and let the thread wait (with some timeout) on a sync object. So it looks like client does not strictly enforce sequential processing of messages, it sends out request #91 before answer for #90 has been received. We use XHR as communication mechanism. |
|
@Manfred-on-github Yes, with WebSocket_XHR upstream is WebSocket and downstream HTTP, i.e. asymetric protocol, thus order of arrival not ensured by protocol. For this reason we have maxMessageSuspendTimeout configuration parameter, which is by default 5 seconds. You can configure it to be longer, as apparently your network infrastructure has some delay. This can be for example due firewall / VPN packet inspection slowing the communication. Check this comment for more info #12640 (comment) and documentation of maxMessageSuspendTimeout here: https://vaadin.com/docs/latest/flow/configuration/properties#properties |
|
We see this all the time and have determined it is due to poor connection on the client side. A lot of our users, across multiple of our webapps, have less-than-ideal internet connections. It would be useful if a custom subclass of |
What does "properly handle" mean in you case? Just log and ignore or are you also carrying out some other action? |
Which kind of condition you have there. Is it just flaky, or is it bandwidth problem? If it is just flaky, the proposed caching mechanism #20348 could help. If it is bandwidth problem, then it requires application design changes to take the limited bandwidth into account. |
and others
Description of the bug
I receive sometimes the same error message on my production system. But I do not have any idea when this happen:
2021-12-27 07:27:43,174 INFO | https-jsse-nio-18443-exec-10 | com.vaadin.flow.server.communication.ServerRpcHandler | Ignoring old duplicate message from the client. Expected: 1748, got: 1747It seems it is the same bug as #9778
Minimal reproducible example
Unfortunately I'm not possible to reproduce the issue. I only find the messages in the logfile.
Versions
The text was updated successfully, but these errors were encountered: