Multiple communication failures when starting server with derby.drda.timeSlice

• Key: DERBY-1856
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Bernt M. Johnsen
• Reporter: Sunitha Kambhampati
• Component/s: Network Server
• Affects Version/s: 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.1.4
• Fix Version/s: 10.1.3.2, 10.2.2.0, 10.3.1.4

Description

In http://www.nabble.com/Problem%3A-Communication-Link-Failure--derby.drda.timeSlice-p5966781.html , Hannes Grund reported a problem with derby.drda.timeSlice property.

I tried this property in my environment on trunk (10.3) and hit several communication failure problems with the following errors below.

On server
------------
trunk2>java -Dderby.drda.maxThreads=100 -Dderby.drda.timeSlice=10000 org.apache.derby.drda.NetworkServerControl star>
Apache Derby Network Server - 10.3.0.0 alpha started and ready to accept connections on port 1527 at 2006-09-15 18:41:51.750 GMT
Execution failed because of Permanent Agent Error: SVRCOD = 40; RDBNAM = testdb5;create=true; diagnostic msg = Session in invalid state:4
org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of Permanent Agent Error: SVRCOD = 40; RDBNAM = testdb5;create=true; diagnostic msg = Session in invalid state:4
        at org.apache.derby.impl.drda.DRDAProtocolException.newAgentError(DRDAProtocolException.java:328)
        at org.apache.derby.impl.drda.DRDAConnThread.agentError(DRDAConnThread.java:476)
        at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:278)
Execution failed because of Permanent Agent Error: SVRCOD = 40; RDBNAM = testdb5;create=true; diagnostic msg = Session in invalid state:4
org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of Permanent Agent Error: SVRCOD = 40; RDBNAM = testdb5;create=true; diagnostic msg = Session in invalid state:4
        at org.apache.derby.impl.drda.DRDAProtocolException.newAgentError(DRDAProtocolException.java:328)
        at org.apache.derby.impl.drda.DRDAConnThread.agentError(DRDAConnThread.java:476)
        at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:278)


On client:
-----------
trunk2>java org.apache.derby.tools.ij
ij version 10.3
ij> connect 'jdbc:derby://localhost:1527/testdb5;create=true;';
ij> select * from t1;
ERROR 42X05: Table/View 'T1' does not exist.
ij> select * from t1;
ERROR 42X05: DERBY SQL error: SQLCODE: -1, SQLSTATE: 42X05, SQLERRMC: T1¶42X05
ij> select * from t1;
ERROR 58015: The DDM object 0x1232 is not supported. The connection has been terminated.
ij> select * from t1;
ERROR 08003: No current connection.


In some cases, the client gets the 58009 communications error.
trunk2>java org.apache.derby.tools.ij
ij version 10.3
ij> connect 'jdbc:derby://localhost:1527/testdb4;create=true;user=a;password=p';
ij> create table t1(i1 int);
ERROR 58009: A communications error has been detected: Software caused connection abort: recv failed.

I am opening this jira because it seems like the basic problem may be just in the way the timeSlice property is being handled. As part of this jira, make sure that the timeSlice property behaves the way it is expected to and also clarify the documentation.

The documentation currently states this "Use the derby.drda.timeslice property to set the number of milliseconds that each connection will use before yielding to another connection. " and the default value is 0. Not clear what it means to have a default of 0. I think it is good to explain the behavior here.
 

Comments

[Bernt M. Johnsen]

The exception thrown is caused by a regression introduced in r126392
(2005-01-25) and is easily fixed by the attached
DERBY-1856-r126392-regressionfix.diff. The cause is that two session
states introduced (SECACC and CHKSEC) is missing in the switch in
DRDAConnThread.run().

Some comments:

1) Testing of maxThreads/timeSlice is obviously non-existing since a
   regression can live for nearly two years. I'll file an issue on
   this.

2) When timeSlice is defined, a timeout of the same size is set on the
   socket. It has been like this since the dawn of times (which in
   this case happens to be 2004-08-26 16:13:46), but Kathey added a
   comment that the timeout is "highly suspect", and I agree. Since
   SocketTimeoutException (introduced in J2SE 1.4) is not handled, the
   socket will be closed down when the timeout expires. This may be ok
   for applications using a connection pool which sanitychecks
   connections before reusing them, but disastrous for other
   applications. Without the timeout, a DRDAConnThread waiting for
   input, will not yield until another request comes from the
   client.

3) I experimented with catching the timeout in the DRDAConnThread as
   the only other change, and that seems to work. If the timeslice is
   setvery low (less than 100ms) I get problems which I guess stems
   from missing corner cases which may well appear with higher
   timeslices e.g. if the load is high or the query tekes a long time.


I guess the best approach is to let the timeout be as it is for the
moment and file a separate issue for proper handling of the
timeout.

Any comments?

[Bernt M. Johnsen]

Added a comment

The fix looks good. +1 to commit.
It would be great if you would make a test for timeSlice, too.

[Bernt M. Johnsen]

I have created DERBY-2165 for the test.

[Bernt M. Johnsen]

Committed revision 484615 on trunk

[Bernt M. Johnsen]

Committed revision 484616 on 10.2

[Bernt M. Johnsen]

Merge to 10.1

[Bernt M. Johnsen]

Committed revision 485667 on 10.1

[Andrew McIntyre]

This issue has been resolved for over a year with no further movement. Closing.