I'll try to explain in a bit more detail what I've seen happening with Auction Monitor. It seems to be reproducible quite easy with more windows open from the same browser instance all pointing to Auction Monitor.
Auction Monitor has a request-scoped ClockBean that uses an IntervalRenderer to initiate a render every second. These render requests are put onto a queue before actually being serviced. The ICEfaces framework takes care of the actual session timeout itself. Between approximately 5 to 15 seconds before the actual session timeout would occur, the ICEfaces framework initiates its shutdown sequence for that particular session. Typically the shutdown sequence invokes the dispose() method of all related DisposableBeans. In the case of the ClockBean the dispose() method takes care of the clean up. Right after the shutdown sequence the ICEfaces framework waits for 3 seconds (to give time to other parts to finish their work as the shutdown sequence occurred) after which it invalidates the session.
In the case of Auction Monitor, the following sequence of events could occur starting just before the session expiry:
- the ClockBean instance requests a render
- the shutdown sequence is initiated
- the ClockBean instance does the clean up, making the ClockBean instance eligible for garbage collection
- the render is serviced and because there is no ClockBean instance for this session a new instance is created
- the new ClockBean instance is able to do one or two more successful render requests that are successfully being serviced as the actual session is still valid
- the session is invalidated (3 seconds after the shutdown sequence was finished)
- the new ClockBean instance will not get disposed during the duration of the application and it will continue trying to do its work (which causes Exceptions to be thrown in this particular case).
Changed Fix Version(s) to 1.7