Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 10.3.1.4
-
Fix Version/s: None
-
Component/s: Network Server
-
Labels:
-
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
- is related to
-
DERBY-2616
intermittent network startup related errors in running junit nightly test suite
-
- Closed
-
Activity
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.
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.
Thanks Bryan, I see some of the same thoughts came up, I'll look through them in more detail before submitting a patch.
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue is related to |
Triaged for 10.5.2.
| Bug behavior facts | [Performance] | |
| Urgency | Normal |
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?
| Labels | derby_triage10_5_2 |
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
| Attachment | AttemptReproDerby1966.java [ 12515460 ] |
| Labels | derby_triage10_5_2 | derby_triage10_9 |
| Workflow | jira [ 12387117 ] | Default workflow, editable Closed status [ 12799687 ] |
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.