On Fri, Jan 7, 2011 at 10:30 AM, Stack <st...@duboce.net> wrote: > On Fri, Jan 7, 2011 at 7:53 AM, Ted Dunning <tdunn...@maprtech.com> wrote: > > This is on 0.90, right? Were you using HDFS to store your region tables? > > > > I just ran into the same thing and looked into the > > > org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader$WALReader$WALReaderFSDataInputStream.getPos > > method. > > > > That method does some truly hideous reflection things without checking > that > > the objects involved actually are the correct type. It also pierces the > > visibility constraints on fields internal to objects by manipulating > their > > visibility. > > > > Is that code really necessary? Is there a good way to make it less > > sensitive to violation of its assumptions? > > > > Yeah, its ugly, but acrobatics were required to get around dumb > dfsclient limitation (See hbase-3038). > > 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. > > > > 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. >
How about checking to see if "in" is instanceOf DFSInputStream before doing the rest of the stuff? > > St.Ack >
