AsynchronousFileChannel.finalize()?

[Vitaly Davidovich]

Opening a new one per request will create mem churn plus involve a syscall
to open the file (so user --> kernel transition, which isn't cheap,
relatively speaking).  You're right in that the actual i/o workload will
probably not change due to page cache.

I say try out the simplest solution (new channel per request) and monitor
performance; if you see an issue, try a refcounted approach and compare.

Sent from my phone
On Mar 28, 2012 10:40 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

> You are right, we can't wait till GC to close a file; user code has to
> trigger close() asap.
>
> In the use case, how much overhead can we really save by using a
> shared channel? If instead a new channel is opened for every new
> request, the added overhead won't be significant, considering OS
> caching, correct? If there's not much advantage to share a channel, my
> use case can be simply dismissed.
>
> Zhong Yu
>
> On Wed, Mar 28, 2012 at 7:16 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > Relying on finalization is far from ideal given its nondeterminism.  It
> > seems like you may want to have a ref count associated with the channel,
> > which is checked during eviction.  This will require some bookkeeping and
> > maybe locking in a few places, which may reduce throughput somewhat, but
> at
> > least you'll have full control and deterministic behavior.  Just a
> thought
> > ...
> >
> > Sent from my phone
> >
> > On Mar 28, 2012 7:36 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:
> >>
> >> It appears that if close() is not invoked before an
> >> AsynchronousFileChannel becomes unreachable, the file handle remains
> >> open, and we get a resource leak.
> >>
> >> We can blame the programer for not properly closing the channel.
> >> However, would the nio team consider to add a feature anyway that will
> >> automatically invoke close() in finalize() (or something like
> >> sun.misc.Cleaner)?
> >>
> >> I have a use case where this feature could be helpful. A server has a
> >> file that's constantly requested by clients. The server opens one
> >> AsynchronousFileChannel and caches it. The same channel is used to
> >> serve all client requests to the file. When the server evicts the
> >> channel from the cache, it cannot immediately close() the channel
> >> right away, because the channel could still be referenced by request
> >> processors reading the file. The channel should be closed only after
> >> nobody references it.
> >>
> >> The point is that an AsynchronousFileChannel can be shared and
> >> accessed concurrently by multiple users; then it is difficult to
> >> pre-assign a user with the responsibility of closing the channel. It
> >> should be the last user that uses the channel - which is better
> >> handled in JDK.
> >>
> >> (In comparison, FileInputStream/FileChannel should have only one user
> >> at any given time, therefore it's clear who is responsible to do the
> >> close(). I wouldn't request the feature on these two classes.)
> >>
> >> Zhong Yu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120329/c400cf79/attachment.html