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

[timcadman]

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

[sidohaakma]

Armadillo session timeout is not 30 minutes

[fdlk]

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]

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]

We speculate this is part of the Jupyter issue

[clemens-tolboom]

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

[clemens-tolboom]

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]

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

• [x] 2m 🏁 ran successful
• [x] 1m 🏁 ran successful
• [x] 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

• the normal R code flow calls are polling so do they poll fast enough?
• do we have async tests?
  • is thisrelated #589

[clemens-tolboom]

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]

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]

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]

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]

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

[StuartWheater]

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]

Follow up issue is #669