Return-Path: Delivered-To: apmail-hadoop-avro-user-archive@minotaur.apache.org Received: (qmail 49870 invoked from network); 17 Mar 2010 23:28:08 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Mar 2010 23:28:08 -0000 Received: (qmail 71404 invoked by uid 500); 17 Mar 2010 23:28:08 -0000 Delivered-To: apmail-hadoop-avro-user-archive@hadoop.apache.org Received: (qmail 71348 invoked by uid 500); 17 Mar 2010 23:28:08 -0000 Mailing-List: contact avro-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: avro-user@hadoop.apache.org Delivered-To: mailing list avro-user@hadoop.apache.org Received: (qmail 71340 invoked by uid 99); 17 Mar 2010 23:28:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Mar 2010 23:28:08 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.221.201] (HELO mail-qy0-f201.google.com) (209.85.221.201) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Mar 2010 23:28:01 +0000 Received: by qyk39 with SMTP id 39so799619qyk.22 for ; Wed, 17 Mar 2010 16:27:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.87.66 with SMTP id v2mr501488qal.343.1268868459349; Wed, 17 Mar 2010 16:27:39 -0700 (PDT) In-Reply-To: <7cd67c5d1003171519h293faf34wf21bd905e307d269@mail.gmail.com> References: <7e45e2ac1003171221i476beeaerf45b24a66b7b1559@mail.gmail.com> <7cd67c5d1003171347y1f9d59e7p8d5166d3a58b6bbf@mail.gmail.com> <7cd67c5d1003171459rf7e7cf4y157298a2a3a927a@mail.gmail.com> <7cd67c5d1003171519h293faf34wf21bd905e307d269@mail.gmail.com> From: Matt Massie Date: Wed, 17 Mar 2010 16:27:19 -0700 Message-ID: <35538fbe1003171627s642c43e8l42863e57746c69ec@mail.gmail.com> Subject: Re: C Implementation, missing avro_flush() To: avro-user@hadoop.apache.org Content-Type: multipart/alternative; boundary=00c09f923332c94b46048207750a X-Virus-Checked: Checked by ClamAV on apache.org --00c09f923332c94b46048207750a Content-Type: text/plain; charset=ISO-8859-1 Thanks for the report Niraj and thanks for the patch, Bruce. I just committed AVRO-480 to trunk. I agree that we need to clean up the I/O API and remove the buffered I/O. That work would be best to address with 1.4 since it will in all likelihood break the existing API in (hopefully small) ways. -Matt On Wed, Mar 17, 2010 at 3:19 PM, Bruce Mitchener wrote: > This is AVRO-480 in JIRA. Patch is attached for dealing with flush. > > - Bruce > > > On Wed, Mar 17, 2010 at 3:59 PM, Bruce Mitchener < > bruce.mitchener@gmail.com> wrote: > >> Niraj, >> >> So, I've been looking at this. >> >> I have a patch ready to roll for the first thing (dealing with >> avro_flush()). I'll go ahead and open a bug about that and attach the patch >> for massie to commit. >> >> However, for fsync(), I think we'd like to wait until 1.4 to address this >> as it will lead a confusing API at the moment that we'll just have to remove >> in short order. >> >> Right now, the container files are implemented with buffered I/O, so you'd >> have to call 3 functions to ensure that it hit disk. I think we can get >> away without buffered I/O and that would make it a more reasonable 2 >> functions. >> >> Do you have an overwhelming need for fsync functionality on container >> files (datafile.c stuff) in the next month or two? >> >> - Bruce >> >> >> On Wed, Mar 17, 2010 at 2:47 PM, Bruce Mitchener < >> bruce.mitchener@gmail.com> wrote: >> >>> Niraj, >>> >>> The header says avro_flush(), but the implementation says >>> avro_writer_flush(). We'll get this addressed shortly. >>> >>> There isn't currently a way to call fsync() directly ... but since you >>> pass the FILE* to the file writer, you could call fsync(fileno(FILE*)) on >>> your own, unless you're using the container file. >>> >>> If you want to open a bug on each of these, I'll work up the patches and >>> work with massie to get them into SVN. >>> >>> Cheers, >>> >>> - Bruce >>> >>> >>> On Wed, Mar 17, 2010 at 1:21 PM, Niraj Tolia wrote: >>> >>>> I was going through the avro.h header file (from the 1.3.0 release) >>>> and noticed that the avro_flush() call is defined but has no >>>> implementation. If someone does try to use it, compilation will fail >>>> with an undefined reference error. I am not sure if this was an >>>> accidental oversight but figured I should let someone know. >>>> >>>> Also, would I be correct in assuming that the C API doesn't allow me >>>> to actually call fsync() on a file writer? Digging through the code >>>> didn't turn up anything obvious. >>>> >>>> Cheers, >>>> Niraj >>>> >>>> -- >>>> http://www.tolia.org/ >>>> >>> >>> >> > --00c09f923332c94b46048207750a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the report Niraj and thanks for the patch, Bruce. =A0I just comm= itted AVRO-480 to trunk.

I agree that we need to clean u= p the I/O API and remove the buffered I/O. =A0That work would be best to ad= dress with 1.4 since it will in all likelihood break the existing API in (h= opefully small) ways.

-Matt



=
On Wed, Mar 17, 2010 at 3:19 PM, Bruce Mitchener= <bruce.m= itchener@gmail.com> wrote:
This is AVRO-480 in JIRA. Patch is attached= for dealing with flush.

= =A0- Bruce


On Wed, Mar= 17, 2010 at 3:59 PM, Bruce Mitchener <bruce.mitchener@gmail.com> wrote:
Niraj,

So, I've been = looking at this.

I have a patch ready to roll for = the first thing (dealing with avro_flush()). =A0I'll go ahead and open = a bug about that and attach the patch for massie to commit.

However, for fsync(), I think we'd like to wait unt= il 1.4 to address this as it will lead a confusing API at the moment that w= e'll just have to remove in short order.

Right now, the container files are implemented with buffered I/O, so you= 9;d have to call 3 functions to ensure that it hit disk. =A0I think we can = get away without buffered I/O and that would make it a more reasonable 2 fu= nctions.

Do you have an overwhelming need for fsync functionalit= y on container files (datafile.c stuff) in the next month or two?

=A0- Bruce


On Wed, Mar 17, 2010 at 2:47 PM, Bruce M= itchener <bruce.mitchener@gmail.com> wrote:
Niraj,

The header says av= ro_flush(), but the implementation says avro_writer_flush(). =A0We'll g= et this addressed shortly.

There isn't currently a way to call fsync() directl= y ... but since you pass the FILE* to the file writer, you could call fsync= (fileno(FILE*)) on your own, unless you're using the container file.

If you want to open a bug on each of these, I'll wo= rk up the patches and work with massie to get them into SVN.

=
Cheers,

=A0- Br= uce


On Wed, Mar 17, 2010 at 1:21 PM, Niraj Tolia <ntolia@gmail.com> wrote:
I was going through the avro.h header file (from the 1.3.0 release)
and noticed that the avro_flush() call is defined but has no
implementation. If someone does try to use it, compilation will fail
with an undefined reference error. I am not sure if this was an
accidental oversight but figured I should let someone know.

Also, would I be correct in assuming that the C API doesn't allow me to actually call fsync() on a file writer? Digging through the code
didn't turn up anything obvious.

Cheers,
Niraj

--
http://www.tolia.org/




--00c09f923332c94b46048207750a--