Issue Details (XML | Word | Printable)

Key: DERBY-2933
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Kathey Marsden
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Derby

When network server disconnects due to an I/O Exception it does not always log the exception that caused the error

Created: 12/Jul/07 10:36 PM   Updated: 06/Jul/09 05:39 PM
Return to search
Component/s: Network Server
Affects Version/s: 10.2.2.1
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works derby-2933_diff.txt 2007-08-01 11:38 PM Kathey Marsden 5 kB
Text File Licensed for inclusion in ASF works DERBY-2933_no_commit_diff.txt 2007-08-01 06:37 PM Kathey Marsden 4 kB
Text File Licensed for inclusion in ASF works derby-2933_stat.txt 2007-08-01 11:39 PM Kathey Marsden 0.2 kB
Issue Links:
Reference
 

Urgency: Normal
Issue & fix info: Repro attached


 Description  « Hide
I found this issue when debugging my attempted fix for DERBY-2892. The I/O Exception that occurs in writeScalarStream is not logged. To reproduce apply the patch in DERBY-2892 and run the repro there.



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Kathey Marsden added a comment - 12/Jul/07 10:37 PM
Reproducible case is in DERBY-2892

Kathey Marsden added a comment - 01/Aug/07 06:37 PM
Attached is a patch that logs the IO/exceptions and other events that cause markCommunicationsFailure to be called. This change caused testNetworkServerSecurityMechanism to start logging this error. I am investigating that, but the patch to turn on the logging should not be committed until this is resolved.


testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)
java.lang.Exception: totalBytesRead < minimumBytesNeeded
at org.apache.derby.impl.drda.DDMReader.fill(DDMReader.java:1936)
at org.apache.derby.impl.drda.DDMReader.ensureALayerDataInBuffer(DDMReader.java:1651)
at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:321)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:677)
at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:275)

Kathey Marsden added a comment - 01/Aug/07 08:55 PM
The error occurs whenever the datbase is shutdown and can be reproduced with this script.
It seems there is some cleanup needed of DDMReader when a severe error occurs.
 
ij> connect 'jdbc:derby://localhost:1527/wombat;create=true';
ij> connect 'jdbc:derby://localhost:1527/;shutdown=true';
totalBytesRead < minimumBytesNeeded
java.lang.Exception: totalBytesRead < minimumBytesNeeded
        at org.apache.derby.impl.drda.DDMReader.fill(DDMReader.java:1936)
        at org.apache.derby.impl.drda.DDMReader.ensureALayerDataInBuffer(DDMReader.java:1651)
        at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:321)
        at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:680)
        at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:275)
ERROR XJ015: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ015, SQLERRMC: Derby system shutdown.

Kathey Marsden added a comment - 01/Aug/07 11:38 PM
Here is another attempt at a patch. I am not really all that pleased with it as I fear it may still gobble some unexpected exceptions. This patch is the same as the first except for it does not log an exception for 1) SocketExceptions which are usually the client disconnecting.
2)The case where DDMReader.fill() expects bytes but gets none. This is the case when the database is shutdown.

I'd appreciate if someone can take a look. At least the patch does have the advantage that it will log some of the exceptions that were not being logged before. It is just a question of whether that is good enough.

Kathey


Kathey Marsden added a comment - 03/Aug/07 05:30 PM
Unassigning myself from this issue and reducing to minor. I fixed the error to log in writeScalarStream but there are still occassions where markCommunicationsFailure is called without logging, most notably when the server is brought down and active sessions are terminated. I left this as is. I am not sure if unexpected exceptions might still be left unlogged, so I am leaving this open.


Kathey

Bernt M. Johnsen added a comment - 07/Aug/07 09:20 AM
The exception handling in the network server should be taken into consideration in DERBY-2412. That should probably solve this in a decent way.

Rick Hillegas added a comment - 06/Jul/09 05:39 PM
Triage for 10.5.2: Assign normal urgency; note that has reproducible test case.