gt; something that I won't be supporting myself in production against an
> increasingly diverging upstream.
>
> - Andy
>
>
> --- On Wed, 3/2/11, Todd Lipcon wrote:
>
>> From: Todd Lipcon
>> Subject: Re: Is DFSInputStream.read(long position,...) designed
x27;t be supporting myself in production against an
> increasingly diverging upstream.
Agreed completely.
-Todd
>
> --- On Wed, 3/2/11, Todd Lipcon wrote:
>
>> From: Todd Lipcon
>> Subject: Re: Is DFSInputStream.read(long position,...) designed for multi
>> threa
ad(long position,...) designed for multi
> threaded access?
> To: "Jason Rutherglen"
> Cc: hdfs-user@hadoop.apache.org
> Date: Wednesday, March 2, 2011, 2:10 PM
> On Wed, Mar 2, 2011 at 8:17 AM, Jason
> Rutherglen
>
> wrote:
> > Todd,
> >
> > T
On Wed, Mar 2, 2011 at 8:17 AM, Jason Rutherglen
wrote:
> Todd,
>
> Thanks for the reply. I looked at HDFS-941 which seems to remove the
> redundant creation of BlockReaders. That and HDFS-347 will solve some
> of the issues, however I think there's also the sendmsg() of the file
> descriptor th
Todd,
Thanks for the reply. I looked at HDFS-941 which seems to remove the
redundant creation of BlockReaders. That and HDFS-347 will solve some
of the issues, however I think there's also the sendmsg() of the file
descriptor that also needs to be implemented?
Jason
On Tue, Mar 1, 2011 at 5:58
Hi Jason,
Yes, this method is currently very inefficient.. HDFS-941 will
hopefully improve this situation, but currently there's no
particularly efficient way to do multithreaded random access.
-Todd
On Tue, Mar 1, 2011 at 4:24 PM, Jason Rutherglen
wrote:
> It's unsynchronized however it's crea
It's unsynchronized however it's creating a new BlockReader on each
call, that seems like a problem?
