Requests need to be introspected and
dispatched to the appropriate handler.
File serving, admin, POST request, etc.
are all valid types that we need to support.
But of course the primary one is the WS request
to load to and interact with a document.
Change-Id: Id2c3214deb6b54b06b2735ec3370f09ed7a1ae51
ConsoleCertificateHandler will block on stdin
when a certificate error occures. This is hardly
helpful to users. Although in a server environment
this is likely to go to the journal, we should
properly log it and shutdown, rather than hang
waiting for the unlikely console input.
Change-Id: I54bb38ec60f443c579ef20dbb759941fae182e5b
When cleaning up DocumentBrokers we hold
the global DocBrokersMutex. So we need
to keep this lock as short as possible
to serve new requests.
However when a given DocBroker is locked
and busy, or worse deadlocked, we'd end
up blocking any new client connection.
So here we skip busy DocBrokers while
cleaning up.
Change-Id: I188c9abc34fd90c4ba388894b47c1ab08d185129
Reviewed-on: https://gerrit.libreoffice.org/34119
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
To perform one fuzzing iteration, use something like:
./loolwsd_fuzzer --config-file=loolwsd.xml --o:lo_template_path="/opt/libreoffice/instdir" --o:storage.filesystem[@allow]=true --fuzz=/tmp/looltrace
Change-Id: I27210d55a65f75e7d51e05c2f5f999acb758c4b1
By default snapshots are disabled, since trace recording
is enabled, to avoid unexpectedly flooding the disk.
Change-Id: I6c8728e14801f0a72accde1378455ec0e6046e3e
We no longer tell the clinet "This is embarrassing..."
when we disconnect and unload an idle document. Instead,
the client UI remains greyed out so the user can resume
as if it was inactive (and reload the document in this case).
Also, we now always send the "close: " message prior
to shutting down a client websocket. This is more
reasonable and consistent when we intentionally disconnect,
so clients can rely on it to signal intent and give reason.
Otherwise, a disconnection without this application-level
message should be unexpected and is therefore reasonable
to show the "This is embarrassing..." message.
Change-Id: Ic7439bcc9267be155586ccd5d122e9fe60225516
- add loolwsd option --config-file=path
- search all data files in the actual data directory
instead of the default one.
(cherry-picked from commit c4e9681fd17381c7af2936726262d7357a7dda10)
Change-Id: I028ff8a696aa6336da55bcac2952f13b12ba8eb8
Reviewed-on: https://gerrit.libreoffice.org/33504
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
The connection limit MAX_CONNECTIONS
is for document WS connections, which
doesn't take into account the other
resources (.js, .css, etc.) that clients
request. These transient files are as
many as 10 per client. While they
are being requested, other clients
should not be blocked due to reaching
the limit.
We now take into account these connections
and allow at least half as many clients
as the limit to connect simultaneously
without blockage.
Change-Id: I42fd27b992457bcf765a7a85382e6d7caad4bc97
Reviewed-on: https://gerrit.libreoffice.org/33669
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Refactored the forkit process wait and
re-fork into separate function.
Change-Id: If6106ea3820d10b4448bb27740d757afcea4779f
Reviewed-on: https://gerrit.libreoffice.org/33137
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Forkit always spawns a single child.
This is done to validate that forking
children is working and to be ready to
serve clients.
However, this initial forking can be slow,
mostly due to cold file reading and loading.
This often causes multiple child spawning
and other undesirable effects.
This patch makes sure that a single child
is always at the ready before proceeding
while simplifying the code. Otherwise, if
forkit fails to fork a single child within
4x an expected command-timeout (currently 5
seconds) then we fail the service altogether.
Change-Id: Ie2a441a2479db98a54f7fb9b9c8e98cda2f07c1c
Reviewed-on: https://gerrit.libreoffice.org/33128
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
In some cases when the last session is destroying
and we expect the DocumentBroker to be removed,
while waiting for autosave, a new client might
connect to the very same document.
In those cases we shouldn't fail but should retry
loading the document again once it has been unloaded.
Change-Id: I97ebb73991b9739cfb4e93b7de9115bdb48fda7a
Reviewed-on: https://gerrit.libreoffice.org/33125
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>