db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1326) Network server may abandon sessions when Derby system is shutdown and this causes intermittent hangs in the client
Date Thu, 01 Jun 2006 13:57:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1326?page=comments#action_12414236 ] 

Deepa Remesh commented on DERBY-1326:
-------------------------------------

Bryan,
Combined with your code changes in "sessionMgmt1.diff ', I think my previous comment about
'no-sessions-for-closed-threads.diff' does not hold good. This is the reason I think the combined
patch is okay:
"
The problem which we found previously with 'no-sessions-for-closed-threads.diff' was that
the "createSession" was thinking there are freeThreads (freeThreads !=0 ). But actually the
threads it were thinking as available were already closed. For the combined patch to work,
freeThreads must become 0 after a restart. This is to ensure that a new thread is created
when a new session comes in after a restart. I think the interrupt calls and the added synchronization
assure that freeThreads will become 0 before we start accepting new sessions.
"

To rephrase it,

1) With only 'no-sessions-for-closed-threads.diff', we can get to the following scenario:
When client starts a new session, the "createSession" logic in the server will check if freeThreads
are available. Because of the restart, the freeThreads counter may be invalid (freeThreads
!=0). This makes the "createSession" logic to think there are some free threads available.
Hence, it will not create a new thread for the incoming session. Instead, the incoming session
is put on the runQueue. However, all the existing threads were marked closed by the restart.
And we do not give sessions to closed threads. So this session keeps waiting for a thread.
When we start another session (e.g with ij), the hang goes away. When the connection from
ij comes in, the newly created thread is able to work on the waiting session and resolve the
hang. I think the patch does the right thing by not giving sessions to closed threads. However,
it can sometimes cause the case of stranded sessions because of incorrect value of freeThreads
counter in "createSession" logic.

2) With the combined patch "sessionMgmt1_and_nosessionsforclosedthreads.diff", I think we
can assume freeThreads counter will have the correct value when a new session comes in after
a restart. The interrupt calls and the added synchronization assure that freeThreads will
become 0 before we start accepting new sessions. If this assumption is correct, then we will
not have the case of stranded sessions mentioned in 1) above.

> Network server may abandon sessions when Derby system is shutdown and this causes intermittent
hangs in the client
> ------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1326
>          URL: http://issues.apache.org/jira/browse/DERBY-1326
>      Project: Derby
>         Type: Bug

>   Components: Network Server
>     Reporter: Deepa Remesh
>     Assignee: Bryan Pendleton
>  Attachments: repro1326.java, sessionMgmt1.diff, sessionMgmt1_and_nosessionsforclosedthreads.diff
>
> This issue was found when working on DERBY-1219. More details can be found in the comments
at http://issues.apache.org/jira/browse/DERBY-1219

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message