+++ This bug was initially created as a clone of RHQ Bug #953955 +++ Description of problem: We have a bug in the operations jobs code where we authenticate the user who scheduled the operation and never log him out. Consequently, the SessionManager cache keeps accumulating entries. Version-Release number of selected component (if applicable): 4.7 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: See call hierarchies of org.rhq.enterprise.server.operation.OperationJob#getUserWithSession The fix should make operation jobs log out the users and if possible the Session manager automatically evict timed out sessionq (with something like a task in a ScheduledExecutor).
A few things: 1) the session manager never purged timed out sessions unless someone logged out (during a logout, we would scrub all timed out sessions). We need a periodic job to clean out any sessions no matter what is going on with user login/logout. 2) the operation job code is creating multiple sessions when it only should be creating one 3) the operation job code should log out of the sessions it creates - this will remove the session from the manager and not leak the session.
git commit to master: cbfe893ad59715428bc8f72763c5b67f6b236779
note - I think a workaround for this is to periodically log in as a user (ANY user) and then immediately log out. This should trigger the session purge code. You might even be able to schedule a cron job to log in and out using the CLI. I haven't tested any of this, but the code to scrub old sessions is in the logout workflow, so presumably logging in and out of a CLI session or Web session would help clean up any old sessions and clean up any "leaked" sessions. Might be something for customers to try if they are hitting this issue as a temporary workaround.
As this is MODIFIED or ON_QA, setting milestone to ER1.