Renamed DocumentStoreManager to DocumentBroker and
restructured the handshake process.
Currently, at first client connection to a given doc
a DocumentBroker is created to serve as the clearing house
of all client-side activities on the document.
Prime goals is loading and saving of the document, but
also to guarantee race-free management of the doc.
Each doc has a unique DocKey based on the URL (the path,
without queries). This DocKey is used as key into a map
of all DocumentBrokers. The latter is shared among
MasterProcessSession instances.
Change-Id: I569f2d235676e88ddc690147f3cb89faa60388c2
Reviewed-on: https://gerrit.libreoffice.org/23216
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The current format is more flexible and standard.
/loolwsd/child?sessionId=xxx&jailId=yyy
The sessionId is the client-specific connection ID (which
is originally passed to the child via the Broker.
The jailId is the PID of the child.
Change-Id: I69c88e84114f9678addf795896ca2da15ca1221b
Reviewed-on: https://gerrit.libreoffice.org/23211
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Further changes/refactoring to make it possible:
* Add broker pid to Admin class
* Move getMemoryUsage for process to Util
* Change variable name to accurately reflect *active* items
_nViews -> _nActiveViews, etc.
Change-Id: I4c9206c49ab829b73ebfe226874bfbbcc8f95342
Reviewed-on: https://gerrit.libreoffice.org/22989
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Much simpler.
Also, don't duplicate the code informing that LD_BIND_NOW or
LOK_VIEW_CALLBACK are not set. Not that I understand why we need to
inform about that? If the "normal" thing should be that they are set,
why don't make it so by default then?
... and Admin and AdminModel containing all the required data
that we need to expose to Admin panel.
Admin processor will keep listening to any data on this
notification pipe and update AdminModel accordingly.
Change-Id: I0dd6f07ae60158733c34d17f53a35def70600513
Reviewed-on: https://gerrit.libreoffice.org/22780
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
So don't give it any then.
Remove the --uid option and related attempts to handle running loolwsd
under sudo, to be able to debug it. Now with loolwsd not having
capabilities, it should work fine to just run it under a debugger
normally. (For the loolbroker and loolkit processes, attaching to an
already started process is the way to debug.)
Sort #includes and using statements. Use 'using' consistently for all
Poco:: types. (I am not 100% convinced that using 'using' like done
here in loolwsd was a good idea after all. But at least let's be
consistent now that we do use it.)
Sorry, could not resist. Obviously not very important.
In retrospect, maybe it would have been better to have as policy to
*not* use any 'using Poco::Foo'. Now there is an inconsistent mix of
writing out the complete type and using a 'using'. Plus copy-pasted
long lists of 'usings'. And of course, one should never have 'using'
in an include file. Oh well.
An abstract Storage abstraction class is added.
There will be a factory to instantiate concrete
implementation for a given backend.
For WebDAV and similar hosted backends, authentication
and authorization will be done by the implementation
with the help of the Auth abstraction.
Change-Id: I38ec5dad4c2c4ce16df30d65826df96751b10e2d
Reviewed-on: https://gerrit.libreoffice.org/22513
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
An abstract class to request an access token, given
an authorization grant. The class should be
specialized for each authentication/authorization
type we support.
Currently it's not enabled in the code as it's
an early stage in developing an general API.
Change-Id: I4f2efd376d575640bd3e17c7257994020b11bbe8
Reviewed-on: https://gerrit.libreoffice.org/22512
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
There are cases when prisoner would send huge text data but
without preceeding 'nextmessage' frames making the master throw
WebSocketException.
Also move the 'nextmessage' frame interpretation logic up in the
'else if' ladder to be able to detect and handle such huge text frames.
Change-Id: Ibe44b69f4ab75c1b8096648c6006316c88366e7c
Reviewed-on: https://gerrit.libreoffice.org/21835
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
TCPServer doesn't use the custom ThreadPool passed to it
to dispatch connections. This leads to starvation
when too many connections are initiated together.
Because we open an internal socket back to master, we
need to be able to dispatch two connections (two threads)
for each client connection.
Therefore, the default ThreadPool needs to have sufficient
capacity to grow. A new constant is added to define this
capacity and it is used to configure both the TCPServer
(which configures the default ThreadPool) and the customer
ThreadPool (used to host the actuall connection handler).
Change-Id: I49adc039aa99e9350b0defc4a5e141b77524992e
Reviewed-on: https://gerrit.libreoffice.org/21976
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
