I found the one more benefit of using (enhanced) interpreter. We load AggregateProtocolImpl.class into CoprocessorHost. Interpreter feeds various values (such as Long.MIN_VALUE) of concrete type (Long) into AggregateProtocolImpl. This simplifies class loading for CoprocessorHost
Cheers On Thu, Mar 31, 2011 at 11:37 AM, Ted Yu <[email protected]> wrote: > Renaming the subject to better reflect the nature of further discussion. > > There're two considerations for my current implementation attached to > HBASE-1512. > 1. User shouldn't modify HbaseObjectWritable directly for the new class > which is to be executed on region server. > 2. The reason for introducing interpreter is that we (plan to) store > objects of MeasureWritable, a relatively complex class, in hbase. Using > interpreter would give us flexibility in computing aggregates. > > Cheers > > On Thu, Mar 31, 2011 at 10:01 AM, Himanshu Vashishtha < > [email protected]> wrote: > >> Hello Ted, >> Did you add a new class: LongColumnInterpreter. Is this the new argument >> type you want to define to pass along rpcs. For all such "new" argument >> types, they should be supported/backed up with in the HbaseObjectWritable >> class to read/write it on wire. Do we really need it, just wondering. >> >> Himanshu >> >> On Thu, Mar 31, 2011 at 10:52 AM, Ted Yu <[email protected]> wrote: >> >> > Hi, >> > When I experimented with HBASE-1512, I got the following from >> > HbaseObjectWritable: >> > java.lang.UnsupportedOperationException: No code for unexpected class >> > >> > >> org.apache.hadoop.hbase.client.coprocessor.AggregationClient$1LongColumnInterpreter >> > >> > I think there was initiative to support dynamic class registration in >> > HbaseObjectWritable >> > >> > If someone can enlighten me on the above, that would be great. >> > >> > >
