Thanks, Jesse. Very useful. Any pointers to specific tests that spin up Coprocessors dynamically in Phoenix?
On Mon, Feb 9, 2015 at 11:51 AM, Jesse Yates <jesse.k.ya...@gmail.com> wrote: > Yeah, I've done that a handful of times in HBase-land (not sure where > though). It gets tricky with phoenix using all the BaseTest stuff because > it does a lot of setup things that could conflict with what you are trying > to do.* > > What I was frequently doing was using a static "latch" for turning on/off > errors since there are a lot of reads/writes that happen on startup that > you don't want to interfere with. Then you trip the latch when the test > starts (avoiding any errors setting up .META. or -ROOT-) and you are good > to go. > > However, in HBase-land we already run mini-cluster things in separate JVMs, > so the static use is just easier; in Phoenix this may not be as feasible. > The > alternative is to get the coprocessors from the coprocessor environment of > the regionserver in the test and pull out the latch from there. > > -J > > * This has been an issue when working on an internal project using Phoenix- > we wanted to use a bunch of the BaseTest methods, but not all of them, and > extent them a little more - and it was notably uncomfortable to mess with; > we just ended up copying out what we needed. Something to look at in the > future.... > > On Mon Feb 09 2015 at 11:01:39 AM Eli Levine <elilev...@gmail.com> wrote: > > > Greetings Phoenix devs, > > > > I'm working on https://issues.apache.org/jira/browse/PHOENIX-900 > (Partial > > results for mutations). In order to test this functionality properly, I > > need to write one or more tests that simulate write failures in HBase. > > > > I think this will involve having a test deploy a custom test-only > > coprocessor that will cause some predefined writes to fail, which the > test > > will verify. Does that sound like the right approach? Any examples of > > similar tests in Phoenix or anywhere else in HBase-land? > > > > Thanks, > > > > Eli > > >
