Bug #1114 (closed)
Opened 16 years ago
Closed 15 years ago
Memory leak in blitz after closed sessions
| Reported by: | jamoore | Owned by: | jamoore |
|---|---|---|---|
| Priority: | critical | Cc: | carlos@…, cxallan |
| Sprint: | n.a. | ||
| Total Remaining Time: | n.a. |
Description
The servants and ties are not being properly cleaned in some cases after session closed. For example, the server may only have 16 active ServiceFactoryI instances, but 1000+ AdminI instances. This may be related to the reference counting of OmeroSessions.
Change History (6)
comment:1 Changed 16 years ago by jmoore
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed 16 years ago by jmoore
- Resolution fixed deleted
- Status changed from closed to reopened
Unrelated to the concurrency issues in #1115, there are further cases of sessions not being collected when timeToLive is the cause of session death. Re-opening.
comment:3 Changed 15 years ago by jmoore
r2996 has a more substantial reworking of SessionCache to fix this secondary problem.
comment:4 Changed 15 years ago by jmoore
r2997 adds another important element to this solution, guaranteeing an SQL update on the session table to set "closed" on any DestroySessionMessage. There were various difficulties in doing this related to Hibernate and transactions. Eventually, it might make sense for the session manager to use JDBC directly rather than worry about this.
comment:5 Changed 15 years ago by jmoore
- Milestone changed from OMERO-Beta4 to OMERO-Beta3.2
r3045 (and r3046 in source:branches/Beta3.1) has an additional fix for this. Weblitz was experiencing numerous "connection timeout" exceptions from c3p0/jdbc. My assumption is that this is caused by the periodic reaping of all sessions, which consumes several connections (this was missing in previous versions). Since weblitz was retrying session creation over and over, this was then further exacerbated.
These fixes simply improve the c3p0 configuration and remove redundancies. It does not fix the overall problem that client code can make enough simultaneous calls to DoS the server. OmeroThrottling is needed to fix that.
comment:6 Changed 15 years ago by jmoore
- Resolution set to fixed
- Status changed from reopened to closed
There are still similar issues with Beta3 in JBoss where stateful sessions are not reaped, but we will attempt to take care of those by careful cleaning of stateful sessions on the client. (Discussed in today's conference call)
There are perhaps some other concurrency issues in ServiceFactoryI but I'll take care of those under another umbrella (#1115)