Return-Path: X-Original-To: apmail-hadoop-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B684F1023B for ; Thu, 19 Dec 2013 12:50:39 +0000 (UTC) Received: (qmail 83860 invoked by uid 500); 19 Dec 2013 12:50:32 -0000 Delivered-To: apmail-hadoop-user-archive@hadoop.apache.org Received: (qmail 83433 invoked by uid 500); 19 Dec 2013 12:50:31 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 83426 invoked by uid 99); 19 Dec 2013 12:50:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Dec 2013 12:50:31 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xiaobinshe@gmail.com designates 209.85.216.172 as permitted sender) Received: from [209.85.216.172] (HELO mail-qc0-f172.google.com) (209.85.216.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Dec 2013 12:50:24 +0000 Received: by mail-qc0-f172.google.com with SMTP id e16so842478qcx.31 for ; Thu, 19 Dec 2013 04:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KHuoTkO/bH7nIsb/UqNqtsb2sp+z8yTi/2WRHEAP50U=; b=JoiopoXGOAzCOt4SsRBcPRiOIvqY2rSsa1Hibluo7JYQYvz4QYicKKX60Cz9BFpAkN mcoxBay57qn5/GnEXJALMImQBQz1AppqVZPhuzH7eMCV/4WzZavYYu4jjPCh2/vjRjau qoHh3zhD8qmtlcwOJ6QoF7m4zh/j8g6lGzOPnZq2HtX/jNi3bHnU3i8PYlw3DuWFhVZo AMgrMNKsMDZdChcV2xZk8S6pV7fVcHh2alxcFRfxlgISAaOQvTsxiRRw+lNHlFsgfcId WnFigg8mKVbMtApnsfGBScLll2FVmRPXuADKTMilQBLF710Hs8LL4zAbtTxbgWLxgSNx 2Y1g== MIME-Version: 1.0 X-Received: by 10.224.168.13 with SMTP id s13mr2537357qay.18.1387457404091; Thu, 19 Dec 2013 04:50:04 -0800 (PST) Received: by 10.140.85.168 with HTTP; Thu, 19 Dec 2013 04:50:04 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Dec 2013 20:50:04 +0800 Message-ID: Subject: Re: Why other process can't see the change after calling hdfsHFlush unless hdfsCloseFile is called? From: Xiaobin She To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=089e01493b2ab6422104ede299e8 X-Virus-Checked: Checked by ClamAV on apache.org --089e01493b2ab6422104ede299e8 Content-Type: text/plain; charset=ISO-8859-1 sorry to reply to my own thread. Does anyone know the answer to this question? If so, can you please tell me if my understanding is right or wrong? thanks. 2013/12/17 Xiaobin She > hi, > > I'm using libhdfs to deal with hdfs in an c++ programme. > > And I have encountered an problem. > > here is the scenario : > 1. first I call hdfsOpenFile with O_WRONLY flag to open an file > 2. call hdfsWrite to write some data > 3. call hdfsHFlush to flush the data, according to the header hdfs.h, > after this call returns, new readers shoule be able to see the data > 4. I use an http get request to get the file list on that directionary > through the webhdfs interface, > here I have to use the webhdfs interface because I need to deal with > symlink file > 5. from the json response which is returned by the webhdfs, I found that > the lenght of the file is still 0. > > I have tried to replace hdfsHFlush with hdfsFlush or hdfsSync, or call > these three together, but still doesn't work. > > Buf if I call hdfsCloseFile after I call the hdfsHFlush, then I can get > the correct file lenght through the webhdfs interface. > > > Is this right? I mean if you want the other process to see the change of > data, you need to call hdfsCloseFile? > > Or is there somethings I did wrong? > > thank you very much for your help. > > > > > --089e01493b2ab6422104ede299e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

sorry to reply to my own thread.

Does anyone kn= ow the answer to this question?
If so, can you please tell me if my unde= rstanding is right or wrong?

thanks.



2013/12/17 Xiaobin She <xiaobinshe@g= mail.com>
hi,

I'm using libhdfs to deal with hdfs in an = c++ programme.

And I have encountered an problem.

here is the= scenario :
1. first I call hdfsOpenFile with O_WRONLY flag to open an f= ile
2. call hdfsWrite to write some data
3. call hdfsHFlush to flush the dat= a,=A0 according to the header hdfs.h, after this call returns, new readers = shoule be able to see the data
4. I use an http get request to get the f= ile list on that directionary through the webhdfs interface,
here=A0 I have to use the webhdfs interface because I need to deal with sym= link file
5. from the json response which is returned by the webhdfs, I = found that the lenght of the file is still 0.

I have tried to replac= e hdfsHFlush with hdfsFlush or hdfsSync, or call these three together, but = still doesn't work.

Buf if I call hdfsCloseFile after I call the hdfsHFlush, then I can get= the correct file lenght through the webhdfs interface.


Is this = right? I mean if you want the other process to see the change=A0 of data, y= ou need to call hdfsCloseFile?

Or is there somethings I did wrong?

thank you very much for your= help.





--089e01493b2ab6422104ede299e8--