db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Database shutdown not releasing file handles
Date Wed, 04 Apr 2012 09:40:59 GMT
On 04.04.12 09:27, Trejkaz wrote:
> On Wed, Apr 4, 2012 at 4:46 PM, Kristian Waagan
> <kristian.waagan@oracle.com>  wrote:
>> On 04.04.12 05:23, Trejkaz wrote:
>>>
>>> We have the occasional user reporting that after shutting down the
>>> database, they can see file handles still open.
>>>
>>> We're using ;shutdown=true (or at least the DataSource equivalent of
>>> it) to do this, and we were led to believe that this would be
>>> sufficient to release all file handles.
>>
>> Hi,
>>
>> Yes, it should, but can you please clarify if you're talking about database
>> shutdown or Derby system shutdown?
>
> Just individual database shutdown.
>
>> Also, do you know to what kinds of files Derby keeps open handles?
>
> The files which are held are:
>
>   seg0\c951.dat
>   seg0\c861.dat
>   seg0\c211.dat
>   seg0\c71.dat
>   seg0\c130.dat
>   seg0\c731.dat
>   seg0\cf0.dat
>
> These do seem to be closed at some point *after* shutdown returns,
> leading us to believe that shutdown doesn't necessarily shut down
> "now", but rather "some time in the future."

Yes, if the handles are closed shortly after shutdown has returned this 
is unfortunately the currently expected behavior. Not sure if we have a 
JIRA for that, at least it has been discussed at some point.
Hopefully "some time in the future" is only a few seconds away.

>
> The timing is like this:
>
>   11:09:02.0444360 AM - close call presumably finishes around here
>   11:10:00.8759376 AM - we attempt to rename the directory
>   11:10:00.8760454 AM - first close call after our rename attempt
>   11:10:12.4420715 AM - last close call after our rename attempt
>
>>> Is it possible that shutdown doesn't actually shut the database down?
>>
>> Which version of Derby are you running with?
>
> v10.8.2.2.
>
> Another probably-critical piece of information I missed was that the
> OS is Windows. (If it had been Linux, we probably wouldn't ever notice
> this sort of thing since we discovered the issue when trying to move a
> file which was held open.)

Yes, that's typical, and the community sometimes observes the same thing 
when such a bug is introduced by someone developing on a non-Windows 
machine and then the nightlies fail on the Windows platform after the 
commit.


-- 
Kristian

>
> Daniel


Mime
View raw message