[ http://issues.apache.org/jira/browse/DERBY-803?page=all ]

Deepa Remesh updated DERBY-803:
-------------------------------

    Assign To:     (was: Deepa Remesh)

Of late, I see this intermittent test failure is reported by few people. 
However, I have not been able to repro this issue on my machine. I am 
unassigning myself from this issue thinking someone else may be interested to 
pick it up.

Here is what I have found along with a recap of the discussions so far on this 
issue and DERBY-1020:

* This test uses derby.drda.startNetworkServer property. It checks that when 
embedded driver is loaded, it starts network server and when we do a system 
shutdown, it shuts down network server.

* The shutdown of network server happens asynchronously. DRDAServerStarter 
calls NetworkServerControlImpl.directShutdown which simply notifies the waiting 
thread and returns. Thus the shutdown of network server happens in parallel 
with remaining shutdown processing in the engine.

* Network server shutdown involves rollback and close of the EngineConnection 
object. Before calling these methods, it checks that the connection is not 
closed. From this, it seemed that this exception can occur only if the engine 
shutdown takes place in the meantime (after we check conn.isClosed() and when 
we are in conn.rollback())

I think the exception occurs when the system shutdown happens in the meantime:

                        if ((conn != null) && !conn.isClosed())
                        {
                                // --------------------------> Derby shutdown
                                if (! forXA)
                                {
                                        conn.rollback();
                                }
                                conn.close();                                   
                        }
                        

The closest I have been able to simulating this error is only by introducing a 
sleep here:

                        if ((conn != null) && !conn.isClosed())
                        {
                                // Introduce a sleep here ... just an attempt 
to simulate the failure
                                try {
                                        Thread.sleep(5000);
                                } catch (InterruptedException ie) {
                                        // 
                                }
                                if(conn.isClosed()) {
                                        System.out.println("Connection has been 
closed in the meantime !!!");
                                }

                                if (! forXA)
                                {
                                        conn.rollback();
                                }
                                conn.close();                                   
                        }
                        
If I run the test with this additional sleep, I always get "Connection has been 
closed in the meantime !!!" message and an exception in conn.rollback().

* Irrespective of where the exception happens, the gist of the problem is what 
Kathey reported in DERBY-1020 (Network Server treats errors on cleanup of 
connections as an unexpected error after intentional shutdown of the 
database/server)

* Possible solutions. These are just some ideas:

1. Catch any SQLExceptions thrown in conn.rollback() and conn.close(). In the 
catch block, call conn.isClosed() to check if connection has been closed. If 
so, ignore the exception. However, this solution has drawback because we do not 
know if the connection is no longer active because of some unexpected event. 
Kathey made this comment in DERBY-1020 
"
If an exception happens on rollback() or close() there are basically three 
scenarios
.
.
.

3) The connection is no longer active because of some unexpected event like a 
crash. There has been some debate in the past whether this type of exception 
needs to be logged. I thought session level exceptions in this block of code 
could safely be ignored since the fact that they were session severity meant 
the session was shutdown. Tomohito thought it was not good to ignore them and I 
understand that point.


"
Based on this, it may not be okay to just ignore exceptions.

2. Use NetworkServerControlImpl.shutdown instead of 
NetworkServerControlImpl.directShutdown method. This is to ensure network 
server has done all the cleanup related to shutdown before we proceed with rest 
of shutdown processing in the engine. However, this will slow down the shutdown 
processing.

3. Modify the test to redirect the exceptions during shutdown, similar to what 
is done in DERBY-273 for dataSourcePermissions_net test. This way, we can avoid 
seeing the intermittent failures in the regression test runs. This will not 
solve the real problem. Also, we may miss some real exceptions. 

> derbynet/DerbyNetAutoStart.java test fails intermittently with 
> org.apache.derby.iapi.services.context.ShutdownException
> -----------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-803
>          URL: http://issues.apache.org/jira/browse/DERBY-803
>      Project: Derby
>         Type: Test

>   Components: Network Server, Regression Test Failure
>     Versions: 10.2.0.0
>     Reporter: Kathey Marsden

>
> DerbyNetAutoStart fails intermittently with the following diff:
> This issue is likely related to DERBY-1020
> ********* Diff file 
> derbyall/derbynetmats/DerbyNet/derbynetmats/DerbyNetAutoStart.diff
> *** Start: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 
> 2006-01-05 23:39:40 ***
> 1a2,3
> > org.apache.derby.iapi.services.context.ShutdownException: 
> >     at org.apache.derby.impl.drda.Session.close(Unknown 
> > Source)agentThread[DRDAConnThread_3,5,derby.daemons]
> Test Failed.
> *** End:   DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 
> 2006-01-05 23:41:10 ***

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

Reply via email to