On Tue, Oct 10, 2017 at 3:12 PM, Stack <[email protected]> wrote: > I've been splunking Phoenix code and I see that in SequenceRegionObserver > and in Indexer, they do by-pass doing their own version of Increment. > >
Following in the previous vein of offering alternatives, Phoenix has its own Increment because of "...deficiencies in Increment implementation (HBASE-10254)": 1) Lack of recognition and identification of when the key value to increment doesn't exist 2) Lack of the ability to set the timestamp of the updated key value. Works the same as existing region.increment(), except assumes there is a single column to increment and uses Phoenix LONG encoding. I think #1 in above is at least improved and if not good enough, we could fix. On #2, could add an ability to search the Increment payload for a timestamp to use. Assuming a single column seems like a downgrade. Phoenix LONG encoding might be hard to do unless we want to pull-in phoenix libs. St.Ack > St.Ack > > On Tue, Oct 10, 2017 at 11:49 AM, Stack <[email protected]> wrote: > >> On Tue, Oct 10, 2017 at 11:10 AM, Andrew Purtell <[email protected]> >> wrote: >> >>> The coprocessor API provides an environment method, bypass(), that when >>> called from a preXXX hook will cause the core code to skip all remaining >>> processing. This capability was introduced on HBASE-3348. Since this >>> time I >>> think we are more enlightened about the complications of this feature. >>> (Or, >>> anyway, speaking for myself:) >>> >>> Not all hooks provide the bypass semantic. Where this is the case the >>> javadoc for the hook says so, but it can be missed. If you call bypass() >>> in >>> a hook where it is not supported it is a no-op. This can lead to a poor >>> developer experience. >>> >>> Where bypass is supported what is being bypassed is all of the core code >>> implementing the remainder of the operation. In order to understand what >>> calling bypass() will skip, a coprocessor implementer should read and >>> understand all of the remaining code and its nuances. Although I think >>> this >>> is good practice for coprocessor developers in general, it demands a >>> lot. I >>> think it would provide a much better developer experience if we didn't >>> allow bypass, even though it means - in theory - a coprocessor would be a >>> lot more limited in some ways than before. What is skipped is extremely >>> version dependent. That core code will vary, perhaps significantly, even >>> between point releases. We do not provide the promise of consistent >>> behavior even between point releases for the bypass semantic. To achieve >>> that we could not change any code between hook points. Therefore the >>> coprocessor implementer becomes an HBase core developer in practice as >>> soon >>> as they rely on bypass(). Every release of HBase may break the assumption >>> that the replacement for the bypassed code takes care of all necessary >>> skipped concerns. Because those concerns can change at any point, such an >>> assumption is never safe. >>> >>> I say "in theory" because I would be surprised if anyone is relying on >>> the >>> bypass for the above reason. I seem to recall that Phoenix might use it >>> in >>> one place to promote a normal mutation into an atomic operation, by >>> substituting one for the other, but if so that objective could be >>> reimplemented using their new locking manager. >>> >>> >> >> Thanks Andrew for starting the discussion. >> >> Up in JIRA we've also talked of a 'wonky' case where CPs need >> write-access to the internal Metrics system so a CP on by-pass is able to >> increment standard counters. For example, a CP might bypass a Get operation >> instead returning a Cell from a CP-managed cache. In this latter case, it >> might want to increment the Get metrics counters so the by-pass shows in >> the general Get counts. >> >> This is problematic but there is at least an instance happening >> downstream. We'd like to keep internal metrics internal. CPs should be able >> to publish their own metrics. >> >> Please speak up if you depend on by-pass. >> >> S >> >> >> >> >> >> >> >>> -- >>> Best regards, >>> Andrew >>> >> >> >
