Monitor the disk space on important file systems: The ones where
cached tiles are stored and where the chroot jails are created. Those
might be the same file system of course, the code checks and doesn't
do needless work.
The check is done whenever a new loolkit process is taken into use and
a new chroot jail it constructed, and whenever a new client session
connects to a document. We don't check more often than once a minute,
though.
Still need to add code to guard against running out of diska space
when saving documents back to where they were opened from. For that
presumably need to enhance the Storage abstraction.
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
Avoid using the static mutex and instead use
the loKitDocument mutex when accessing the
latter. The static mutex is used only when
accessing the document manager. That is,
only when loading and unloading a document.
For ChildSession members that may
be accessed from both the callback and
incoming web-socket, guard them with the
member mutex.
Finally, move any local data manipulation
outside of locks altogether.
Change-Id: I046906bc6ed7e0b38c309f97836b38e27f9bfc8e
Reviewed-on: https://gerrit.libreoffice.org/29336
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
- show best, average, worst, last times of
- server ping round trip
- times between key press and invalidation message
- tile based and total tile update latencies
- show data of the last five invalidation:
- tilecombine messages, if they exist
- otherwise the invalidation message
- border of the last five invalidation rectangles
- visual fixes:
- more transparent red color for better text typing
- small letters over tiles with transparent background
- black attribution text instead of gray + bottomleft position
Unfortunately, std::regex is not well supported by old
compilers, namely gcc 4.8 doesn't seem to pass tests.
In addition, newer gcc versions, such as 5.2, don't like
{0,0} initialization.
For now we agreed on restoring the original Poco regex
and the old initialization of {}. When we move to
newer gcc, we can revert this commit so we get std::regex.
This commit reverts the following 3 commits:
Revert "Util: fix -Werror=shadow"
This reverts commit 01c6cb40ef.
Revert "loolwsd: replace Poco regex with std"
This reverts commit 1fdb4bf862.
Revert "Fix gcc-4.8 build"
This reverts commit 92ff278997.
Change-Id: I04912055d1143a2aeebb8d853c4d0c7fe74a40cc
Reviewed-on: https://gerrit.libreoffice.org/29324
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Introduce new API in our Util namespace to save data to a file
safely. The data is written to a temporary file in the same directory
and after that has succeeded, it is renamed atomicaly to the intended
name. If any step of the saving fails, neither the temporay file or
the intended target (if one exists before) is left behind.
Also add an API intended to alert the sysadmin in cases where their
attention and action are required. This is not yet properly
implemented. See FIXME comment for discussion.
Basically, instead of foo.compare(0, 3, "bar") use
LOOLProtocol::getFirstToken(foo)!="bar". Using a separate length of a
string literal is very fragile, it is easy to get the length wrong, or
forget to change it in case the string changes. See
137e677eb0.
It isn't entirely sure to me whether was is kept in a message queue
follows LOOL protocol message syntax, but it seems to be so in
practice, so we can use LOOLProtocol::getFirstToken().
Also, calls like msg.compare(0, 4, "tile") add undocumented implicit
requirements that the token in question must be unique as an initial
substring of the first tokens of all messages. It actually isn't,
there is also "tilecombine". But in this case, that was taken care of
by checking for "tilecombine" first. Ugh. Whether that was by accident
or design is hard to say, but at least there was no comment indicating
intentionality.
We still have lots of similar fragile mis-use of std::string::find().
