db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1856) Multiple communication failures when starting server with derby.drda.timeSlice
Date Fri, 08 Dec 2006 09:03:22 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1856?page=all ]

Bernt M. Johnsen updated DERBY-1856:
------------------------------------

    Attachment: DERBY-1856-r126392-regressionfix.diff

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?


> Multiple communication failures when starting server with derby.drda.timeSlice
> ------------------------------------------------------------------------------
>
>                 Key: DERBY-1856
>                 URL: http://issues.apache.org/jira/browse/DERBY-1856
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.1.3.1, 10.1.2.1, 10.3.0.0
>         Environment: any ( but I tried  on windows/2k/t40 laptop/jdk142).
>            Reporter: Sunitha Kambhampati
>         Assigned To: Bernt M. Johnsen
>         Attachments: DERBY-1856-r126392-regressionfix.diff
>
>
> 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. 
>  

-- 
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

       

Mime
View raw message