This adds a new config option to enable/disable
experimental features and behavior. The default
value can be controlled at build time by
--enable-experimental.
Change-Id: Iffcb4c71d9e0933a646251b63033b6dadcd3b809
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
To avoid writing (saving) while reading (uploading) or
any other undesirable racse on the document file,
we atomically rename the file after saving on disk
to pass ownership.
After saving in Core, we rename the document in the
jail to .upload (by appending it). DocumentBroker
looks for the file with that extension and atomically
renames it to .uploading (by appening the 'ing' suffix).
This way, the Kit only renames from the original to
.upload and DocBroker renames only .upload to .uploading.
This guarantees that we never rename the same file
concurrently.
Uploading decision is strictly based on the modified
timestamp of the .uploading file, compared to the
timestamp of the last file we uploaded successfully.
Change-Id: I03520cd8c87605f6dad417e7a978204f76fc0c38
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
User-Agent is designed for client-side use only,
in http requests. For servers, the Server header
is designed to announce the server name and version.
This tries to normalize the use and documents
the proper intent and usage.
Change-Id: I42d68d65611cab64c45adf03fe74f9466798b093
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
The use of a common threadname suffix in the WSD and Kit
processes is intentional. It is designed to help filter
for a single document's logs across both processes.
The thread name has nothing to do with the classes in
the code, nor is it intended to imply any relationship
except with the process and the document in question.
As the comment in this patch explains, the choice of
the suffix is arbitrary and while it may be changed,
it has to be sensible and common between the two threads
to allow for easy grepping.
Historically, there were in fact dedicated threads
within the respective "broker" classes, but this
fact should be safely ignored, since at the log level
we care less about which part of the code generates a
log entry (that info, if needed, is at the end of each
log entry, in the form of filename and line number),
rather we care more about which document it relates to,
which is crucial in investigating production issues.
Logs and code structure are only incidentally related.
Logs are (or at least should be) designed around
the execution structure, not code architecture.
(This reverts 2a16f34812)
Change-Id: Ic6fe2f9425998824774d2644fe4362e75dea6b88
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/101261
Tested-by: Jenkins
Tested-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
loolmount now works and supports mounting and
unmounting, plus numerous improvements,
refactoring, logging, etc.. When enabled,
binding improves the jail setup time by anywhere
from 2x to orders of magnitude (in docker, f.e.).
A new config entry mount_jail_tree controls
whether mounting is used or the old method of
linking/copying of jail contents. It is set to
true by default and falls back to linking/copying.
A test mount is done when the setting is enabled,
and if mounting fails, it's disabled to avoid noise.
Temporarily disabled for unit-tests until we can
cleanup lingering mounts after Jenkins aborts our
build job. In a future patch we will have mount/jail
cleanup as part of make.
The network/system files in /etc that need frequent
refreshing are now updated in systemplate to make
their most recent version available in the jails.
These files can change during the course of loolwsd
lifetime, and are unlikely to be updated in
systemplate after installation at all. We link to
them in the systemplate/etc directory, and if that
fails, we copy them before forking each kit
instance to have the latest.
This reworks the approach used to bind-mount the
jails and the templates such that the total is
now down to only three mounts: systemplate, lo, tmp.
As now systemplate and lotemplate are shared, they
must be mounted as readonly, this means that user/
must now be moved into tmp/user/ which is writable.
The mount-points must be recursive, because we mount
lo/ within the mount-point of systemplate (which is
the root of the jail). But because we (re)bind
recursively, and because both systemplate and
lotemplate are mounted for each jails, we need to
make them unbindable, so they wouldn't multiply the
mount-points for each jails (an explosive growth!)
Contrarywise, we don't want the mount-points to
be shared, because we don't expect to add/remove
mounts after a jail is created.
The random temp directory is now created and set
correctly, plus many logging and other improvements.
Change-Id: Iae3fda5e876cf47d2cae6669a87b5b826a8748df
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92829
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
LibreOffice core uses that, too, and we support an even more
restricted set of compilers.
Change-Id: I0d0e2c8608e323eb5ef0f35ee8c46d02ab49a745
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92467
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
The initial child spawning takes significantly longer
than subsequent ones (for obvious reasons) and this
lead to unit-tests being sensitive to the timeout
we use for child spawning. Too short, and we
spawn more than we want on startup, too long
and crash-recovery tests fail (we don't
recover fast enough, as we wait too long before
spawning new children).
Dynamically setting the timeout allows us to give
longer timeout at startup, and reduce it afterwards.
Reviewed-on: https://gerrit.libreoffice.org/81194
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 32fa1d95fc2ec65866d0cb47d619885182db7040)
Change-Id: I8423f5c6619e57030ab43d519aaa41d8712c36d3
Reviewed-on: https://gerrit.libreoffice.org/81570
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
We need to give the child more time than we
poll, so we would get a chance to register
prespawned children before we account for
any missing ones. Also, allowing only 5
seconds risks spawning too many children
on a slow, or somewhat loaded system.
This raises the child timeout to twice
the poll timeout, which is 5 seconds,
allowing for 10 seconds for spawning.
Change-Id: I4cc9e2fc656268fa82a935a5cb1626540bd49980
Reviewed-on: https://gerrit.libreoffice.org/80322
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit afb96fcbad4e36ef4eb07bf6d0b67329b714858e)
Reviewed-on: https://gerrit.libreoffice.org/81560
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Unix Domain Sockets are inaddressable remotely, and more efficient,
as well as allowing future SCM_CREDENTIALS / SCM_RIGHTS.
Change-Id: Ia2472260f75feb43e9022cdfa0fe005ccd489454
Add an entry to discovery.xml with the urlsrc where capabilities end
point can be found. Use json format to send back the feature list.
Change-Id: I390a53d956d53ca79e5a8090aead7f4131ec4ca0
We try to decrease the network usage with avoiding sending out
to much tiles to the client. When we already sent out two versions
of the same tile without having the tileprocessed message from the
client we delay sending out the next version to avoid spamming tiles
on the network.
Change-Id: Ia47cd7c0d3fb829f6777f0c3265970433591df19
POST requests require the full request to be
left in the socket buffer to be parsed in full.
But GET requests, especially WS upgrade, must
have the request cleared from the socket, as
there is more data expected to be read after
the upgrade, which happens by the DocBroker
thread, so clearing the buffer must be done
before the upgrade.
This patch accomodates these two conflicting
cases and refactors the code slightly to
make it more structured and readable.
Change-Id: Ia7357a745a3900f986099ba14af2a0946023018b
Reviewed-on: https://gerrit.libreoffice.org/36873
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This was a workaround to Poco's limitation
of requiring socket receiveFrame be given
preallocated buffer, which couldn't be
exceeded by a larger payload. This meant
the receiver had to know the maximum
payload in advance.
Since only the Kit uses Poco sockets,
and the Kit never receives large payloads,
this preamble is now obsolete.
100% (94/94) of old-style tests PASS.
Change-Id: I76776f89497409e5755e335a3e25553e91cf0876
Reviewed-on: https://gerrit.libreoffice.org/36037
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
These are really GET requests that aren't
WebSocket upgrade. Should rename to something
less misleading.
Re-enabled testSlideShow which depended on this.
Change-Id: I52b7f67b650fcdcbae7c2bff020b756099263141
Since we always need to set the thread-pool size
anyway, we cannot have 'unlimited' connections.
Actually, we never did, so that was misleading
in configure.ac anyway.
The current defaults are 20 connections and
10 documents, instead of the previous 1024
connections.
The reason for this "low" limit is to
enable unittesting these limits automatically
for the default configure.
There is also a lower-limit (needed by unittests
and internal technical requirements) of 3 connections
and 2 documents.
Change-Id: I6ccf3a607c50bb2a86bf1c0a16ebb6326ee34c7d
Reviewed-on: https://gerrit.libreoffice.org/32712
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Messages larger than a certain size are preambled
with a 'nextmessage' message that hold the size
of the subsequent message.
This is a workaround to a limitation the Poco
WebSocket API where if the buffer size is
smaller than the received frame the socket
ends up in a bad state and must be closed.
Unfortunately the new API that avoids this
workaround is not yet released by Poco.
Here we minimize the need for 'nextmessage'
to truely large messages. The limit is now
raised from above 1KB to over 63KB.
We may raise this limit further, but that will
cost each socket that much dedicated buffer size.
Change-Id: I01e4c68cdbe67e413c04a9725152224a87ab8267
Reviewed-on: https://gerrit.libreoffice.org/31286
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
