Reduces the number of WOPI calls made during a document load. Earlier
effort was made in edfd3266f8
This commit cleans up and uses better approach for the same.
Other than that, access token of each session is now correctly
used when interacting with the storage. Earlier, we used to
use the same access token for each upload to storage which means
that irrespective of who clicked the save button, changes to the
document were only made on behalf of one person (of whom the
access token is used). This is fixed now.
Also includes minor cleanup left and right.
Change-Id: Id32702ff02aea4f63b7cc6afa9f62664807bb57d
Reviewed-on: https://gerrit.libreoffice.org/29931
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This reduces the number of fileinfo calls made to storage. These calls can
be expensive in storage such as WOPI where loolwsd needs to
interact with another server to get the file information. Use the
same storage object once created so that fileinfo can be
cached and returned quickly for subsequent such calls.
3 GetFileInfo WOPI calls are now merged into 1.
Change-Id: I56c3d23d3d6d7dc3a4b42433f51304dac28a12e8
Using a new internal command, when a client disconnects
an internal 'disconnect' message is dispatched so
the child process cleans up the ChildSession in question.
Change-Id: I34166ad59e84ae389a3913bd2430fe537225bb4b
Reviewed-on: https://gerrit.libreoffice.org/29650
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
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>
