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 >
