Trying to reproduce on Ubuntu.
On Tue, Oct 23, 2012 at 1:58 PM, Patrick Hunt <[email protected]> wrote: > Hm, I just updated and I'm seeing two errors (which is 1 less issue > than before): > > testTermDocIterable(org.apache.blur.utils.TermDocIterableTest) > org.apache.blur.thrift.BlurClusterTest: java.lang.NullPointerException > > Let me look and see if I can at least determine what the underlying > problems are. > > Patrick > > On Tue, Oct 23, 2012 at 10:12 AM, Aaron McCurry <[email protected]> wrote: >> I ran into some errors with ZookeeperClusterStatusTest tests and have >> resolved the issues I found. All units tests pass on OSX, I have not >> had a chance to run them on Linux yet. I also fixed the nasty NPE >> exception on the BlurClusterTest (it was affecting the functional >> tests as well). I ran a few burn-in tests on a VM running a 2 >> controller + 3 shard server Blur cluster. The tests included loaded >> data as fast as possibly while running searches against that data as >> fast as possible. The tests ran without issue (basically like they >> did before the upgrade to Lucene 4). I feel like the code is in a >> good state at this point. I'm going to merge this code to master and >> create another branch to begin modifying the RPC API. >> >> Anyone have any objections? >> >> Aaron >> >> On Mon, Oct 22, 2012 at 8:29 PM, Patrick Hunt <[email protected]> wrote: >>> On Mon, Oct 22, 2012 at 5:23 PM, Aaron McCurry <[email protected]> wrote: >>>> Hmm. >>>> >>>> On Mon, Oct 22, 2012 at 8:17 PM, Patrick Hunt <[email protected]> wrote: >>>>> Sounds good to me. >>>>> >>>>> Not sure if anyone else is seeing this but the unit tests are not >>>>> passing for me on ubuntu. I see one failure and two errors. >>>>> >>>>> Failed tests: >>>>> >>>>> testSafeModeSetInFuture(org.apache.blur.manager.clusterstatus.ZookeeperClusterStatusTest) >>>> >>>> Haven't seen this. >>>> >>>>> Tests in error: >>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest) >>>> >>>> This either. >>>> >>>>> org.apache.blur.thrift.BlurClusterTest: java.lang.NullPointerException >>>> >>>> I think I have been seeing this one during some functional tests. >>>> Haven't figured out the cause yet, but it seems like it's a nasty >>>> threading problem. Because when I drop the mutate threads back 1 >>>> everything works fine. However the test was passing on OSX. >>>> >>>>> >>>>> Just me or is this expected? >>>> >>>> Not expected. I'm going to setup a VM on computer to run tests in >>>> Linux as well. >>> >>> Ok. Let me know how it goes and I can try and debug it a bit, although >>> you're running much faster than I can at this point. ;-) Definitely >>> let me know if you can't reproduce it and I'll dig into it for sure. >>> >>> Patrick >>> >>>> >>>>> >>>>> Patrick >>>>> >>>>> On Sun, Oct 21, 2012 at 10:38 AM, Aaron McCurry <[email protected]> >>>>> wrote: >>>>>> We can fix the jira issues. >>>>>> >>>>>> On Sun, Oct 21, 2012 at 1:36 PM, Garrett Barton >>>>>> <[email protected]> wrote: >>>>>>> Sounds good to me Aaron, call it 0.2. Does that mess up Jira if you have >>>>>>> things scheduled against releases? >>>>>>> On Oct 21, 2012 9:44 AM, "Aaron McCurry" <[email protected]> wrote: >>>>>>> >>>>>>>> Ok, I think it will be some time before all the changes for the new >>>>>>>> api are in place and fully functional. So perhaps we should merge the >>>>>>>> lucene-4.0.0 branch into master and fix whatever bugs are found. I >>>>>>>> did some system testing yesterday and only found one big issue. There >>>>>>>> seems to be a threading problem with the BlurAnalyzer. If a single >>>>>>>> instance is in use across multiple threads some weird behaviors >>>>>>>> happen. Otherwise everything else seems to work, normally (I will >>>>>>>> create a jira issue). >>>>>>>> >>>>>>>> If we do merge the lucene-4.0.0 branch, I feel like we should change >>>>>>>> the version to 0.2. The reason is, the indexes in 0.1.x are not going >>>>>>>> to be backwards compatible (at least not with out some work). Does >>>>>>>> anyone have any strong feelings on this? >>>>>>>> >>>>>>>> Aaron >>>>>>>> >>>>>>>> On Sat, Oct 20, 2012 at 10:10 PM, Gagan Juneja >>>>>>>> <[email protected]> wrote: >>>>>>>> > I agree with Garrett. We can merge this branch to the place from >>>>>>>> > where we >>>>>>>> > cut it. Again as Garrett said If we want to keep only new api thing >>>>>>>> > then >>>>>>>> we >>>>>>>> > can merge it to master as well. >>>>>>>> > >>>>>>>> > Regards, >>>>>>>> > Gagan >>>>>>>> > >>>>>>>> > On Sat, Oct 20, 2012 at 9:50 PM, Garrett Barton < >>>>>>>> [email protected]>wrote: >>>>>>>> > >>>>>>>> >> I guess it depends on if your planning a 1.4 release with lucene 4. >>>>>>>> >> If >>>>>>>> yes >>>>>>>> >> then merge and work towards making everything functional. If not >>>>>>>> >> then >>>>>>>> leave >>>>>>>> >> the 1.3.x in master for bug fixing or whatnot and merge this branch >>>>>>>> >> into >>>>>>>> >> the new api one. >>>>>>>> >> On Oct 20, 2012 11:03 AM, "Aaron McCurry" <[email protected]> >>>>>>>> >> wrote: >>>>>>>> >> >>>>>>>> >> > I think that we can merge the lucene-4.0.0 branch back into the >>>>>>>> >> > master, since tests and code are compiling. I haven't done any >>>>>>>> >> > functional testing yet, but if much of the RPC and internals are >>>>>>>> >> > going >>>>>>>> >> > to change I think that it may be a waste of time to test and fix >>>>>>>> >> > everything that we are about to change. What do others think? >>>>>>>> >> > >>>>>>>> >> > Aaron >>>>>>>> >> > >>>>>>>> >> >>>>>>>>
