incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: 0.2.4 release planning
Date Tue, 06 Jan 2015 15:49:56 GMT
On Wed, Dec 3, 2014 at 8:35 AM, Tim Williams <williamstw@gmail.com> wrote:

> The complete list:
>
> 1) pom file changes - seems like everyone is ok with this for 0.2.4,
> so I'll make those changes in the next day or so.
>

I think this is complete.


>
> 2) documentation - there's still a bit left on the command stuff that
> I'll try to finish off in the next day or so; we also need to just go
> through the rest of the documentation and make sure it's all still
> accurate.
>

This still needs to be finished unless we are ok with releasing it
incomplete.


>
> 3) Apply some changes to the IndexInput and such that improve merge
> performance.
>

This still needs to improved a bit, but the overall solution is still
unknown.


>
> 4) Routing issue with the console.
>

I think this is fixed.


>
> ?5) Add javadoc tags for @blur.experimental so folks using the new
> Command stuff have fair warning and we have more freedom?
>

If we mark the command API experimental do we need to finish the docs
before release?

Aaron


>
> Thanks,
> --tim
>
>
> On Tue, Dec 2, 2014 at 11:24 AM, Chris Rohr <rohr.chris@gmail.com> wrote:
> > We need to figure out how to fix the routing issue that came up with the
> > console when we downgraded Jetty from 9 to 8.
> > On Tue, Dec 2, 2014 at 7:24 AM Aaron McCurry <amccurry@gmail.com> wrote:
> >
> >> There are a few code updates from the merge testing that need to be
> >> applied. I will try to have them applied later today.
> >>
> >> On Tuesday, December 2, 2014, Tim Williams <williamstw@gmail.com>
> wrote:
> >>
> >> > Ok, so we have:
> >> >
> >> > 1) pom file changes - seems like everyone is ok with this for 0.2.4,
> >> > so I'll make those changes in the next day or so.
> >> > 2) documentation - there's still a bit left on the command stuff that
> >> > I'll try to finish off in the next day or so; we also need to just go
> >> > through the rest of the documentation and make sure it's all still
> >> > accurate.
> >> > 3) ?
> >> >
> >> > Thanks,
> >> > --tim
> >> >
> >> >
> >> > On Mon, Nov 24, 2014 at 7:11 PM, Aaron McCurry <amccurry@gmail.com
> >> > <javascript:;>> wrote:
> >> > > I have helped them out on this issue.  It turns out that several of
> the
> >> > > thread pools were configured with too many threads.  I will check
> back
> >> > with
> >> > > them tomorrow to make sure that everything is still running well.
> >> > >
> >> > > Aaron
> >> > >
> >> > > On Thu, Nov 20, 2014 at 8:58 PM, Tim Williams <williamstw@gmail.com
> >> > <javascript:;>> wrote:
> >> > >
> >> > >> Ok, let's crash on this issue then.  Chris, do you wanna open
up a
> >> > >> JIRA issue for it?  Any ideas how we might craft a test for it?
 It
> >> > >> seems like it might have to be an integration test, but can you
say
> >> > >> more about the conditions that precede it?  Any sorting? Any
> filters?
> >> > >> Large number of fields? Large number of column families?  If you
> can
> >> > >> open up a ticket, I'm wondering if we can iterate on a test until
> we
> >> > >> find the right scenario that reproduces it or maybe you don't
know
> >> > >> enough about it quite yet?
> >> > >>
> >> > >> Thanks,
> >> > >> --tim
> >> > >>
> >> > >> On Thu, Nov 20, 2014 at 8:22 PM, Aaron McCurry <amccurry@gmail.com
> >> > <javascript:;>> wrote:
> >> > >> > The issue that Chris has mentioned is the only blocker in
my
> mind. I
> >> > >> would
> >> > >> > like to resolve the merge performance issue but I agree with
Tim
> >> that
> >> > >> > should not hold up the release.
> >> > >> >
> >> > >> > Aaron
> >> > >> >
> >> > >> > On Thursday, November 20, 2014, Chris Rohr <rohr.chris@gmail.com
> >> > <javascript:;>> wrote:
> >> > >> >
> >> > >> >> Tim,
> >> > >> >>
> >> > >> >> Thanks for starting this list.  I am cool with being
the RM for
> >> this.
> >> > >> >> I just got a new computer so I'll make sure my keys are
still
> good
> >> to
> >> > >> >> go.
> >> > >> >>
> >> > >> >> As for remaining issues:
> >> > >> >>
> >> > >> >> 1. We are having a back pressure issue under the following
> >> scenario:
> >> > >> >>     * column families are cold
> >> > >> >>     * concurrent queries (more than 10) are issued against
the
> cold
> >> > >> >> families
> >> > >> >>    This basically makes the system unusable very quickly
and
> runs
> >> the
> >> > >> >> cluster to the point where it has to be restarted.  Aaron
has
> been
> >> > >> >> brought into the conversation to help review things on
our end
> as
> >> > >> >> well.
> >> > >> >>
> >> > >> >> 2. The console was updated to support SSL connections,
however,
> >> there
> >> > >> >> is no way currently to actually enable ssl on Jetty through
> >> > >> >> configuration.  We may want to get that done prior to
the
> release.
> >> > >> >>
> >> > >> >> Current In-work console issues that would be nice to
have:
> >> > >> >>
> >> > >> >> 1. Facets on the search tab
> >> > >> >> 2. Top in the console
> >> > >> >>
> >> > >> >> Chris
> >> > >> >>
> >> > >> >> On Wed, Nov 19, 2014 at 7:14 PM, Tim Williams <
> >> williamstw@gmail.com
> >> > <javascript:;>
> >> > >> >> <javascript:;>> wrote:
> >> > >> >> > I'd like to chart out what needs to be done to kick
0.2.4 out
> the
> >> > >> >> > door.  On core blur, I'm only aware of slow merging
under
> certain
> >> > >> >> > [extreme-ish?] conditions.
> >> > >> >> >
> >> > >> >> > o) I pushed a new archetype for new Commands yesterday
that
> has
> >> > some
> >> > >> >> > slightly funky version bug/behavior. The archetype
just
> creates a
> >> > >> >> > sample command so I think we're fine shipping with
that as is.
> >> > >> >> >
> >> > >> >> > o) I think we're ok shipping with the merge weirdness
because
> >> we've
> >> > >> >> > been unable to hunt it down so far and it's pretty
rock solid
> and
> >> > only
> >> > >> >> > presents under certain circumstances.
> >> > >> >> >
> >> > >> >> > o) ?
> >> > >> >> >
> >> > >> >> > Also, Chris, you still cool with being RM for this
one?
> >> > >> >> >
> >> > >> >> > Thanks,
> >> > >> >> > --tim
> >> > >> >>
> >> > >>
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message