You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using reloadOnReconnect, and the client disconnects, we keep a cache for each active socket channel, with a 100kB buffer. Once this buffer is full, an error is thrown:
Max disconnected buffer size exceeded by adding 50186 bytes
Then, the same error is repeated whenever a message is posted to this same channel, which results in a potentially heavy log spam. Moreover, the classes involved use protected methods, but are not actually exported, making it difficult to fix in specific applications (or to increase buffer size, etc).
I think we need two steps to improve this:
only log the error once per SocketWriteBuffer instance
open the API a bit, so this can be customized in specific apps
Steps to Reproduce:
Note: the bug can be difficult to reproduce in Theia, because you need to hit the 100kB buffer limit with a single service, before the disconnected client session expires and the buffer is closed. This means that, with the default settings, you have 30 seconds to fill 100kB with a single service, which probably won't happen under normal conditions. This could however easily happen e.g. during a large build, which will generate many file system events.
Increase the frontendConnectionTimeout to a higher value, so the buffer isn't cleared too quickly (e.g. 1800000 for 30 minutes). This gives more time to reproduce the issue
Load the Theia application, then refresh the tab in your browser. This will create two frontend sessions: one for the initial page, and one for the refreshed page. The initial session will use a SocketWriteBuffer and fill it with messages; the refreshed session will work as expected.
Copy-paste deep folder hierarchies in the Explorer multiple times. This should generate enough messages to fill the buffer quickly with /services/remote-filesystem change notifications.
Observe the backend logs: Max disconnected buffer size exceeded by adding ... bytes will be logged many times, and logged again for every update after that
Additional Information
Operating System: any
Theia Version: >= 1.45 (reconnect behavior), tested on 1.45.1 (custom app) and 1.48.0 (Theia example browser app)
The text was updated successfully, but these errors were encountered:
- avoid logging the same error multiple times in SocketWriteBuffer.
throw once, then silently ignore following issues.
- export ReconnectableSocketChannel to make buffer customization easier
for applications
refs eclipse-theia#13662
Signed-off-by: Camille Letavernier <cletavernier@eclipsesource.com>
Bug Description:
When using reloadOnReconnect, and the client disconnects, we keep a cache for each active socket channel, with a 100kB buffer. Once this buffer is full, an error is thrown:
Max disconnected buffer size exceeded by adding 50186 bytes
Then, the same error is repeated whenever a message is posted to this same channel, which results in a potentially heavy log spam. Moreover, the classes involved use
protected
methods, but are not actually exported, making it difficult to fix in specific applications (or to increase buffer size, etc).I think we need two steps to improve this:
Steps to Reproduce:
Note: the bug can be difficult to reproduce in Theia, because you need to hit the 100kB buffer limit with a single service, before the disconnected client session expires and the buffer is closed. This means that, with the default settings, you have 30 seconds to fill 100kB with a single service, which probably won't happen under normal conditions. This could however easily happen e.g. during a large build, which will generate many file system events.
1800000
for 30 minutes). This gives more time to reproduce the issueSocketWriteBuffer
and fill it with messages; the refreshed session will work as expected./services/remote-filesystem
change notifications.Max disconnected buffer size exceeded by adding ... bytes
will be logged many times, and logged again for every update after thatAdditional Information
The text was updated successfully, but these errors were encountered: