Task #2804 (closed)
Bug: don't permit closing a session while a method is active
Reported by: | jamoore | Owned by: | jamoore |
---|---|---|---|
Priority: | blocker | Milestone: | OMERO-Beta4.2.1 |
Component: | Security | Version: | n.a. |
Keywords: | n.a. | Cc: | cxallan, jburel |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | 0.0d |
Sprint: | 2010-09-30 (17) |
Description
Imports failed after ten minutes of idleness (#2803). Why the session was being closed is part of that ticket, but the fact that any session can be closed when a method is running is a problem. Either the reference count should be simply set to 0, or should be set to some marker (-1) so that cleanup can occur at the end of the method, and no further methods can be started.
Change History (22)
comment:1 Changed 14 years ago by jmoore
comment:2 Changed 14 years ago by jmoore
comment:3 Changed 14 years ago by cxallan
- Priority changed from major to blocker
comment:4 Changed 14 years ago by cxallan
http://qa.openmicroscopy.org.uk/qa/feedback/2746/ is an example of this.
comment:5 Changed 14 years ago by cxallan
- Owner set to atarkowska
As an initial work around Ola will add a comment to ensure that administrators understand that this can take a long time!
comment:6 Changed 14 years ago by atarkowska
- Sprint set to 2010-09-09 (16)
comment:7 Changed 14 years ago by jburel
- Sprint changed from 2010-09-09 (16) to 2010-09-30 (17)
comment:8 Changed 14 years ago by jmoore
- Owner changed from atarkowska to jmoore
- Status changed from new to assigned
comment:9 Changed 14 years ago by cxallan
Another example from last week:
comment:10 Changed 14 years ago by jmoore
Some notes:
- session destruction seems to start with SessionManagerI.reapSession which implies a call to SessionCache.removeSession most likely from ServiceFactoryI.destroy.
- simple 2 threaded python version with a 15min Thread.sleep on setPlane doesn't show the error
- importer GUI importing a single file with the same 15min hang also doesn't show the error
- master.out & master.err in one example don't show anything pertinent
- there are no substantial SessionCache synchronizations at the time
- there is an odd close exception. See #2973. Most likely related to other close issues
comment:11 Changed 14 years ago by jmoore
comment:12 Changed 14 years ago by jmoore
- Owner jmoore deleted
- Status changed from assigned to new
comment:13 Changed 14 years ago by jmoore
comment:14 Changed 14 years ago by jmoore
- Owner set to jmoore
comment:15 Changed 14 years ago by jmoore
- Status changed from new to assigned
comment:16 Changed 14 years ago by jmoore
comment:17 Changed 14 years ago by jmoore
comment:18 Changed 14 years ago by jmoore
- Remaining Time changed from 0.75 to 0
- Resolution set to wontfix
- Status changed from assigned to closed
I've re-opened #2803 as the true cause of this behavior. Many of the commits here, looking back, should have been placed there.
The idea of preventing timeouts while a method is active does have value, but I'm closing this ticket anyway. The keep-alives will have to be responsible for preventing a very long running method from running into the type of exceptions seen here and under #2803.
comment:19 Changed 14 years ago by jmoore
comment:20 Changed 13 years ago by jmoore
(In [8445]) Adding logging at INFO to track session closing (See #2804)
original-svn-id: file:///home/svn/omero/trunk@8255 05709c45-44f0-0310-885b-81a1db45b4a6
comment:21 Changed 13 years ago by jmoore
(In [8446]) More logging at INFO for session tracking (See #2804)
original-svn-id: file:///home/svn/omero/trunk@8259 05709c45-44f0-0310-885b-81a1db45b4a6
comment:22 Changed 13 years ago by jmoore
(In [8447]) Copying reference counts between SessionContexts (See #2804, Fix #2803)
original-svn-id: file:///home/svn/omero/trunk@8262 05709c45-44f0-0310-885b-81a1db45b4a6
Be sure to review the commit for #2803 since another keep alive should not be necessary.