Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of francois.orsini@gmail.com
 designates 66.249.82.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=e93rwyWjFgo6asIbDCHQfWXKeieR0uv7qjSyIEO08Rqmo5Y0sRYdbMvNkRfHIjAgIcb1PkACXypqleFcHbfamUiJqudRq5mZe+nTT1jZQK+XaFNXyCTQ+YDFKqIuSujz7xQlyXWLi0LmMc0QDree6sgrao4FmjyE2daUDSrcXiU=
Message-ID: <7921d3e40510311610vacde68ep42831cbdfe750700@mail.gmail.com>
Date: Mon, 31 Oct 2005 16:10:57 -0800
From: Francois Orsini <francois.orsini@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: Derby I/O issues during checkpointing
In-Reply-To: <x1ofsluhl5ha.fsf@clustra.norway.sun.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_273_13369766.1130803857543"
References: <x1ofsluhl5ha.fsf@clustra.norway.sun.com>

------=_Part_273_13369766.1130803857543
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In order for a thread to generate many outstanding I/O calls at a time, it
should *not* block on an I/O in the first place if it does not have to -
this is what you observed - Typically, we would want to be able to issue
Asynchronous I/O's so that a given thread at the low-level does not block
but rather is allowed to check for I/O completion at a later time as
appropriate, while producing additional I/O requests (i.e. read-ahead) -
Asynchronous I/O's in Java is not something you used to get out of the box
and people have implemented it via I/O worker threads (simulated Async
I/O's) or/and using JNI (calling into OS proprietary asynchronous I/O drive=
r
on Unix FSs and Windows (NT)).

I think the approach you have made is good in terms of principles and
prototyping but I would think we would need to implement something more
sophisticated and having an implementation of worker threads simulating
asynchronous I/Os (whether we end-up using Java Asynchronous I/O in NIO or
not). I think we could even see additional performance gain.

Just my 0.02 cents...

--francois

------=_Part_273_13369766.1130803857543
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In order for a thread to generate many outstanding I/O calls at a time,
it should *not* block on an I/O in the first place if it does not have
to - this is what you observed - Typically, we would want to be able to
issue Asynchronous I/O's so that a given thread at the low-level does
not block but rather is allowed to check for I/O completion at a later
time as appropriate, while producing additional I/O requests (i.e.
read-ahead) - Asynchronous I/O's in Java is not something you used to
get out of the box and people have implemented it via I/O worker
threads (simulated Async I/O's) or/and using JNI (calling into OS
proprietary asynchronous I/O driver on Unix FSs and Windows (NT)).<br>
<br>
I think the approach you have made is good in terms of principles and
prototyping but I would think we would need to implement something more
sophisticated and having an implementation of worker threads simulating
asynchronous I/Os (whether we end-up using Java Asynchronous I/O in NIO
or not). I think we could even see additional performance gain.<br>
<br>
Just my 0.02 cents...<br>
<br>
--francois<br>

------=_Part_273_13369766.1130803857543--