Re: Simulating HBase write failures in Phoenix tests
Some unit tests in HBase show how you can install test coprocessors that do various broken things. If you install it so it sorts below the Phoenix coprocessors in priority then at runtime the Phoenix coprocessor code will be called by the coprocessor framework, Phoenix code will do whatever and hand control back to HBase by returning, the coprocessor framework will then call the test coprocessor which will simulate failure, and I think this is the ordering you want. On Mon, Feb 9, 2015 at 11:01 AM, Eli Levine 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 > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: Simulating HBase write failures in Phoenix tests
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 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 > 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 > 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 > > > > > >
Re: Simulating HBase write failures in Phoenix tests
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 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 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 > > >
Re: Simulating HBase write failures in Phoenix tests
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 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 >
