Instead of trying to inform the sysadmin (which we did not yet try to
do in any meaningful way), inform all connected clients (even those
editing other documents).
We use 'error: cmd=internal kind=diskfull' as the message to the
clients. The loleaflet code needs to be updated to handle that
carefully by displaying a very prominent message that tells the user
that all bets are off.
Also add a unit test for the functionality.
Document the new protocol details.
The code for this alert functionalty became a bit less elegant than I
like because of the way we include Util.cpp in the unit test 'test'
program.
Still need to add code to check for disk full in more places, not just
when saving a cached tile or font. Probably we should even actually
check for disk space on the file system(s) we use getting alarmingly
low, not just check for file writing operations that fail. Later.
The missing init of mutexes is probably theoretical, the TraceFile and
the Unit ones were real errors, I think.
Change-Id: If19c23a9c93d34059998346af8d45c26a34043a6
Delaying the splitting maximizes the chances
that we will deduplicate and combine them
in the queue optimally.
Change-Id: Ib721fe7596de7ad5d34159949fe75f16e861eb24
Reviewed-on: https://gerrit.libreoffice.org/29287
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
aka: don't save invalidated tiles into cache
Tiles that are rendered when invalidation is recieved are outdated.
What we do is remember the last tile version when we get an invalidation.
This tile version, and any preceding it, is out of date and should not
get saved in the tile cache.
This fixes a race between rendering and invalidation, which happens
in the following scenario.
1. Tile requested for rendering.
2. User inputs key.
3. While tile is rendering, the tile is invalidated in Core
(the shared lock between rendering and processing input doesn't
include parsing tile request or preparing the payload back).
4. Once the tile rendering is done, but before it's encoded and sent back,
the invalidation is received on the callback.
5. Tile cache is cleared of that tile.
6. The outdated tile is received on its way to the client, saved in cache.
7. Client requests the tile anew upon getting the invalidation.
8. The tile is served from the cache, which is outdated, therefore
missing the last key input form the user.
The fix is in #3 to remember the version number of the tile being
rendered. Then in #6 we forward the tile to the client, but we
do not store it in cache. In #8 the tile request results in a new
rendering, since the cache will not have the tile. Only this last
rendering of the tile is saved in cache for future requests.
Change-Id: I0b0a3c2b917906c0d0c9046e3e6d3d4d354a7777
Reviewed-on: https://gerrit.libreoffice.org/29209
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
It's too easy to forget the Log::end when using the Log::debug() etc
API. Not sure what could be done to that. Change the logging API to be
like LibreOffice's SAL_INFO?
This is fine since there is deduplication logic
in the queue before rendering, so it's safer
to pass client requests along and rather than not.
Change-Id: I6d50fc731a273d907e178827a09e8cf9a4b8345b
Reviewed-on: https://gerrit.libreoffice.org/29163
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
And accept any version newer than expected.
Since we have proper de-duplication of tiles
requesting newer versions reduces changes of
races between client and the renderer.
Change-Id: I30bb53f98ef6f1461b53c1cf527d315dc35f7f26
Reviewed-on: https://gerrit.libreoffice.org/29125
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tile queue was used to process canceltiles commands.
Since those are handled by TileCache, there is no need
for queues and the threads that pump them.
But because these queues were also used to buffer between
WSD internals and clients, such that a slow client wouldn't
block WSD while sending back tiles, it is necessary
to reword that logic.
In subsequent commits that will change as well.
With this change not only do we save a thread per client,
but we also reduce latency of tile, and improve typing
responsiveness, by almost 3x or more! Latencies are
down to ~15ms from almost 50ms.
Reviewed-on: https://gerrit.libreoffice.org/28575
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
(cherry picked from commit 59eaacd2f8)
Change-Id: I77813267a95a724491165792ec020ae00953c05e
Reviewed-on: https://gerrit.libreoffice.org/29066
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Act as if it was always set.
The ChildSession::_multiView field will always be true, so factor it
out. Ditto for Document::_multiView.
The ClientSession::_haveEditLock will also be always true, so factor
it out. This means the ClientSession::isEditLocked() will always
return true, so factor it out, too.
ClientSession::markEditLock() always will always set _haveEditLock to
true (which it will be from the constructor already anyway) so it can
be removed.
ClientSession::setEditLock() does not need a parameter as the
parameter was actually only used for misleading logging. The msg
variable constructed in the function used isEditLocked(), not the
parameter.
We still generate and handle editlock messages. Not sure whether that
makes any sense, though.
When 2 users opened the document at the very same time, it happened that new
jails / instances were created for the document twice.
As a solution, insert a dummy (marked to destroy) document into the map of
DocumentBrokers, which will lead into synchronization between the two
instances.
[I suppose the synchronization did not work previously either, as emplace()
does not seem to modify the value when the key is already in the map.]
This breaks combine-tiles very significantly, viewing images
in documents with this appears to show each tile scaling and
rendering individually.
This reverts commit 99d0ee2ac1.
Tile queue was used to process canceltiles commands.
Since those are handled by TileCache, there is no need
for queues and the threads that pump them.
But because these queues were also used to buffer between
WSD internals and clients, such that a slow client wouldn't
block WSD while sending back tiles, it is necessary
to reword that logic.
In subsequent commits that will change as well.
With this change not only do we save a thread per client,
but we also reduce latency of tile, and improve typing
responsiveness, by almost 3x or more! Latencies are
down to ~15ms from almost 50ms.
Change-Id: I9bb5856efed28caea9d4e6f94f77b093779e5241
Reviewed-on: https://gerrit.libreoffice.org/28575
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
If core says that document save operation failed because document
was in unmodified state, don't upload to storage (hence no
revision)
Change-Id: I47fbc8a7bc632bb7977d263d697d665161f3b076
Specified when websocket is initialized. Documents once
opened in readonly mode cannot edit throughout the life of the session.
This is very much like present view mode except the ability to
change to edit mode.
Change-Id: I176e3bbf210c3383268d1a5b50dc17f0cbfb26b8
Tile invalidation and painting can race with one another.
A race when the user types two characters in quick succession:
1. After the first key press, the tile is invalidated.
2. The client request the tile on receiving the invalidate.
3. TileCache doesn't find it, and adds subscription.
A. Sometime before rendering, the second key press is received.
B. This invalidates the very same tile.
C. The client request the same tile.
D. TileCache finds a subscription and ignores the new one.
4. The tile is rendered and sent back.
5. Subscription is found and the tile is forwarded to clients.
6. Subcription is removed as the request is fullfilled.
E. The second tile is rendered and sent back.
F. TileCache finds no subscription and the tile is dropped.
End result: Only the first character appears on the screen.
Versioning fixes the above situation by making sure that in
step 5 the subscription will show to belong to a different
(and newer version) and so the tile will be ignored.
Instead, at F the TileCache will find both subscription
and a matching version and the lastest version will always
be sent back to the client.
Change-Id: I7d7fe1407cda1908d794683c3ce4c2fd18609a2f
Reviewed-on: https://gerrit.libreoffice.org/25341
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tiles can be rendered in large batches and sent back
as combined payloads, all reduce latency and overhead
significantly.
Initial tests show a reduction in total latency by 2x.
This without sending tiles back to the client in combined
form, which will reduce latency further.
Change-Id: Iee06503f2a6c741fadb2c890266ea514c809c0dc
Reviewed-on: https://gerrit.libreoffice.org/25339
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
