As I mentioned above, not off the top of my head :-/ but I was just using simple region observers - all you need to do is add them to the list for the config before cluster start up and should be good to go.
On Mon, Feb 9, 2015, 1:03 PM Eli Levine <elilev...@gmail.com> wrote: > 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 > > > > > >
