hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <tdunn...@maprtech.com>
Subject Re: java.lang.NoSuchMethodException: hbase-0.90
Date Fri, 07 Jan 2011 19:34:31 GMT
On Fri, Jan 7, 2011 at 10:30 AM, Stack <stack@duboce.net> wrote:

> As to your question Ted, it does seem like we could do the reflection
> once-only in the constructor rather than every time we do a getPos.
> Let me ask Nicolas.  Maybe he had reason for having to do it each
> time.  As to its assumptions, what you think?  It assumes class has a
> data member named 'in' and that file length is a long which seems safe
> enough.  Otherwise, its just changing accessibility.

It also assumes the type of this.in.in (at least the duck type).

This broke when we gave it a non HDFS instream.  I have added a
getFileLength method so that works now.  But it sounds like it may break
under other conditions as well.

Is there a reasonable fall back if the method doesn't exist?  Perhaps it
would be good to just test if the getMethod call returns null or throws.
 Then the fallback could be used.

> > My own situation is a bit unusual since I was testing hbase on a non-HDFS
> > file system, but Abinash's experience makes it seem that there is
> something
> > worse going on.
> >
> Ted, you need something changed?  If so, lets do it now before I roll
> next 0.90.0RC.

I am happy to make the change.  Just need a bit of context to avoid messing

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message