Hi Carey, So sessions will only be written to the store (jdbc) when the request count drops to zero. If the count remains above 0, then that is why they are not written nor expired.
I will take a particularly close look at the Async handling myself, but if you came up with a repro test case that does some simple async handling that would be great . Jan On Thu., 13 Dec. 2018, 13:24 Carey Evans <[email protected] wrote: > Hi. > > We're trying to use Jetty 9.4.14 with an application that uses a lot of > sessions, and we're having trouble with the DefaultSessionCache not > deleting some old sessions, until we ended up with 6.7 GB consumed by > 393216 Session objects in the heap after our load test. Looking at the > sessions that hadn't expired after a few hours, I see that each of them has > _requests set to 1, when it looks like they should all be 0. > > We're using a JDBC session store, and a lot of sessions didn't seem to > make it to the database table, although the ones that did were expired and > removed as expected. > > This is a fairly large application with a lot of proprietary code, so > unfortunately I don't have a way to reproduce this that I can share at the > moment. We do a fair bit of asynchronous servlet processing, though, which > makes me suspicious. Where can I start to look for a solution to this? > > > > -- > Laissez lire, et laissez danser; ces deux amusements ne feront jamais de > mal au monde. > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
