How to monitor and invalidate HTTP Sessions in WildFly

This article we will learn how to monitor and invalidate HTTP Sessions in WildFly application server / JBoss EAP using the management instruments such as the Command Line Interface and the Web console. We will also learn how to capture Undertow metrics using the Micrometer metrics component.

Monitoring HTTP Sessions

First of all, in order to gather statistics about HTTP sessions, you need to enable statistics on undertow subsystem You can do it from the CLI as follows:

/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)

That being said, let’s start checking an example application which has been deployed and has 2 active sessions:

/deployment=example.war/subsystem=undertow:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "active-sessions" => 2,
        "context-root" => "/example",
        "expired-sessions" => 0,
        "highest-session-count" => 2,
        "max-active-sessions" => -1,
        "rejected-sessions" => 0,
        "server" => "default-server",
        "session-avg-alive-time" => 0,
        "session-max-alive-time" => 0,
        "sessions-created" => 2,
        "virtual-host" => "default-host",
        "servlet" => undefined,
        "websocket" => undefined
    }
}

On the other hand, if you want to monitor the active HTTP Sessions for a single Web application, refer to the /deployment Model. For example, to count the active sessions for the Web application example.war:

/deployment=example.war/subsystem=undertow:read-attribute(name=active-sessions)

Monitoring HTTP Statistics with the Metrics

In order to monitor Undertow Statistics using metric, you can use the Micrometer extension which derives from the MicroProfile API.

Firstly, make sure that you enable the extension with:

if (outcome != success) of /extension=org.wildfly.extension.micrometer:read-resource
    /extension=org.wildfly.extension.micrometer:add
    /subsystem=micrometer:add()
end-if

Also, make sure that you are enabling metrics in Undertow:

/subsystem=undertow:write-attribute(name=statistics-enabled, value=true)

Then, if you curl the metrics endpoint:

curl -s http://localhost:9990/metrics 

Finally, you should be able to see Undertow metrics in the output:

....
wildfly_undertow_bytes_received_total_bytes{server="default-server",http_listener="default"} 6304.0
wildfly_undertow_bytes_received_total_bytes{server="default-server",https_listener="https"} 0.0

wildfly_undertow_bytes_sent_total_bytes{server="default-server",http_listener="default"} 2244.0
wildfly_undertow_bytes_sent_total_bytes{server="default-server",https_listener="https"} 0.0

wildfly_undertow_error_count_total{server="default-server",http_listener="default"} 0.0
wildfly_undertow_error_count_total{server="default-server",https_listener="https"} 0.0

wildfly_undertow_max_processing_time_seconds{server="default-server",http_listener="default"} 0.0
wildfly_undertow_max_processing_time_seconds{server="default-server",https_listener="https"} 0.0

wildfly_undertow_processing_time_total_seconds{server="default-server",http_listener="default"} 0.0
wildfly_undertow_processing_time_total_seconds{server="default-server",https_listener="https"} 0.0

wildfly_undertow_request_count_total{server="default-server",http_listener="default"} 8.0
wildfly_undertow_request_count_total{server="default-server",https_listener="https"} 0.0

Finally, please note that to display deployment undertow metrics with Micrometer you need to use a WildFly version
that contains this fix: https://issues.redhat.com/browse/WFLY-19583

To learn more about WildFly metrics, check this article: How to manage WildFly metrics

Invalidating HTTP Sessions

In order to invalidate HTTP Sessions or check the Session attributes, we need to collect its Session id. This can be done programmaticaly at some point:

HttpSession session = request.getSession();
String sessionid = session.getId();

However you can list HTTP Sessions from the CLI as well:

/deployment=example.war/subsystem=undertow:list-sessions()
{
    "outcome" => "success",
    "result" => [
        "iD_2bXgNFzOa5vPQvDoDuwXr1cec94xn2k-OvRk6",
        "4Jj6Y9qem8vAm8WXT3UAqvApBBfFszMLLWRyUqrK"
    ]
}

With that value, we can invalidate the HTTP Session as follows:

/deployment=example.war/subsystem=undertow:invalidate-session(session-id=iD_2bXgNFzOa5vPQvDoDuwXr1cec94xn2k-OvRk6)

We can also check the list of attributes which have been added to the Session:

 /deployment=example.war/subsystem=undertow:list-session-attribute-names(session-id=k3Yp2uwWYDxWhCe7JhpKghrEsxE6Gyo9lZgFySWC)
{
    "outcome" => "success",
    "result" => ["name"]
}

That can be combined with the attribute’s values:

[standalone@localhost:9990 /] /deployment=example.war/subsystem=undertow:list-session-attributes(session-id=k3Yp2uwWYDxWhCe7JhpKghrEsxE6Gyo9lZgFySWC)
{
    "outcome" => "success",
    "result" => [("name" => "Frank")]
}

Monitoring and invalidating HTTP Sessions from WildFly Web Console

It is worth mentioning, that you can also collect statistics and invalidate HTTP Sessions from the Web Console.

You should select your deployment unit under “Runtime / Server / Web / Deployment”. The following UI shows the core HTTP Session statistics:

To invalidate a HTTP Session, choose a deployment and select the “View” button. Within the available catgories (Sessions/Servlets/WebSockets), choose “Sessions“.

There, you can see all active sessions. Select a session to inspect HTTP session attributes. Also, you can invalidate a session by pressing “Invalidate Session“.

Conclusion

In conclusion, monitoring WildFly HTTP Sessions is a crucial steps towards ensuring the reliability and scalability of your enterprise applications. By closely monitoring key performance indicators and employing efficient monitoring tools, you can proactively identify bottlenecks, optimize resource utilization, and prevent potential downtime.