"Unable to extend the HTTP session" WARN logs

Issue

These warnings are frequently found in the logs:

Unable to extend the HTTP session.

Unable to extend the HTTP session. Review the portal property "session.timeout" if this warning is displayed frequently

Environment

Liferay DXP 7.0 Fixpack 102+
Liferay DXP 7.1 Fixpack 25+
Liferay DXP 7.2 Fixpack 15+
Liferay DXP 7.3 SP3+
Liferay DXP 7.4

(All versions where LPS-133668 is included)

Resolution

The "Unable to extend the HTTP session" error is caused when the browser sends a /c/portal/extend_session request to the Liferay server to extend the session, but it was already expired. This error can be caused by a Liferay misconfiguration or an external cause:

Liferay misconfiguration

This trace can be caused by a Liferay misconfiguration, you should check:

Check the session timeout configuration:
- Firstly, you must review the values configured for session timeout from the following files:
  - TOMCAT_HOME/webapps/ROOT/WEB-INF/web.xml => check the <session-timeout>configuration
  - [LIFERAY_HOME]/portal-ext.properties => check the session.timeout property
- The first one will usually overwrite the value defined in the second one, but this is not always true if you are not using the Tomcat application server, so both configurations must be aligned.
- See more details in How to change the Session timeout value.
- Be careful because sometimes when you patch your environment, if there is any change in web.xml included by Liferay, custom modifications in TOMCAT_HOME/webapps/ROOT/WEB-INF/web.xml could be lost.

Check the session timeout auto extend offset configuration:
- Check the session.timeout.auto.extend.offset property in the [LIFERAY_HOME]/portal-ext.properties file (from 2024.Q1+, use the UI to configure it) . This offset controls the number of seconds the extend request will be executed before the session is timed out:
  - The offset should be big enough so the "extend session" request arrives before the session is expired
  - It should be at least bigger than 60 seconds to avoid issues with the browser timers throttle to 1 minute, see Session timeout auto extend fails with Google Chrome
- The default value is session.timeout.auto.extend.offset=70 seconds (since LPS-137264), bigger values may help.

Check the values applied in the product:

To check the actual values related to the session that are applied in the portal, this Groovy script is useful:

import com.liferay.portal.util.PropsValues
out.println("session.timeout: " + PropsValues.SESSION_TIMEOUT)
out.println("session.timeout.redirect.on.expire: " + PropsValues.SESSION_TIMEOUT_REDIRECT_ON_EXPIRE)
out.println("session.timeout.warning: " + PropsValues.SESSION_TIMEOUT_WARNING)

// From 2024.Q1+, use the UI. See https://learn.liferay.com/w/dxp/system-administration/configuring-liferay/virtual-instances/infrastructure#session-timeout
out.println("session.timeout.auto.extend: " + PropsValues.SESSION_TIMEOUT_AUTO_EXTEND)
out.println("session.timeout.auto.extend.offset: " + PropsValues.SESSION_TIMEOUT_AUTO_EXTEND_OFFSET)

External causes

After checking that the Liferay configuration is aligned and correctly configured, the error can be also caused by the following external causes:

The extend session requests are sent to a node that doesn't have the user's session:
- You should check the load balancer configuration, especially if using sticky session.
- If you are using session replication at the application server, you should double-check that the session is correctly replicated.

The sessions are expired after a server restart:
- This can be mitigated by configuring a session replication to a second cluster node, this will avoid losing the user sessions during a server restart. See: Setting up Session Replication in Tomcat With Liferay DXP
- If you don't have session replication and your Tomcat has session persistence across restarts configured, you can mitigate the error if the session length is greater than the restart time.

Some browsers are sending extend requests with the wrong offset value:
- After changing the session.timeout / session.auto.extend.offset configuration, you can have user browsers with a cached version of the "extend session" JavaScript logic.
- You can simply wait some weeks until these browsers reload the new JavaScript, the WARN traces should be reduced after some time.
- You can also configure a longer session timeout in both Tomcat and Liferay sides, for example, increasing it from 15 minutes to 30 minutes, this will mitigate the problems because the browsers with the cached version will continue sending the requests with the shorter length, avoiding the issue.

Disabling the WARN traces

If there are no real issues related to the session in Liferay, you can turn it off. To do so, you need to follow the instruction listed in Adjusting log levels to persist after portal restart and configure the category portal_web.docroot.html.portal.extend_session_jsp to ERROR:

Create a file called portal-log4j-ext.xml in [TOMCAT]/webapps/ROOT/WEB-INF/classes/META-INF with the following content and restart the portal:

<?xml version="1.0"?>
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
    <category name="portal_web.docroot.html.portal.extend_session_jsp">
        <priority value="ERROR" />
    </category>
</log4j:configuration>

Additional log DEBUG traces about session extension

If you want to do additional research about the session extension, you can enable following DEBUG traces:

portal_web.docroot.html.portal.extend_session_jsp -> When the "Unable to extend the HTTP session" WARN is produced, it also traces the session to be extended and the effective session of the request.
com.liferay.portal.servlet.PortalSessionListener -> Traces all the session creation and destruction events, so you can check when they are created and expired.
Important: These debug traces were added in LPS-147401 so you will have to update your installation to 7.1 fp 27, 7.2 fp 17, 7.3 u4 or 7.4 u9 or request a hotfix.

It can be also useful to activate the access log in the Tomcat server.xml configuration file with the sessionid information from the request, adding:

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-Agent}i&quot; %{JSESSIONID}c %S %{LIFERAY_SHARED_AUTHENTICATION_TOKEN#CSRF}s" />

at the end of the file, inside the </Host> label.