[ 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
