Skip to content
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

Armadillo doesn't seem to adhere to session timeout of 30 min #121

Closed
timcadman opened this issue Mar 25, 2021 · 14 comments
Closed

Armadillo doesn't seem to adhere to session timeout of 30 min #121

timcadman opened this issue Mar 25, 2021 · 14 comments
Assignees
Labels
bug 🐛 Something isn't working molgenis-service-armadillo 🦎 Armadillo service
Milestone

Comments

@timcadman
Copy link
Contributor

How to reproduce:
Log in via Elixir and wait for 15 mins, and the session times out.

@sidohaakma sidohaakma added the bug 🐛 Something isn't working label Mar 25, 2021
@sidohaakma
Copy link
Contributor

@fdlk
Copy link
Contributor

fdlk commented Mar 26, 2021

Weird. We set server.servlet.session.timeout to 30 minutes in the helm chart, here in this repo leave the spring boot default alone.

@sidohaakma sidohaakma added the molgenis-service-armadillo 🦎 Armadillo service label Apr 9, 2021
@sidohaakma
Copy link
Contributor

I think this could be due to the fact that when something goes wrong in the analysis the session is terminated. This works as intended. We need to harvest the error messages and feed it back to the DataSHIELD team.

@mswertz
Copy link
Member

mswertz commented Jul 28, 2022

We speculate this is part of the Jupyter issue

@mswertz mswertz added this to the Icebox milestone Jul 28, 2022
@clemens-tolboom
Copy link
Collaborator

Testing on localhost:8080 as admin user using settings

server:
  servlet:
    session:
      timeout: 1m

I am kicked out the session in 1 minute time trying to switch between projects and users.

UI

The UI could be friendlier

image

@clemens-tolboom clemens-tolboom self-assigned this Sep 25, 2023
@clemens-tolboom
Copy link
Collaborator

According to (use add blocker) https://www.baeldung.com/servlet-session-timeout

  • the default depends
  • we can programmatic set
HttpSession session = request.getSession();
session.setMaxInactiveInterval(10*60);

@clemens-tolboom clemens-tolboom modified the milestones: Icebox, Sprint 217 Feb 20, 2024
@clemens-tolboom
Copy link
Collaborator

clemens-tolboom commented Feb 20, 2024

Tests

Is this lines to look for?

2024-02-20 16:38:10.231 [Catalina-utility-1|] DEBUG o.a.catalina.session.ManagerBase - Start expire sessions StandardManager at 1708443490231 sessioncount 2
2024-02-20 16:38:10.231 [Catalina-utility-1|] DEBUG o.a.catalina.session.ManagerBase - End expire sessions StandardManager processingTime 0 expired sessions: 1

server.servlet.session.timeout=x minutes

Will ./release-test.R fail? File upload takes ~2 minutes

  • expected failure as file upload takes time?
  • R query taking longer that session timeout should fail?

Results

  • 2m 🏁 ran successful
  • 1m 🏁 ran successful
  • 10 🏁 ran successful
    • should be 10 seconds ✅ UI fails after waiting for 20s
    • Assigned expr. (methy_0y_EUR <- as.resource.object(eSet_0y_EUR)) [=====================] 100% /37s

Conclusion

@clemens-tolboom
Copy link
Collaborator

clemens-tolboom commented Feb 20, 2024

Session checks seems to occur each minute ...

tail -f logs/armadillo.log | grep "Start expire sessions" -A 5

print found lines + 5 After so catching End expire sessions

... edited
2024-02-20 17:10:55.105 [Catalina-utility-1|] DEBUG o.a.catalina.session.ManagerBase - Start expire sessions StandardManager at 1708445455101 sessioncount 0
...
2024-02-20 17:14:55.189 [Catalina-utility-2|] DEBUG o.a.catalina.session.ManagerBase - End expire sessions StandardManager processingTime 1 expired sessions: 1


2024-02-20 17:11:55.131 [Catalina-utility-2|] DEBUG o.a.catalina.session.ManagerBase - Start expire sessions StandardManager at 1708445515130 sessioncount 3


2024-02-20 17:12:55.152 [Catalina-utility-1|] DEBUG o.a.catalina.session.ManagerBase - Start expire sessions StandardManager at 1708445575152 sessioncount 3


2024-02-20 17:13:55.172 [Catalina-utility-1|] DEBUG o.a.catalina.session.ManagerBase - Start expire sessions StandardManager at 1708445635172 sessioncount 2

@clemens-tolboom
Copy link
Collaborator

It seems reproducible but is still uncertain calling increasing lambda

ds.Lasso_CVInSite(
  X = "x_mat",
  Y = "y_mat",
  type = "regress",
  nlambda = 2,
  lam_ratio = 0.01,
  datasources = conns,
  nDigits = 4,
  nfolds = 2)

https://github.com/transbioZI/dsMTLClient/blob/main/R/ds.Lasso.R

@timcadman
Copy link
Contributor Author

I've investigated this further and this particular time-out issue was not affected/resolved by changing server.servlet.session.timeout. I reduced it to 1 minute and the function continued to run past this, presumably because it kept polling.

@timcadman
Copy link
Contributor Author

timcadman commented Feb 22, 2024

However it has now been resolved by increasing the JWT token duration on the authentication server. Dick has set this to 4 hours, and the following now completes:

ds.Lasso_CVInSite(
  X = "x_mat",
  Y = "y_mat",
  type = "regress",
  nlambda = 20,
  lam_ratio = 0.01,
  datasources = conns,
  nDigits = 4,
  nfolds = 10)

@clemens-tolboom
Copy link
Collaborator

clemens-tolboom commented Feb 27, 2024

We now need to refresh the JWT token from within Armadillo.

@StuartWheater
Copy link
Collaborator

I looked at this a while ago, it appeared the changes needed are relatively easy. If the JWT needs refreshing the http(s) request will return a particular http status code, the JWT can be refreshed using the appropriate function, and the request reissued with the new JWT.

If memory serves only very few places in the code need to be changed.

@timcadman
Copy link
Contributor Author

Follow up issue is #669

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something isn't working molgenis-service-armadillo 🦎 Armadillo service
Projects
None yet
Development

No branches or pull requests

6 participants