Derby
  1. Derby
  2. DERBY-1966

NetworkServer startup can take 50+ seconds if a client holds an open connection to the previous server booted within the same vm

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: None
    • Component/s: Network Server
    • Environment:
      Windows XP - IBM JVM 1.4.2
    • Urgency:
      Normal
    • Bug behavior facts:
      Performance

      Description

      Seen when a client in the same jvm held a open connection to a previously booted network server within the same jvm.

      Order would be:

      boot server
      client connect to server (hold onto connection and don't close)
      shutdown server
      boot server <<<<<------ this boot will take 50+ seconds

        Issue Links

          Activity

          Hide
          Daniel John Debrunner added a comment -

          Also occurs if a reference to the NetworkServerControl used to start the server is kept.
          Can reproduce this by not nulling out networkServerController in the tearDown method of NetworkServerTestSetup and then run a JUnit test that uses the decorator repeatably within the same JVM. Using the MathTrigFunctionsTest in the swingui (just keep clicking run once the test completes) I saw about 2 failures to start the network server every 15 runs.

          Show
          Daniel John Debrunner added a comment - Also occurs if a reference to the NetworkServerControl used to start the server is kept. Can reproduce this by not nulling out networkServerController in the tearDown method of NetworkServerTestSetup and then run a JUnit test that uses the decorator repeatably within the same JVM. Using the MathTrigFunctionsTest in the swingui (just keep clicking run once the test completes) I saw about 2 failures to start the network server every 15 runs.
          Hide
          Daniel John Debrunner added a comment -

          the interaction between NetworkServerControlImpl and DRDAServerStarter is overly complex and convoluted.
          It results in the method startNetworkServer in NetworkServerControlImpl being called twice on two different instances of NetworkServerControlImpl. Strangely enough both are required (but it's not obvious why from casual reading,
          it is due to some ordering issues) and it's further confused by the fact that the method startNetworkServer does not
          in fact start the server. Not sure of its exact role

          Separating out some of the code in DRDAServerStarter into separate methods (and adding comments) allows
          a more natural interface between these two classes. Will submit a patch for this soon. Probably does not solve the 60+
          second issue, but makes the code more understandable.

          Show
          Daniel John Debrunner added a comment - the interaction between NetworkServerControlImpl and DRDAServerStarter is overly complex and convoluted. It results in the method startNetworkServer in NetworkServerControlImpl being called twice on two different instances of NetworkServerControlImpl. Strangely enough both are required (but it's not obvious why from casual reading, it is due to some ordering issues) and it's further confused by the fact that the method startNetworkServer does not in fact start the server. Not sure of its exact role Separating out some of the code in DRDAServerStarter into separate methods (and adding comments) allows a more natural interface between these two classes. Will submit a patch for this soon. Probably does not solve the 60+ second issue, but makes the code more understandable.
          Hide
          Bryan Pendleton added a comment -

          I completely agree with your observations regarding the complexity. Deepa and Knut Anders and I wrestled with this code a bunch as part of DERBY-1219 and DERBY-1326. See e.g. https://issues.apache.org/jira/browse/DERBY-1326#action_12415277

          I'm not sure if any of the comments in those issues are of much help; just wanted to chime in and agree with your comments.

          Show
          Bryan Pendleton added a comment - I completely agree with your observations regarding the complexity. Deepa and Knut Anders and I wrestled with this code a bunch as part of DERBY-1219 and DERBY-1326 . See e.g. https://issues.apache.org/jira/browse/DERBY-1326#action_12415277 I'm not sure if any of the comments in those issues are of much help; just wanted to chime in and agree with your comments.
          Hide
          Daniel John Debrunner added a comment -

          Thanks Bryan, I see some of the same thoughts came up, I'll look through them in more detail before submitting a patch.

          Show
          Daniel John Debrunner added a comment - Thanks Bryan, I see some of the same thoughts came up, I'll look through them in more detail before submitting a patch.
          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2.
          Hide
          Kristian Waagan added a comment -

          Unable to reproduce on OpenSolaris with the procedure described above.
          Is this a Windows-only bug, or has it been observed on another operating system too?

          Show
          Kristian Waagan added a comment - Unable to reproduce on OpenSolaris with the procedure described above. Is this a Windows-only bug, or has it been observed on another operating system too?
          Hide
          Kathey Marsden added a comment -

          I attempted to reproduce this problem with the attached program AttemptReproDerby1966 against the reported version 10.3.1.4 on Windows with IBM 1.4.2 (although probably a later version of IBM 1.4.2)

          $ java -version
          java version "1.4.2"
          Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
          Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142ifx-20110211 (SR13 FP8+PM31983) (JIT enabled: jitc))

          Kristian also said he had trouble reproducing with the steps provided. I think unless someone has other ideas, we should close this one Cannot Reproduce

          Show
          Kathey Marsden added a comment - I attempted to reproduce this problem with the attached program AttemptReproDerby1966 against the reported version 10.3.1.4 on Windows with IBM 1.4.2 (although probably a later version of IBM 1.4.2) $ java -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142ifx-20110211 (SR13 FP8+PM31983) (JIT enabled: jitc)) Kristian also said he had trouble reproducing with the steps provided. I think unless someone has other ideas, we should close this one Cannot Reproduce

            People

            • Assignee:
              Unassigned
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development