-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
collaboration stacktraces when #10588
Comments
@jvillafanez Please take a look. |
Couple of things:
|
#10590 should fix the issue, although I don't think I've reproduced it correctly. I assume the setup is that you have 2 or more OnlyOffice, so it's possible that OnlyOffice1 makes a request to the collaboration service that ends up hitting OnlyOffice2, which is down. This could explain why I don't seem to reproduce the issue with only one OnlyOffice. Regarding the behavior, at least with one OnlyOffice, I'm getting a 404 in the web (not sure if the web team can do anything to beautify the error), but no error in the log. I guess the iframe tries to open the OnlyOffice site but it's down; this could explain why there is no logs other than a successful "openInApp" request (WOPI requests are expected to come from OnlyOffice, which is down) |
@wkloucek are you sure about the behavior here? I have the question what happens with the proofkeys when you restart all pods of onlyoffice? we should not run into a situation where ocis has no keys or the wrong keys, because that would block the web office. |
No, I only have one Onlyoffice cluster that I take down (or some parts of it). I'm talking about an installation like this: https://github.com/owncloud/ocis-charts/blob/65cb136af35f7229fda2c0b045e1e9929444e199/deployments/ocis-office/helmfile.yaml#L22-L90
what should happen to them? They are configured in a ConfigMap, so they are the same before and after the restart if you're pointing at this. This is not yet reflected in https://github.com/owncloud/ocis-charts/tree/main/deployments/ocis-office but I can add it there, too.
If office is down, there is no /hosting/discovery available and thus oCIS can't load the proof keys. |
@wkloucek thanks please note that none of us has access to the deployment repo anymore. |
From our side, the collaboration service will cache the public keys in local memory for the time period specified in the |
I only linked public ocis-charts repo here (this is also no enterprise issue)
I see that #10590 fixes it. So I could test again when it's available as a tagged (pre-)release |
Now there is a debug log entry to know when we're fetching the public keys, so it should be easy to know if it works or not. |
Describe the bug
The collaboration service has a stacktrace situation when the office /hosting/discovery enpoint can't be reached
Steps to reproduce
This is what I did, but I'm not sure if it reproduces it:
Expected behavior
No stacktraces
Actual behavior
See stacktraces:
Setup
oCIS 7.0.0-rc.2 in Kubernetes via the oCIS Helm Chart
The text was updated successfully, but these errors were encountered: