Problems with Pax-Web in Karaf 4.4.6 (HTTP Sessions)?

74 views
Skip to first unread message

Lukasz Lech

unread,
Apr 30, 2024, 4:41:36 AM4/30/24
to op...@googlegroups.com

Hello,

 

I have problem after upgrade from Karaf 4.4.5 to Karaf 4.4.6.

I have code that uses Session to store backend values.

When I test locally (under Windows) Sessions are not working – they are created, but very soon they are destroyed (after 1, max 2 minutes).

(I have SessionListener that logs when session is destroyed).

 

I have configured in org.ops4j.pax.web.cfg:

org.ops4j.pax.web.session.timeout=15

 

and I have keepalive every 30 seconds.

In the productive setup (Ubuntu-based docker image) there are no such problems.

 

I can remember session problems for a few years, where keepalive wasn’t working, and also only it was only on Windows, but it wasn’t such severe (now sessions seem to be timeouted almost immediately, which breaks the whole app).

 

Do you have any ideas, what can be causing such behavior?

As workaround, I can use older Karaf for development…

 

Best regards,

Lukasz Lech

 

Grzegorz Grzybek

unread,
Apr 30, 2024, 5:26:14 AM4/30/24
to op...@googlegroups.com
Hello

There was a session timeout configuration problem fixed in https://github.com/ops4j/org.ops4j.pax.web/issues/1912 in Pax Web 8.0.25.

Karaf 4.4.6 uses Pax Web 8.0.27 and 4.4.5 uses 8.0.24. #1912 seems to be the only change that affects your application...

Can you send more logs or a way to reproduce this issue?

regards
Grzegorz Grzybek

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/GV0P278MB01786777BAD4DB24F293825DF61A2%40GV0P278MB0178.CHEP278.PROD.OUTLOOK.COM.

Lukasz Lech

unread,
Apr 30, 2024, 6:02:36 AM4/30/24
to op...@googlegroups.com

Hello,

 

The logs are application-specific so it wouldn’t help you so much, but I’ve found in debugger something interesting.

 

There are 2 places in JettyServerWrapper that set maxInactiveInterval on Jetty. Jetty expects time in seconds, and the ops4j config in minutes. In one place, the value is multiplied by 60, in other, it’s not.

 

On Karaf 4.4.5 both places are called. First set parameter from my configuration (15), so the session timeout is set to 15 seconds.

Second one sets 30 (I suppose, it’s default value) and multiplies it by 60, so 30 minutes timeout are set. Parameter from my configuration is ignored.

 

On Karaf 4.4.6, only the first call is made. It means, that the session timeout is 15 seconds, instead of minutes.

 

I’ve updated org.ops4j.pax.web.session.timeout to 900 and all my automatic tests are completed. I need now to wait if the sessions will be actually deleted after this 15 minutes.

 

I hope that helps.

 

Best regards,

Lukasz Lech

Grzegorz Grzybek

unread,
Apr 30, 2024, 7:16:43 AM4/30/24
to op...@googlegroups.com
Hmm, good research!

On Pax Web side there are these methods/fields:
 – org.ops4j.pax.web.service.PaxWebConstants#DEFAULT_SESSION_TIMEOUT = 30, so should be in minutes
  org.ops4j.pax.web.service.PaxWebConfig#PID_CFG_SESSION_TIMEOUT - mentions minutes
  org.ops4j.pax.web.service.spi.model.elements.SessionConfigurationModel#sessionTimeout which maps to web.xml's `<session-timeout>` field and according to Servlet Spec, it should be in minutes again.
 – org.apache.catalina.Context#setSessionTimeout() - also works with minutes and Pax Web handles it correctly
 – io.undertow.servlet.api.DeploymentInfo#setDefaultSessionTimeout() - works with seconds, that's why Pax web multiplies SessionConfiguration#getSessionTimeout() by 60
 – org.eclipse.jetty.server.session.SessionHandler#setMaxInactiveInterval() - works with seconds and Pax Web multiplies the timeout by 60, but only in one place

So indeed there's a problem here and I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1952 to fix this.

Thanks for report!

regards
Grzegorz Grzybek


Reply all
Reply to author
Forward
0 new messages