The main purpose of this time-out is to avoid waiting forever for lost
tile messages, but since it rare to loose them we can use bigger value,
so we can avoid to send new tiles to a slow network.
Note that the used time stamp does not mean the time when the tile
actually send to the client, but the time when it gets to the sender
queue.
Change-Id: I230d85c38b3a5dafd195851d0cf4caac23149e3e
There valid cases when we get unknown tileID. For example we
sent some tiles, but in the meantime canceltiles arrives which
resets tiles-on-fly list, but the client still send tileprocessed
messages for earlier requested tiles.
Change-Id: If2ec015106a0e58d66ae4517b64a9552eb8c38fc
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
Re-think Linux vs mobile ifdefs a bit. Use #ifdef __linux only to
surround code that actually is Linux-specific. Use #ifdef MOBILEAPP
for code that is for a mobile version (with no separste wsd, forkit,
and kit processes, and with no WebSocket protocol used).
Bypass UnitFoo for mobile. Possibly we do want the UnitFoo stuff after
all on mobile, to run in some special testing mode? Hard to say, let's
skipt it for now.
So we can avoid that tile sending stop working because server is
waiting for tileprocessed messages which will not arrive.
Change-Id: I545346c50d49340999608aadac32b5190ede43c5
A problem comes up when only a part of the tile is visible
on the client side and invalidation affects the invisible
part of this tile. To get back the old / right behavior we
need to request this kind of tiles too.
This reverts commit f1a385be98.
It's not easy, it can interfere the tile tracking.
Change-Id: I1e4ec9b4d66e5e912873f673fd5cb71ba55a9332
Reviewed-on: https://gerrit.libreoffice.org/59326
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
No need to keep such a cache here. The consumer of previews
(thumbnails) in question does it itself (Nextcloud).
This reverts commit 405b66c8db
Change-Id: Iad16212ccbc875fe4f6d041e2fceef7eaea1d1bb
Store the tile cache names and drop outdated tiles
times to times, so we can avoid tile rendering / sending to
stuck.
Change-Id: Ibff001307c7c660cbc57ab20c29c430e0090444d
I used number 25 as this limit. It's an approximate value. It's enough
to handle the first 5-10 character input without waiting for tileprocessed
messages. After the first 5-10 characters the tileprocessed messages are
arriving continuously (same frequency as the typing speed), so for the later
character inputs we always have some tileprocessed messages arrived so
we can push new tiles to the network again.
This 25 upper limit also seems enough to send all tiles when a whole page is
requested (e.g. zoom os scroll).
We store the requested tiles in a list, used as a queue. I don't use std::queue
because sometimes we need to do deduplication (replace older versions of the
same tile with a newer version).
Change-Id: I22ff3e35c8ded6001c7fc160abdc1f1b12ce3bae
We always one bunch of tiles (e.g. all tiles invalidated) and we
are waiting until client send tileprocessed message back for all
tiles before sending the new tiles.
By canceltiles message we drop every previously requested tiles and
make wsd ready to send new tiles, which will be requested by the client
in theory.
Change-Id: I9901420ada549e962ffaf5e6bd58e52b86bd129d
When asked to "convert" a document to a PNG image, i.e. what one can
call a thumbnail, check if we have a cached PNG for the same docuemnt
already, and in that case return it.
When we have done such a convert-to operation to PNG, save the result
in the cache for later re-use.
This change adds no thumbnail cache cleanup mechanism. That will have
to be implemented separately using a cron job or whatever.
There are further improvement possibilities: For instance, if the
document is of a type that contains an embedded thumbnail (like ODF),
just extract and return that. For ODF that embedded thumbnail even
already is in PNG format.
Change-Id: I882efe97acc1d81041dc7a4ccb222995940e4836
Reviewed-on: https://gerrit.libreoffice.org/57345
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Log all error: cases in ClientSession::handleKitToClientMessage(), not
just the case of cmd=load with kind= some password failure.
Change-Id: I53c959068f5642ae41157e8feb14fd34fc59dc9a
Since changing the tracking state is done by toggling,
we need to wait to get the current state at load time
before we can tell whether we need to toggle it or not.
Change-Id: Ib5a2639b2acf3874c191971eedf9a3bebcefebad
Reviewed-on: https://gerrit.libreoffice.org/53415
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Otherwise saving is bound to fail, causing other
errors, which is nonsensical since there is nothing
to save to begin with.
Change-Id: Icb65a4a3b277b3175aadbe5107b294b24a399e7b
Reviewed-on: https://gerrit.libreoffice.org/50148
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Asking the doc broker to close means that it will save the current
document to storage before shutting down. But we don't want that because
storing the current document to storage means overwriting the document
which has been changed underneath us.
Change-Id: I8df45d2f0cf3f65936dc3030f483e52fd1703146
Reviewed-on: https://gerrit.libreoffice.org/49134
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
Now always given a proper reason too.
Also, stop polling thread and cleanup when
failing to acquire/spawn a child process.
Change-Id: I7ddee01dd47b8ee72f2d9134c0f1b264634d8611
Reviewed-on: https://gerrit.libreoffice.org/47886
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Maintaining a flag is problematic, at least the way
it was reset on adding new sessions. Luckily there
should be no reason for having it, since we should
check it only when removing sessions. Also, we
need to check for every case of removal, and not, as
was, just on disconnection, which is incomplete.
Change-Id: I878766701228c41fc93eeaff21852fa887de9eff
Reviewed-on: https://gerrit.libreoffice.org/47883
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
