Just wanted to make clear what are the consequences of this behaviour. One of my clients is using wildfly to host a web-shop. In the web-shop the basket will be saved in a session. However, prices do change from time to time, so there is a process that runs through all the sessions, looks at all the baskets and check if prices in the basket have to be adjusted. This leads effectively to session which would never expire and servers blowing up.
Are you refering to Java Servlet 3.1 Specification chapter 7.5 Session Timeouts? Could you write down which sentence you have in mind exactly?
But yes I have got your point. But this is general problem bumpTimeout is also in setAttribute, removeAttribute, getAttributeNames, getId. Question here is how should be "user interaction" detected reliably.
swd847 what do you think?
Martin, I would correct the list of methods where 'bumpTimeout' is actually used in InMemorySessionManager to following: createSession(), setMaxInactiveInterval(), getAttribute(), getAttributeNames(), setAttribute(), removeAttribute(). From this list usage in following methods is suspicious: getAttribute(), getAttributeNames(), setAttribute(), removeAttribute().
All occurrences were added by this commit  with initial session timeout implementation.
The truth is the Servlet 4.0, section 7.5  specification (Servlet 3.1 is almost identical) specifies that timeout depends on user activity only:
"This means that the only mechanism that can be used to indicate when a client is no longer active is a time out period."
User interaction by common sense should mean some client request. Yeah, it looks like a bug to me, but swd847 should take a look.
I created JIRAs to track progress on this: WFLY-11115 UNDERTOW-1419