Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Lefty Leverenz]

The dev@hive archive isn't perfect.  For example, it doesn't have Hari's
May 7th comment on HIVE-5092:

https://issues.apache.org/jira/browse/HIVE-5092?focusedCommentId=13992191&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992191

I searched by date, thread, and author in the
Apache archives
and by text string in
Markmail
.

But this discussion belongs in a different thread.

-- Lefty


On Mon, May 19, 2014 at 6:11 PM, Alan Gates  wrote:

> Per the apache infra tweet stream mail delivery times should be back to
> normal as of today. I believe Sushanth decided to roll a new rc anyway.
> Once that is done we should be able to vote in the normal manner.
>
> Alan.
>
> Sent from my iPhone
>
> On May 19, 2014, at 17:59, Lefty Leverenz  wrote:
>
> > Gotta side with Alan about voting by JIRA:  although it's convenient for
> > the moment, the indirect mail records wouldn't be labeled [VOTE].  Some
> > future Hive historian could come to grief (and have to drop out of grad
> > school).
> >
> > The community needs to see the votes as they come in, and shouldn't have
> to
> > look in the archives or JIRA comments.  What to do?  When can we expect
> the
> > mailing list to get back to normal?
> >
> >
> > -- Lefty
> >
> >
> > On Mon, May 19, 2014 at 8:00 AM, Alan Gates 
> wrote:
> >
> >> The vote by mail requirement is an Apache one, which trumps any Hive
> >> bylaws.  I really think Apache is going to frown on voting via JIRA.
> >>
> >> Alan.
> >>
> >> On May 17, 2014, at 9:15 PM, Lefty Leverenz 
> >> wrote:
> >>
> >>> Hive bylaws<
> >> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Voting
> >say
> >>> the mailing list is used for voting, but as I recall bylaws have some
> >>> wiggle room.
> >>>
> >>> Decisions regarding the project are made by votes on the primary
> project
>  development mailing list (u...@hive.apache.org  >).
>  Where necessary, PMC voting may take place on the private Hive PMC
> >> mailing
>  list. Votes are clearly indicated by subject line starting with
> [VOTE].
>  Votes may contain multiple items for approval and these should be
> >> clearly
>  separated. Voting is carried out by replying to the vote mail.
> >>>
> >>>
> >>> (Hm, the text says "primary project development mailing list" but then
> >>> user@hive is shown in parentheses -- is that a typo in the bylaws?)
> >>>
> >>> Would people be willing to vote simultaneously by mail and on a jira?
> >> It's
> >>> inconvenient but shouldn't be necessary after this release.
> >>>
> >>> -- Lefty
> >>>
> >>>
> >>> On Sat, May 17, 2014 at 7:30 PM, Sushanth Sowmyan  >>> wrote:
> >>>
>  There is a technical issue as well now, as raised by Prashant. But
>  there is also the issue that people aren't reliably able to
>  respond/object/approve, and not knowing if/when it'll go through.
> 
>  I think I like Lefty's jira proposal - we could open out a jira for it
>  and address votes there, I think I'll do that for RC2.
> 
>  On Fri, May 16, 2014 at 2:53 PM, Alan Gates 
> >> wrote:
> > So this isn’t a technical issue, just concern about the delays in the
>  mailing list?  Why not just extend the voting period then, until say
> >> Monday?
> >
> > Alan.
> >
> > On May 15, 2014, at 3:17 PM, Sushanth Sowmyan 
>  wrote:
> >
> >> Hi Folks,
> >>
> >> I'm canceling this vote and withdrawing the RC1 candidate for the
> >> following reasons:
> >>
> >> a) I've talked to a couple of other people who haven't seen my mail
> >> updates to this thread, and saw my initial vote mail a bit late too.
> >> b) There's at least one other person that has attempted to reply to
> >> this thread, and I don't see the replies yet.
> >>
> >> Thus, when the mailing list channel isn't reliably working, the
> >> ability for people to +1 or -1 is taken away, and this does not
> work.
> >> (We don't want a situation where 3 people go ahead and +1, and that
> >> arrives before today evening, thus making the release releasable,
> >> while someone else discovers a breaking issue that should stop it,
> but
> >> is not able to have their objection or -1 appear in time.)
> >>
> >> I'm open to suggestions on how to proceed with the voting process.
> We
> >> could wait out this week and hope the ASF mailing list issues are
> >> resolved, but if it takes too much longer than that, we also have
> the
> >> issue of delaying an important bugfix release.
> >>
> >> Thoughts?
> >>
> >> -Sushanth
> >> (3:15PM PDT, May 15 2014)
> >>
> >>
> >>
> >> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan <
> >> khorg...@gmail.com>
>  wrote:
> >>> The apache dev list seems to still be a little wonky, Prasanth
> mailed
> >>> me saying he'd rep

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Alan Gates]

Per the apache infra tweet stream mail delivery times should be back to normal 
as of today. I believe Sushanth decided to roll a new rc anyway. Once that is 
done we should be able to vote in the normal manner. 

Alan. 

Sent from my iPhone

On May 19, 2014, at 17:59, Lefty Leverenz  wrote:

> Gotta side with Alan about voting by JIRA:  although it's convenient for
> the moment, the indirect mail records wouldn't be labeled [VOTE].  Some
> future Hive historian could come to grief (and have to drop out of grad
> school).
> 
> The community needs to see the votes as they come in, and shouldn't have to
> look in the archives or JIRA comments.  What to do?  When can we expect the
> mailing list to get back to normal?
> 
> 
> -- Lefty
> 
> 
> On Mon, May 19, 2014 at 8:00 AM, Alan Gates  wrote:
> 
>> The vote by mail requirement is an Apache one, which trumps any Hive
>> bylaws.  I really think Apache is going to frown on voting via JIRA.
>> 
>> Alan.
>> 
>> On May 17, 2014, at 9:15 PM, Lefty Leverenz 
>> wrote:
>> 
>>> Hive bylaws<
>> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Voting>say
>>> the mailing list is used for voting, but as I recall bylaws have some
>>> wiggle room.
>>> 
>>> Decisions regarding the project are made by votes on the primary project
 development mailing list (u...@hive.apache.org ).
 Where necessary, PMC voting may take place on the private Hive PMC
>> mailing
 list. Votes are clearly indicated by subject line starting with [VOTE].
 Votes may contain multiple items for approval and these should be
>> clearly
 separated. Voting is carried out by replying to the vote mail.
>>> 
>>> 
>>> (Hm, the text says "primary project development mailing list" but then
>>> user@hive is shown in parentheses -- is that a typo in the bylaws?)
>>> 
>>> Would people be willing to vote simultaneously by mail and on a jira?
>> It's
>>> inconvenient but shouldn't be necessary after this release.
>>> 
>>> -- Lefty
>>> 
>>> 
>>> On Sat, May 17, 2014 at 7:30 PM, Sushanth Sowmyan >> wrote:
>>> 
 There is a technical issue as well now, as raised by Prashant. But
 there is also the issue that people aren't reliably able to
 respond/object/approve, and not knowing if/when it'll go through.
 
 I think I like Lefty's jira proposal - we could open out a jira for it
 and address votes there, I think I'll do that for RC2.
 
 On Fri, May 16, 2014 at 2:53 PM, Alan Gates 
>> wrote:
> So this isn’t a technical issue, just concern about the delays in the
 mailing list?  Why not just extend the voting period then, until say
>> Monday?
> 
> Alan.
> 
> On May 15, 2014, at 3:17 PM, Sushanth Sowmyan 
 wrote:
> 
>> Hi Folks,
>> 
>> I'm canceling this vote and withdrawing the RC1 candidate for the
>> following reasons:
>> 
>> a) I've talked to a couple of other people who haven't seen my mail
>> updates to this thread, and saw my initial vote mail a bit late too.
>> b) There's at least one other person that has attempted to reply to
>> this thread, and I don't see the replies yet.
>> 
>> Thus, when the mailing list channel isn't reliably working, the
>> ability for people to +1 or -1 is taken away, and this does not work.
>> (We don't want a situation where 3 people go ahead and +1, and that
>> arrives before today evening, thus making the release releasable,
>> while someone else discovers a breaking issue that should stop it, but
>> is not able to have their objection or -1 appear in time.)
>> 
>> I'm open to suggestions on how to proceed with the voting process. We
>> could wait out this week and hope the ASF mailing list issues are
>> resolved, but if it takes too much longer than that, we also have the
>> issue of delaying an important bugfix release.
>> 
>> Thoughts?
>> 
>> -Sushanth
>> (3:15PM PDT, May 15 2014)
>> 
>> 
>> 
>> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan <
>> khorg...@gmail.com>
 wrote:
>>> The apache dev list seems to still be a little wonky, Prasanth mailed
>>> me saying he'd replied to this thread with the following content,
>> that
>>> I don't see in this thread:
>>> 
>>> "Hi Sushanth
>>> 
>>> https://issues.apache.org/jira/browse/HIVE-7067
>>> This bug is critical as it returns wrong results for min(), max(),
>>> join queries that uses date/timestamp columns from ORC table.
>>> The reason for this issue is, for these datatypes ORC returns java
>>> objects whereas for all other types ORC returns writables.
>>> When get() is performed on their corresponding object inspectors,
>>> writables return a new object where as java object returns reference.
>>> This will cause issue when any operator perform comparison on
>>> date/timestamp values (references will be overwritten with next
>>> values).
>>> More informa

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Lefty Leverenz]

Gotta side with Alan about voting by JIRA:  although it's convenient for
the moment, the indirect mail records wouldn't be labeled [VOTE].  Some
future Hive historian could come to grief (and have to drop out of grad
school).

The community needs to see the votes as they come in, and shouldn't have to
look in the archives or JIRA comments.  What to do?  When can we expect the
mailing list to get back to normal?


-- Lefty


On Mon, May 19, 2014 at 8:00 AM, Alan Gates  wrote:

> The vote by mail requirement is an Apache one, which trumps any Hive
> bylaws.  I really think Apache is going to frown on voting via JIRA.
>
> Alan.
>
> On May 17, 2014, at 9:15 PM, Lefty Leverenz 
> wrote:
>
> > Hive bylaws<
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Voting>say
> > the mailing list is used for voting, but as I recall bylaws have some
> > wiggle room.
> >
> > Decisions regarding the project are made by votes on the primary project
> >> development mailing list (u...@hive.apache.org ).
> >> Where necessary, PMC voting may take place on the private Hive PMC
> mailing
> >> list. Votes are clearly indicated by subject line starting with [VOTE].
> >> Votes may contain multiple items for approval and these should be
> clearly
> >> separated. Voting is carried out by replying to the vote mail.
> >
> >
> > (Hm, the text says "primary project development mailing list" but then
> > user@hive is shown in parentheses -- is that a typo in the bylaws?)
> >
> > Would people be willing to vote simultaneously by mail and on a jira?
>  It's
> > inconvenient but shouldn't be necessary after this release.
> >
> > -- Lefty
> >
> >
> > On Sat, May 17, 2014 at 7:30 PM, Sushanth Sowmyan  >wrote:
> >
> >> There is a technical issue as well now, as raised by Prashant. But
> >> there is also the issue that people aren't reliably able to
> >> respond/object/approve, and not knowing if/when it'll go through.
> >>
> >> I think I like Lefty's jira proposal - we could open out a jira for it
> >> and address votes there, I think I'll do that for RC2.
> >>
> >> On Fri, May 16, 2014 at 2:53 PM, Alan Gates 
> wrote:
> >>> So this isn’t a technical issue, just concern about the delays in the
> >> mailing list?  Why not just extend the voting period then, until say
> Monday?
> >>>
> >>> Alan.
> >>>
> >>> On May 15, 2014, at 3:17 PM, Sushanth Sowmyan 
> >> wrote:
> >>>
>  Hi Folks,
> 
>  I'm canceling this vote and withdrawing the RC1 candidate for the
>  following reasons:
> 
>  a) I've talked to a couple of other people who haven't seen my mail
>  updates to this thread, and saw my initial vote mail a bit late too.
>  b) There's at least one other person that has attempted to reply to
>  this thread, and I don't see the replies yet.
> 
>  Thus, when the mailing list channel isn't reliably working, the
>  ability for people to +1 or -1 is taken away, and this does not work.
>  (We don't want a situation where 3 people go ahead and +1, and that
>  arrives before today evening, thus making the release releasable,
>  while someone else discovers a breaking issue that should stop it, but
>  is not able to have their objection or -1 appear in time.)
> 
>  I'm open to suggestions on how to proceed with the voting process. We
>  could wait out this week and hope the ASF mailing list issues are
>  resolved, but if it takes too much longer than that, we also have the
>  issue of delaying an important bugfix release.
> 
>  Thoughts?
> 
>  -Sushanth
>  (3:15PM PDT, May 15 2014)
> 
> 
> 
>  On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan <
> khorg...@gmail.com>
> >> wrote:
> > The apache dev list seems to still be a little wonky, Prasanth mailed
> > me saying he'd replied to this thread with the following content,
> that
> > I don't see in this thread:
> >
> > "Hi Sushanth
> >
> > https://issues.apache.org/jira/browse/HIVE-7067
> > This bug is critical as it returns wrong results for min(), max(),
> > join queries that uses date/timestamp columns from ORC table.
> > The reason for this issue is, for these datatypes ORC returns java
> > objects whereas for all other types ORC returns writables.
> > When get() is performed on their corresponding object inspectors,
> > writables return a new object where as java object returns reference.
> > This will cause issue when any operator perform comparison on
> > date/timestamp values (references will be overwritten with next
> > values).
> > More information is provided in the description of the jira.
> >
> > I think the severity of this bug is critical and should be included
> as
> > part of 0.13.1. Can you please include this patch in RC2?”
> >
> > I think this meets the bar for criticality(actual bug in core
> feature,
> > no workaround) and severity( incorrect results, effectively data

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Alan Gates]

The vote by mail requirement is an Apache one, which trumps any Hive bylaws.  I 
really think Apache is going to frown on voting via JIRA.

Alan.

On May 17, 2014, at 9:15 PM, Lefty Leverenz  wrote:

> Hive 
> bylawssay
> the mailing list is used for voting, but as I recall bylaws have some
> wiggle room.
> 
> Decisions regarding the project are made by votes on the primary project
>> development mailing list (u...@hive.apache.org ).
>> Where necessary, PMC voting may take place on the private Hive PMC mailing
>> list. Votes are clearly indicated by subject line starting with [VOTE].
>> Votes may contain multiple items for approval and these should be clearly
>> separated. Voting is carried out by replying to the vote mail.
> 
> 
> (Hm, the text says "primary project development mailing list" but then
> user@hive is shown in parentheses -- is that a typo in the bylaws?)
> 
> Would people be willing to vote simultaneously by mail and on a jira?  It's
> inconvenient but shouldn't be necessary after this release.
> 
> -- Lefty
> 
> 
> On Sat, May 17, 2014 at 7:30 PM, Sushanth Sowmyan wrote:
> 
>> There is a technical issue as well now, as raised by Prashant. But
>> there is also the issue that people aren't reliably able to
>> respond/object/approve, and not knowing if/when it'll go through.
>> 
>> I think I like Lefty's jira proposal - we could open out a jira for it
>> and address votes there, I think I'll do that for RC2.
>> 
>> On Fri, May 16, 2014 at 2:53 PM, Alan Gates  wrote:
>>> So this isn’t a technical issue, just concern about the delays in the
>> mailing list?  Why not just extend the voting period then, until say Monday?
>>> 
>>> Alan.
>>> 
>>> On May 15, 2014, at 3:17 PM, Sushanth Sowmyan 
>> wrote:
>>> 
 Hi Folks,
 
 I'm canceling this vote and withdrawing the RC1 candidate for the
 following reasons:
 
 a) I've talked to a couple of other people who haven't seen my mail
 updates to this thread, and saw my initial vote mail a bit late too.
 b) There's at least one other person that has attempted to reply to
 this thread, and I don't see the replies yet.
 
 Thus, when the mailing list channel isn't reliably working, the
 ability for people to +1 or -1 is taken away, and this does not work.
 (We don't want a situation where 3 people go ahead and +1, and that
 arrives before today evening, thus making the release releasable,
 while someone else discovers a breaking issue that should stop it, but
 is not able to have their objection or -1 appear in time.)
 
 I'm open to suggestions on how to proceed with the voting process. We
 could wait out this week and hope the ASF mailing list issues are
 resolved, but if it takes too much longer than that, we also have the
 issue of delaying an important bugfix release.
 
 Thoughts?
 
 -Sushanth
 (3:15PM PDT, May 15 2014)
 
 
 
 On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan 
>> wrote:
> The apache dev list seems to still be a little wonky, Prasanth mailed
> me saying he'd replied to this thread with the following content, that
> I don't see in this thread:
> 
> "Hi Sushanth
> 
> https://issues.apache.org/jira/browse/HIVE-7067
> This bug is critical as it returns wrong results for min(), max(),
> join queries that uses date/timestamp columns from ORC table.
> The reason for this issue is, for these datatypes ORC returns java
> objects whereas for all other types ORC returns writables.
> When get() is performed on their corresponding object inspectors,
> writables return a new object where as java object returns reference.
> This will cause issue when any operator perform comparison on
> date/timestamp values (references will be overwritten with next
> values).
> More information is provided in the description of the jira.
> 
> I think the severity of this bug is critical and should be included as
> part of 0.13.1. Can you please include this patch in RC2?”
> 
> I think this meets the bar for criticality(actual bug in core feature,
> no workaround) and severity( incorrect results, effectively data
> corruption when used as source for other data), and I'm willing to
> spin an RC2 for this, but I would still like to follow the process I
> set up for jira inclusion though, to make sure I'm not being biased
> about this, so I would request two other +1s to champion this bug's
> inclusion into the release.
> 
> Also, another thought here is whether it makes sense for us to try to
> have a VOTE with a 72 hour deadline when the mailing list still seems
> iffy and delaying mails by multiple hours. Any thoughts on how we
> should proceed? (In case this mail goes out much later than I send it
> out, I'm sending it out at 11:45AM PDT, Thu May 15 

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Edward Capriolo]

"Voting will conclude in 72 hours."

This statement is not correct. The vote stays open as long as it needs to.
The 72 hour window is a window for someone to register a -1 vote. The vote
stays open until it passes. So... if there are two +1 votes in 24 hours and
6 days later someone registers the third +1 the vote passes.

Again the 72 hours is the minimal amount of time for someone to get in a
-1. If someone does not have time to put in a -1 they missed their boat.

Anyway +1 on hive 13.1



On Sun, May 18, 2014 at 12:15 AM, Lefty Leverenz wrote:

> Hive bylaws<
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Voting>say
> the mailing list is used for voting, but as I recall bylaws have some
> wiggle room.
>
> Decisions regarding the project are made by votes on the primary project
> > development mailing list (u...@hive.apache.org ).
> > Where necessary, PMC voting may take place on the private Hive PMC
> mailing
> > list. Votes are clearly indicated by subject line starting with [VOTE].
> > Votes may contain multiple items for approval and these should be clearly
> > separated. Voting is carried out by replying to the vote mail.
>
>
> (Hm, the text says "primary project development mailing list" but then
> user@hive is shown in parentheses -- is that a typo in the bylaws?)
>
> Would people be willing to vote simultaneously by mail and on a jira?  It's
> inconvenient but shouldn't be necessary after this release.
>
> -- Lefty
>
>
> On Sat, May 17, 2014 at 7:30 PM, Sushanth Sowmyan  >wrote:
>
> > There is a technical issue as well now, as raised by Prashant. But
> > there is also the issue that people aren't reliably able to
> > respond/object/approve, and not knowing if/when it'll go through.
> >
> > I think I like Lefty's jira proposal - we could open out a jira for it
> > and address votes there, I think I'll do that for RC2.
> >
> > On Fri, May 16, 2014 at 2:53 PM, Alan Gates 
> wrote:
> > > So this isn’t a technical issue, just concern about the delays in the
> > mailing list?  Why not just extend the voting period then, until say
> Monday?
> > >
> > > Alan.
> > >
> > > On May 15, 2014, at 3:17 PM, Sushanth Sowmyan 
> > wrote:
> > >
> > >> Hi Folks,
> > >>
> > >> I'm canceling this vote and withdrawing the RC1 candidate for the
> > >> following reasons:
> > >>
> > >> a) I've talked to a couple of other people who haven't seen my mail
> > >> updates to this thread, and saw my initial vote mail a bit late too.
> > >> b) There's at least one other person that has attempted to reply to
> > >> this thread, and I don't see the replies yet.
> > >>
> > >> Thus, when the mailing list channel isn't reliably working, the
> > >> ability for people to +1 or -1 is taken away, and this does not work.
> > >> (We don't want a situation where 3 people go ahead and +1, and that
> > >> arrives before today evening, thus making the release releasable,
> > >> while someone else discovers a breaking issue that should stop it, but
> > >> is not able to have their objection or -1 appear in time.)
> > >>
> > >> I'm open to suggestions on how to proceed with the voting process. We
> > >> could wait out this week and hope the ASF mailing list issues are
> > >> resolved, but if it takes too much longer than that, we also have the
> > >> issue of delaying an important bugfix release.
> > >>
> > >> Thoughts?
> > >>
> > >> -Sushanth
> > >> (3:15PM PDT, May 15 2014)
> > >>
> > >>
> > >>
> > >> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan <
> khorg...@gmail.com>
> > wrote:
> > >>> The apache dev list seems to still be a little wonky, Prasanth mailed
> > >>> me saying he'd replied to this thread with the following content,
> that
> > >>> I don't see in this thread:
> > >>>
> > >>> "Hi Sushanth
> > >>>
> > >>> https://issues.apache.org/jira/browse/HIVE-7067
> > >>> This bug is critical as it returns wrong results for min(), max(),
> > >>> join queries that uses date/timestamp columns from ORC table.
> > >>> The reason for this issue is, for these datatypes ORC returns java
> > >>> objects whereas for all other types ORC returns writables.
> > >>> When get() is performed on their corresponding object inspectors,
> > >>> writables return a new object where as java object returns reference.
> > >>> This will cause issue when any operator perform comparison on
> > >>> date/timestamp values (references will be overwritten with next
> > >>> values).
> > >>> More information is provided in the description of the jira.
> > >>>
> > >>> I think the severity of this bug is critical and should be included
> as
> > >>> part of 0.13.1. Can you please include this patch in RC2?”
> > >>>
> > >>> I think this meets the bar for criticality(actual bug in core
> feature,
> > >>> no workaround) and severity( incorrect results, effectively data
> > >>> corruption when used as source for other data), and I'm willing to
> > >>> spin an RC2 for this, but I would still like to follow the process I
> > >>> set up for jira inclusion though, 

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Lefty Leverenz]

Hive 
bylawssay
the mailing list is used for voting, but as I recall bylaws have some
wiggle room.

Decisions regarding the project are made by votes on the primary project
> development mailing list (u...@hive.apache.org ).
> Where necessary, PMC voting may take place on the private Hive PMC mailing
> list. Votes are clearly indicated by subject line starting with [VOTE].
> Votes may contain multiple items for approval and these should be clearly
> separated. Voting is carried out by replying to the vote mail.


(Hm, the text says "primary project development mailing list" but then
user@hive is shown in parentheses -- is that a typo in the bylaws?)

Would people be willing to vote simultaneously by mail and on a jira?  It's
inconvenient but shouldn't be necessary after this release.

-- Lefty


On Sat, May 17, 2014 at 7:30 PM, Sushanth Sowmyan wrote:

> There is a technical issue as well now, as raised by Prashant. But
> there is also the issue that people aren't reliably able to
> respond/object/approve, and not knowing if/when it'll go through.
>
> I think I like Lefty's jira proposal - we could open out a jira for it
> and address votes there, I think I'll do that for RC2.
>
> On Fri, May 16, 2014 at 2:53 PM, Alan Gates  wrote:
> > So this isn’t a technical issue, just concern about the delays in the
> mailing list?  Why not just extend the voting period then, until say Monday?
> >
> > Alan.
> >
> > On May 15, 2014, at 3:17 PM, Sushanth Sowmyan 
> wrote:
> >
> >> Hi Folks,
> >>
> >> I'm canceling this vote and withdrawing the RC1 candidate for the
> >> following reasons:
> >>
> >> a) I've talked to a couple of other people who haven't seen my mail
> >> updates to this thread, and saw my initial vote mail a bit late too.
> >> b) There's at least one other person that has attempted to reply to
> >> this thread, and I don't see the replies yet.
> >>
> >> Thus, when the mailing list channel isn't reliably working, the
> >> ability for people to +1 or -1 is taken away, and this does not work.
> >> (We don't want a situation where 3 people go ahead and +1, and that
> >> arrives before today evening, thus making the release releasable,
> >> while someone else discovers a breaking issue that should stop it, but
> >> is not able to have their objection or -1 appear in time.)
> >>
> >> I'm open to suggestions on how to proceed with the voting process. We
> >> could wait out this week and hope the ASF mailing list issues are
> >> resolved, but if it takes too much longer than that, we also have the
> >> issue of delaying an important bugfix release.
> >>
> >> Thoughts?
> >>
> >> -Sushanth
> >> (3:15PM PDT, May 15 2014)
> >>
> >>
> >>
> >> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan 
> wrote:
> >>> The apache dev list seems to still be a little wonky, Prasanth mailed
> >>> me saying he'd replied to this thread with the following content, that
> >>> I don't see in this thread:
> >>>
> >>> "Hi Sushanth
> >>>
> >>> https://issues.apache.org/jira/browse/HIVE-7067
> >>> This bug is critical as it returns wrong results for min(), max(),
> >>> join queries that uses date/timestamp columns from ORC table.
> >>> The reason for this issue is, for these datatypes ORC returns java
> >>> objects whereas for all other types ORC returns writables.
> >>> When get() is performed on their corresponding object inspectors,
> >>> writables return a new object where as java object returns reference.
> >>> This will cause issue when any operator perform comparison on
> >>> date/timestamp values (references will be overwritten with next
> >>> values).
> >>> More information is provided in the description of the jira.
> >>>
> >>> I think the severity of this bug is critical and should be included as
> >>> part of 0.13.1. Can you please include this patch in RC2?”
> >>>
> >>> I think this meets the bar for criticality(actual bug in core feature,
> >>> no workaround) and severity( incorrect results, effectively data
> >>> corruption when used as source for other data), and I'm willing to
> >>> spin an RC2 for this, but I would still like to follow the process I
> >>> set up for jira inclusion though, to make sure I'm not being biased
> >>> about this, so I would request two other +1s to champion this bug's
> >>> inclusion into the release.
> >>>
> >>> Also, another thought here is whether it makes sense for us to try to
> >>> have a VOTE with a 72 hour deadline when the mailing list still seems
> >>> iffy and delaying mails by multiple hours. Any thoughts on how we
> >>> should proceed? (In case this mail goes out much later than I send it
> >>> out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)
> >>>
> >>>
> >>>
> >>> On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan 
> wrote:
>  Eugene, do you know if these two failures happen on 0.13.0 as well?
> 
>  I would assume that TestHive_7 is an issue on 0.13.0 as well, given
>  that the fix for i

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Sushanth Sowmyan]

There is a technical issue as well now, as raised by Prashant. But
there is also the issue that people aren't reliably able to
respond/object/approve, and not knowing if/when it'll go through.

I think I like Lefty's jira proposal - we could open out a jira for it
and address votes there, I think I'll do that for RC2.

On Fri, May 16, 2014 at 2:53 PM, Alan Gates  wrote:
> So this isn’t a technical issue, just concern about the delays in the mailing 
> list?  Why not just extend the voting period then, until say Monday?
>
> Alan.
>
> On May 15, 2014, at 3:17 PM, Sushanth Sowmyan  wrote:
>
>> Hi Folks,
>>
>> I'm canceling this vote and withdrawing the RC1 candidate for the
>> following reasons:
>>
>> a) I've talked to a couple of other people who haven't seen my mail
>> updates to this thread, and saw my initial vote mail a bit late too.
>> b) There's at least one other person that has attempted to reply to
>> this thread, and I don't see the replies yet.
>>
>> Thus, when the mailing list channel isn't reliably working, the
>> ability for people to +1 or -1 is taken away, and this does not work.
>> (We don't want a situation where 3 people go ahead and +1, and that
>> arrives before today evening, thus making the release releasable,
>> while someone else discovers a breaking issue that should stop it, but
>> is not able to have their objection or -1 appear in time.)
>>
>> I'm open to suggestions on how to proceed with the voting process. We
>> could wait out this week and hope the ASF mailing list issues are
>> resolved, but if it takes too much longer than that, we also have the
>> issue of delaying an important bugfix release.
>>
>> Thoughts?
>>
>> -Sushanth
>> (3:15PM PDT, May 15 2014)
>>
>>
>>
>> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan  
>> wrote:
>>> The apache dev list seems to still be a little wonky, Prasanth mailed
>>> me saying he'd replied to this thread with the following content, that
>>> I don't see in this thread:
>>>
>>> "Hi Sushanth
>>>
>>> https://issues.apache.org/jira/browse/HIVE-7067
>>> This bug is critical as it returns wrong results for min(), max(),
>>> join queries that uses date/timestamp columns from ORC table.
>>> The reason for this issue is, for these datatypes ORC returns java
>>> objects whereas for all other types ORC returns writables.
>>> When get() is performed on their corresponding object inspectors,
>>> writables return a new object where as java object returns reference.
>>> This will cause issue when any operator perform comparison on
>>> date/timestamp values (references will be overwritten with next
>>> values).
>>> More information is provided in the description of the jira.
>>>
>>> I think the severity of this bug is critical and should be included as
>>> part of 0.13.1. Can you please include this patch in RC2?”
>>>
>>> I think this meets the bar for criticality(actual bug in core feature,
>>> no workaround) and severity( incorrect results, effectively data
>>> corruption when used as source for other data), and I'm willing to
>>> spin an RC2 for this, but I would still like to follow the process I
>>> set up for jira inclusion though, to make sure I'm not being biased
>>> about this, so I would request two other +1s to champion this bug's
>>> inclusion into the release.
>>>
>>> Also, another thought here is whether it makes sense for us to try to
>>> have a VOTE with a 72 hour deadline when the mailing list still seems
>>> iffy and delaying mails by multiple hours. Any thoughts on how we
>>> should proceed? (In case this mail goes out much later than I send it
>>> out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)
>>>
>>>
>>>
>>> On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan  
>>> wrote:
 Eugene, do you know if these two failures happen on 0.13.0 as well?

 I would assume that TestHive_7 is an issue on 0.13.0 as well, given
 that the fix for it went into trunk. What is your sense for how
 important it is that we fix this? i.e., per my understanding, (a) It
 does not cause a crash or adversly affect the ability for webhcat to
 continue operating, and (b) It means that the feature does not work
 (at all, but in isolation), and that there is no work around for it.
 This means I treat it as critical(valid bug without workaround) but
 not severe(breaks product, affects other features from being used).
 Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
 committers +1 an inclusion request for this.

 As for TestHeartbeat_1, that's an interesting failure. Do you have
 logs on what commandline options
 org.apache.hive.hcatalog.templeton.LauncherDelegator sent along that
 caused it to break? Would that affect other job launches?


 On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman
  wrote:
> TestHive_7 is explained by 
> https://issues.apache.org/jira/browse/HIVE-6521,
> which is in trunk but not 13.1
>
>
> On Tue, May 13, 2014 

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Alan Gates]

On May 16, 2014, at 10:51 PM, Lefty Leverenz  wrote:

>> Any thoughts on how we should proceed?
> 
>  1. Is the mail archive accurate now?  Perhaps it could be used for vote
>  verification.
>  2. What if we voted in comments on a JIRA ticket?  (Lately I'm checking
>  comment order on JIRAs because my inbox receives messages out of order.)
No, it has to use mail as the primary medium I think.  But the archives are 
accurate.

Alan.

> 
> The JIRA is connected to the mailing list, so it might comply with the
> vote-by-email rule.
> 
> -- Lefty
> 
> 
> On Fri, May 16, 2014 at 2:53 PM, Alan Gates  wrote:
> 
>> So this isn’t a technical issue, just concern about the delays in the
>> mailing list?  Why not just extend the voting period then, until say Monday?
>> 
>> Alan.
>> 
>> On May 15, 2014, at 3:17 PM, Sushanth Sowmyan  wrote:
>> 
>>> Hi Folks,
>>> 
>>> I'm canceling this vote and withdrawing the RC1 candidate for the
>>> following reasons:
>>> 
>>> a) I've talked to a couple of other people who haven't seen my mail
>>> updates to this thread, and saw my initial vote mail a bit late too.
>>> b) There's at least one other person that has attempted to reply to
>>> this thread, and I don't see the replies yet.
>>> 
>>> Thus, when the mailing list channel isn't reliably working, the
>>> ability for people to +1 or -1 is taken away, and this does not work.
>>> (We don't want a situation where 3 people go ahead and +1, and that
>>> arrives before today evening, thus making the release releasable,
>>> while someone else discovers a breaking issue that should stop it, but
>>> is not able to have their objection or -1 appear in time.)
>>> 
>>> I'm open to suggestions on how to proceed with the voting process. We
>>> could wait out this week and hope the ASF mailing list issues are
>>> resolved, but if it takes too much longer than that, we also have the
>>> issue of delaying an important bugfix release.
>>> 
>>> Thoughts?
>>> 
>>> -Sushanth
>>> (3:15PM PDT, May 15 2014)
>>> 
>>> 
>>> 
>>> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan 
>> wrote:
 The apache dev list seems to still be a little wonky, Prasanth mailed
 me saying he'd replied to this thread with the following content, that
 I don't see in this thread:
 
 "Hi Sushanth
 
 https://issues.apache.org/jira/browse/HIVE-7067
 This bug is critical as it returns wrong results for min(), max(),
 join queries that uses date/timestamp columns from ORC table.
 The reason for this issue is, for these datatypes ORC returns java
 objects whereas for all other types ORC returns writables.
 When get() is performed on their corresponding object inspectors,
 writables return a new object where as java object returns reference.
 This will cause issue when any operator perform comparison on
 date/timestamp values (references will be overwritten with next
 values).
 More information is provided in the description of the jira.
 
 I think the severity of this bug is critical and should be included as
 part of 0.13.1. Can you please include this patch in RC2?”
 
 I think this meets the bar for criticality(actual bug in core feature,
 no workaround) and severity( incorrect results, effectively data
 corruption when used as source for other data), and I'm willing to
 spin an RC2 for this, but I would still like to follow the process I
 set up for jira inclusion though, to make sure I'm not being biased
 about this, so I would request two other +1s to champion this bug's
 inclusion into the release.
 
 Also, another thought here is whether it makes sense for us to try to
 have a VOTE with a 72 hour deadline when the mailing list still seems
 iffy and delaying mails by multiple hours. Any thoughts on how we
 should proceed? (In case this mail goes out much later than I send it
 out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)
 
 
 
 On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan 
>> wrote:
> Eugene, do you know if these two failures happen on 0.13.0 as well?
> 
> I would assume that TestHive_7 is an issue on 0.13.0 as well, given
> that the fix for it went into trunk. What is your sense for how
> important it is that we fix this? i.e., per my understanding, (a) It
> does not cause a crash or adversly affect the ability for webhcat to
> continue operating, and (b) It means that the feature does not work
> (at all, but in isolation), and that there is no work around for it.
> This means I treat it as critical(valid bug without workaround) but
> not severe(breaks product, affects other features from being used).
> Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
> committers +1 an inclusion request for this.
> 
> As for TestHeartbeat_1, that's an interesting failure. Do you have
> logs on what commandline options
> org.apache.hive.hcatalog

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Lefty Leverenz]

> Any thoughts on how we should proceed?

   1. Is the mail archive accurate now?  Perhaps it could be used for vote
   verification.
   2. What if we voted in comments on a JIRA ticket?  (Lately I'm checking
   comment order on JIRAs because my inbox receives messages out of order.)

The JIRA is connected to the mailing list, so it might comply with the
vote-by-email rule.

-- Lefty


On Fri, May 16, 2014 at 2:53 PM, Alan Gates  wrote:

> So this isn’t a technical issue, just concern about the delays in the
> mailing list?  Why not just extend the voting period then, until say Monday?
>
> Alan.
>
> On May 15, 2014, at 3:17 PM, Sushanth Sowmyan  wrote:
>
> > Hi Folks,
> >
> > I'm canceling this vote and withdrawing the RC1 candidate for the
> > following reasons:
> >
> > a) I've talked to a couple of other people who haven't seen my mail
> > updates to this thread, and saw my initial vote mail a bit late too.
> > b) There's at least one other person that has attempted to reply to
> > this thread, and I don't see the replies yet.
> >
> > Thus, when the mailing list channel isn't reliably working, the
> > ability for people to +1 or -1 is taken away, and this does not work.
> > (We don't want a situation where 3 people go ahead and +1, and that
> > arrives before today evening, thus making the release releasable,
> > while someone else discovers a breaking issue that should stop it, but
> > is not able to have their objection or -1 appear in time.)
> >
> > I'm open to suggestions on how to proceed with the voting process. We
> > could wait out this week and hope the ASF mailing list issues are
> > resolved, but if it takes too much longer than that, we also have the
> > issue of delaying an important bugfix release.
> >
> > Thoughts?
> >
> > -Sushanth
> > (3:15PM PDT, May 15 2014)
> >
> >
> >
> > On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan 
> wrote:
> >> The apache dev list seems to still be a little wonky, Prasanth mailed
> >> me saying he'd replied to this thread with the following content, that
> >> I don't see in this thread:
> >>
> >> "Hi Sushanth
> >>
> >> https://issues.apache.org/jira/browse/HIVE-7067
> >> This bug is critical as it returns wrong results for min(), max(),
> >> join queries that uses date/timestamp columns from ORC table.
> >> The reason for this issue is, for these datatypes ORC returns java
> >> objects whereas for all other types ORC returns writables.
> >> When get() is performed on their corresponding object inspectors,
> >> writables return a new object where as java object returns reference.
> >> This will cause issue when any operator perform comparison on
> >> date/timestamp values (references will be overwritten with next
> >> values).
> >> More information is provided in the description of the jira.
> >>
> >> I think the severity of this bug is critical and should be included as
> >> part of 0.13.1. Can you please include this patch in RC2?”
> >>
> >> I think this meets the bar for criticality(actual bug in core feature,
> >> no workaround) and severity( incorrect results, effectively data
> >> corruption when used as source for other data), and I'm willing to
> >> spin an RC2 for this, but I would still like to follow the process I
> >> set up for jira inclusion though, to make sure I'm not being biased
> >> about this, so I would request two other +1s to champion this bug's
> >> inclusion into the release.
> >>
> >> Also, another thought here is whether it makes sense for us to try to
> >> have a VOTE with a 72 hour deadline when the mailing list still seems
> >> iffy and delaying mails by multiple hours. Any thoughts on how we
> >> should proceed? (In case this mail goes out much later than I send it
> >> out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)
> >>
> >>
> >>
> >> On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan 
> wrote:
> >>> Eugene, do you know if these two failures happen on 0.13.0 as well?
> >>>
> >>> I would assume that TestHive_7 is an issue on 0.13.0 as well, given
> >>> that the fix for it went into trunk. What is your sense for how
> >>> important it is that we fix this? i.e., per my understanding, (a) It
> >>> does not cause a crash or adversly affect the ability for webhcat to
> >>> continue operating, and (b) It means that the feature does not work
> >>> (at all, but in isolation), and that there is no work around for it.
> >>> This means I treat it as critical(valid bug without workaround) but
> >>> not severe(breaks product, affects other features from being used).
> >>> Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
> >>> committers +1 an inclusion request for this.
> >>>
> >>> As for TestHeartbeat_1, that's an interesting failure. Do you have
> >>> logs on what commandline options
> >>> org.apache.hive.hcatalog.templeton.LauncherDelegator sent along that
> >>> caused it to break? Would that affect other job launches?
> >>>
> >>>
> >>> On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman
> >>>  wrote:
>  TestHi

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Alan Gates]

So this isn’t a technical issue, just concern about the delays in the mailing 
list?  Why not just extend the voting period then, until say Monday?

Alan.

On May 15, 2014, at 3:17 PM, Sushanth Sowmyan  wrote:

> Hi Folks,
> 
> I'm canceling this vote and withdrawing the RC1 candidate for the
> following reasons:
> 
> a) I've talked to a couple of other people who haven't seen my mail
> updates to this thread, and saw my initial vote mail a bit late too.
> b) There's at least one other person that has attempted to reply to
> this thread, and I don't see the replies yet.
> 
> Thus, when the mailing list channel isn't reliably working, the
> ability for people to +1 or -1 is taken away, and this does not work.
> (We don't want a situation where 3 people go ahead and +1, and that
> arrives before today evening, thus making the release releasable,
> while someone else discovers a breaking issue that should stop it, but
> is not able to have their objection or -1 appear in time.)
> 
> I'm open to suggestions on how to proceed with the voting process. We
> could wait out this week and hope the ASF mailing list issues are
> resolved, but if it takes too much longer than that, we also have the
> issue of delaying an important bugfix release.
> 
> Thoughts?
> 
> -Sushanth
> (3:15PM PDT, May 15 2014)
> 
> 
> 
> On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan  wrote:
>> The apache dev list seems to still be a little wonky, Prasanth mailed
>> me saying he'd replied to this thread with the following content, that
>> I don't see in this thread:
>> 
>> "Hi Sushanth
>> 
>> https://issues.apache.org/jira/browse/HIVE-7067
>> This bug is critical as it returns wrong results for min(), max(),
>> join queries that uses date/timestamp columns from ORC table.
>> The reason for this issue is, for these datatypes ORC returns java
>> objects whereas for all other types ORC returns writables.
>> When get() is performed on their corresponding object inspectors,
>> writables return a new object where as java object returns reference.
>> This will cause issue when any operator perform comparison on
>> date/timestamp values (references will be overwritten with next
>> values).
>> More information is provided in the description of the jira.
>> 
>> I think the severity of this bug is critical and should be included as
>> part of 0.13.1. Can you please include this patch in RC2?”
>> 
>> I think this meets the bar for criticality(actual bug in core feature,
>> no workaround) and severity( incorrect results, effectively data
>> corruption when used as source for other data), and I'm willing to
>> spin an RC2 for this, but I would still like to follow the process I
>> set up for jira inclusion though, to make sure I'm not being biased
>> about this, so I would request two other +1s to champion this bug's
>> inclusion into the release.
>> 
>> Also, another thought here is whether it makes sense for us to try to
>> have a VOTE with a 72 hour deadline when the mailing list still seems
>> iffy and delaying mails by multiple hours. Any thoughts on how we
>> should proceed? (In case this mail goes out much later than I send it
>> out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)
>> 
>> 
>> 
>> On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan  
>> wrote:
>>> Eugene, do you know if these two failures happen on 0.13.0 as well?
>>> 
>>> I would assume that TestHive_7 is an issue on 0.13.0 as well, given
>>> that the fix for it went into trunk. What is your sense for how
>>> important it is that we fix this? i.e., per my understanding, (a) It
>>> does not cause a crash or adversly affect the ability for webhcat to
>>> continue operating, and (b) It means that the feature does not work
>>> (at all, but in isolation), and that there is no work around for it.
>>> This means I treat it as critical(valid bug without workaround) but
>>> not severe(breaks product, affects other features from being used).
>>> Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
>>> committers +1 an inclusion request for this.
>>> 
>>> As for TestHeartbeat_1, that's an interesting failure. Do you have
>>> logs on what commandline options
>>> org.apache.hive.hcatalog.templeton.LauncherDelegator sent along that
>>> caused it to break? Would that affect other job launches?
>>> 
>>> 
>>> On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman
>>>  wrote:
 TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
 which is in trunk but not 13.1
 
 
 On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman 
 wrote:
 
> I downloaded src tar, built it and ran webhcat e2e tests.
> I see 2 failures (which I don't see on trunk)
> 
> TestHive_7 fails with
> "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"
> 
> TestHeartbeat_1 fails to even launch the job.  This looks like the root
> cause
> 
> ERROR | 13 May 2014 18:24:00,394 |
> org.apache.hive.hcatalog.templeton.Catc

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Sushanth Sowmyan]

Eugene, do you know if these two failures happen on 0.13.0 as well?

I would assume that TestHive_7 is an issue on 0.13.0 as well, given
that the fix for it went into trunk. What is your sense for how
important it is that we fix this? i.e., per my understanding, (a) It
does not cause a crash or adversly affect the ability for webhcat to
continue operating, and (b) It means that the feature does not work
(at all, but in isolation), and that there is no work around for it.
This means I treat it as critical(valid bug without workaround) but
not severe(breaks product, affects other features from being used).
Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
committers +1 an inclusion request for this.

As for TestHeartbeat_1, that's an interesting failure. Do you have
logs on what commandline options
org.apache.hive.hcatalog.templeton.LauncherDelegator sent along that
caused it to break? Would that affect other job launches?


On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman
 wrote:
> TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
> which is in trunk but not 13.1
>
>
> On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman 
> wrote:
>
>> I downloaded src tar, built it and ran webhcat e2e tests.
>> I see 2 failures (which I don't see on trunk)
>>
>> TestHive_7 fails with
>> "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"
>>
>> TestHeartbeat_1 fails to even launch the job.  This looks like the root
>> cause
>>
>> ERROR | 13 May 2014 18:24:00,394 |
>> org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
>> java.lang.NullPointerException
>> at
>> org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
>> at
>> org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
>> at
>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:170)
>> at
>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:153)
>> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:64)
>> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:107)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:103)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at javax.security.auth.Subject.doAs(Subject.java:396)
>> at
>> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1557)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator.queueAsUser(LauncherDelegator.java:103)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator.enqueueController(LauncherDelegator.java:81)
>> at
>> org.apache.hive.hcatalog.templeton.JarDelegator.run(JarDelegator.java:55)
>> at
>> org.apache.hive.hcatalog.templeton.Server.mapReduceJar(Server.java:711)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>> at
>> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>> at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>> at
>> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>> at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>> at
>> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1480)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1411)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1360)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1350)
>> at
>> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>> at
>> com.sun.jersey.spi.container.servlet.ServletContainer.servi

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Sushanth Sowmyan]

Hi Folks,

I'm canceling this vote and withdrawing the RC1 candidate for the
following reasons:

a) I've talked to a couple of other people who haven't seen my mail
updates to this thread, and saw my initial vote mail a bit late too.
b) There's at least one other person that has attempted to reply to
this thread, and I don't see the replies yet.

Thus, when the mailing list channel isn't reliably working, the
ability for people to +1 or -1 is taken away, and this does not work.
(We don't want a situation where 3 people go ahead and +1, and that
arrives before today evening, thus making the release releasable,
while someone else discovers a breaking issue that should stop it, but
is not able to have their objection or -1 appear in time.)

I'm open to suggestions on how to proceed with the voting process. We
could wait out this week and hope the ASF mailing list issues are
resolved, but if it takes too much longer than that, we also have the
issue of delaying an important bugfix release.

Thoughts?

-Sushanth
(3:15PM PDT, May 15 2014)



On Thu, May 15, 2014 at 11:46 AM, Sushanth Sowmyan  wrote:
> The apache dev list seems to still be a little wonky, Prasanth mailed
> me saying he'd replied to this thread with the following content, that
> I don't see in this thread:
>
> "Hi Sushanth
>
> https://issues.apache.org/jira/browse/HIVE-7067
> This bug is critical as it returns wrong results for min(), max(),
> join queries that uses date/timestamp columns from ORC table.
> The reason for this issue is, for these datatypes ORC returns java
> objects whereas for all other types ORC returns writables.
> When get() is performed on their corresponding object inspectors,
> writables return a new object where as java object returns reference.
> This will cause issue when any operator perform comparison on
> date/timestamp values (references will be overwritten with next
> values).
> More information is provided in the description of the jira.
>
> I think the severity of this bug is critical and should be included as
> part of 0.13.1. Can you please include this patch in RC2?”
>
> I think this meets the bar for criticality(actual bug in core feature,
> no workaround) and severity( incorrect results, effectively data
> corruption when used as source for other data), and I'm willing to
> spin an RC2 for this, but I would still like to follow the process I
> set up for jira inclusion though, to make sure I'm not being biased
> about this, so I would request two other +1s to champion this bug's
> inclusion into the release.
>
> Also, another thought here is whether it makes sense for us to try to
> have a VOTE with a 72 hour deadline when the mailing list still seems
> iffy and delaying mails by multiple hours. Any thoughts on how we
> should proceed? (In case this mail goes out much later than I send it
> out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)
>
>
>
> On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan  wrote:
>> Eugene, do you know if these two failures happen on 0.13.0 as well?
>>
>> I would assume that TestHive_7 is an issue on 0.13.0 as well, given
>> that the fix for it went into trunk. What is your sense for how
>> important it is that we fix this? i.e., per my understanding, (a) It
>> does not cause a crash or adversly affect the ability for webhcat to
>> continue operating, and (b) It means that the feature does not work
>> (at all, but in isolation), and that there is no work around for it.
>> This means I treat it as critical(valid bug without workaround) but
>> not severe(breaks product, affects other features from being used).
>> Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
>> committers +1 an inclusion request for this.
>>
>> As for TestHeartbeat_1, that's an interesting failure. Do you have
>> logs on what commandline options
>> org.apache.hive.hcatalog.templeton.LauncherDelegator sent along that
>> caused it to break? Would that affect other job launches?
>>
>>
>> On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman
>>  wrote:
>>> TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
>>> which is in trunk but not 13.1
>>>
>>>
>>> On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman 
>>> wrote:
>>>
 I downloaded src tar, built it and ran webhcat e2e tests.
 I see 2 failures (which I don't see on trunk)

 TestHive_7 fails with
 "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"

 TestHeartbeat_1 fails to even launch the job.  This looks like the root
 cause

 ERROR | 13 May 2014 18:24:00,394 |
 org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
 java.lang.NullPointerException
 at
 org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
 at
 org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
 at
 org.apache.hadoop.util.GenericOptionsParser.(GenericOptio

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Prasanth Jayachandran]

Hi Sushanth

https://issues.apache.org/jira/browse/HIVE-7067
This bug is critical as it returns wrong results for min(), max(), join queries 
that uses date/timestamp columns from ORC table.
The reason for this issue is, for these datatypes ORC returns java objects 
whereas for all other types ORC returns writables.
When get() is performed on their corresponding object inspectors, writables 
return a new object where as java object returns reference.
This will cause issue when any operator perform comparison on date/timestamp 
values (references will be overwritten with next values).
More information is provided in the description of the jira.

I think the severity of this bug is critical and should be included as part of 
0.13.1. Can you please include this patch in RC2?

Thanks
Prasanth Jayachandran

On May 13, 2014, at 8:14 PM, Eugene Koifman  wrote:

> TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
> which is in trunk but not 13.1
> 
> 
> On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman 
> wrote:
> 
>> I downloaded src tar, built it and ran webhcat e2e tests.
>> I see 2 failures (which I don't see on trunk)
>> 
>> TestHive_7 fails with
>> "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"
>> 
>> TestHeartbeat_1 fails to even launch the job.  This looks like the root
>> cause
>> 
>> ERROR | 13 May 2014 18:24:00,394 |
>> org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
>> java.lang.NullPointerException
>>at
>> org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
>>at
>> org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
>>at
>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:170)
>>at
>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:153)
>>at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:64)
>>at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
>>at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:107)
>>at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:103)
>>at java.security.AccessController.doPrivileged(Native Method)
>>at javax.security.auth.Subject.doAs(Subject.java:396)
>>at
>> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1557)
>>at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator.queueAsUser(LauncherDelegator.java:103)
>>at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator.enqueueController(LauncherDelegator.java:81)
>>at
>> org.apache.hive.hcatalog.templeton.JarDelegator.run(JarDelegator.java:55)
>>at
>> org.apache.hive.hcatalog.templeton.Server.mapReduceJar(Server.java:711)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>at java.lang.reflect.Method.invoke(Method.java:597)
>>at
>> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>>at
>> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>>at
>> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>>at
>> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>>at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>>at
>> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>>at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>>at
>> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>>at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1480)
>>at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1411)
>>at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1360)
>>at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1350)
>>at
>> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>>at
>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>>at
>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>>at javax.servlet.http.Htt

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Sushanth Sowmyan]

The apache dev list seems to still be a little wonky, Prasanth mailed
me saying he'd replied to this thread with the following content, that
I don't see in this thread:

"Hi Sushanth

https://issues.apache.org/jira/browse/HIVE-7067
This bug is critical as it returns wrong results for min(), max(),
join queries that uses date/timestamp columns from ORC table.
The reason for this issue is, for these datatypes ORC returns java
objects whereas for all other types ORC returns writables.
When get() is performed on their corresponding object inspectors,
writables return a new object where as java object returns reference.
This will cause issue when any operator perform comparison on
date/timestamp values (references will be overwritten with next
values).
More information is provided in the description of the jira.

I think the severity of this bug is critical and should be included as
part of 0.13.1. Can you please include this patch in RC2?”

I think this meets the bar for criticality(actual bug in core feature,
no workaround) and severity( incorrect results, effectively data
corruption when used as source for other data), and I'm willing to
spin an RC2 for this, but I would still like to follow the process I
set up for jira inclusion though, to make sure I'm not being biased
about this, so I would request two other +1s to champion this bug's
inclusion into the release.

Also, another thought here is whether it makes sense for us to try to
have a VOTE with a 72 hour deadline when the mailing list still seems
iffy and delaying mails by multiple hours. Any thoughts on how we
should proceed? (In case this mail goes out much later than I send it
out, I'm sending it out at 11:45AM PDT, Thu May 15 2014)



On Thu, May 15, 2014 at 10:06 AM, Sushanth Sowmyan  wrote:
> Eugene, do you know if these two failures happen on 0.13.0 as well?
>
> I would assume that TestHive_7 is an issue on 0.13.0 as well, given
> that the fix for it went into trunk. What is your sense for how
> important it is that we fix this? i.e., per my understanding, (a) It
> does not cause a crash or adversly affect the ability for webhcat to
> continue operating, and (b) It means that the feature does not work
> (at all, but in isolation), and that there is no work around for it.
> This means I treat it as critical(valid bug without workaround) but
> not severe(breaks product, affects other features from being used).
> Thus, I'm willing to include HIVE-6521 in an RC2 if we have 2 more
> committers +1 an inclusion request for this.
>
> As for TestHeartbeat_1, that's an interesting failure. Do you have
> logs on what commandline options
> org.apache.hive.hcatalog.templeton.LauncherDelegator sent along that
> caused it to break? Would that affect other job launches?
>
>
> On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman
>  wrote:
>> TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
>> which is in trunk but not 13.1
>>
>>
>> On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman 
>> wrote:
>>
>>> I downloaded src tar, built it and ran webhcat e2e tests.
>>> I see 2 failures (which I don't see on trunk)
>>>
>>> TestHive_7 fails with
>>> "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"
>>>
>>> TestHeartbeat_1 fails to even launch the job.  This looks like the root
>>> cause
>>>
>>> ERROR | 13 May 2014 18:24:00,394 |
>>> org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
>>> java.lang.NullPointerException
>>> at
>>> org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
>>> at
>>> org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
>>> at
>>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:170)
>>> at
>>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:153)
>>> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:64)
>>> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
>>> at
>>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:107)
>>> at
>>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:103)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at javax.security.auth.Subject.doAs(Subject.java:396)
>>> at
>>> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1557)
>>> at
>>> org.apache.hive.hcatalog.templeton.LauncherDelegator.queueAsUser(LauncherDelegator.java:103)
>>> at
>>> org.apache.hive.hcatalog.templeton.LauncherDelegator.enqueueController(LauncherDelegator.java:81)
>>> at
>>> org.apache.hive.hcatalog.templeton.JarDelegator.run(JarDelegator.java:55)
>>> at
>>> org.apache.hive.hcatalog.templeton.Server.mapReduceJar(Server.java:711)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> su

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Eugene Koifman]

After upgrading Hadoop version, TestHive_7 is the only issue as explained
below.
RC looks good.


On Tue, May 13, 2014 at 8:14 PM, Eugene Koifman wrote:

> TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
> which is in trunk but not 13.1
>
>
> On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman 
> wrote:
>
>> I downloaded src tar, built it and ran webhcat e2e tests.
>> I see 2 failures (which I don't see on trunk)
>>
>> TestHive_7 fails with
>> "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"
>>
>> TestHeartbeat_1 fails to even launch the job.  This looks like the root
>> cause
>>
>> ERROR | 13 May 2014 18:24:00,394 |
>> org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
>> java.lang.NullPointerException
>> at
>> org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
>> at
>> org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
>> at
>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:170)
>> at
>> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:153)
>> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:64)
>> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:107)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:103)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at javax.security.auth.Subject.doAs(Subject.java:396)
>> at
>> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1557)
>> at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator.queueAsUser(LauncherDelegator.java:103)
>>  at
>> org.apache.hive.hcatalog.templeton.LauncherDelegator.enqueueController(LauncherDelegator.java:81)
>> at
>> org.apache.hive.hcatalog.templeton.JarDelegator.run(JarDelegator.java:55)
>> at
>> org.apache.hive.hcatalog.templeton.Server.mapReduceJar(Server.java:711)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>> at
>> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>> at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>> at
>> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>> at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>> at
>> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1480)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1411)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1360)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1350)
>> at
>> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>> at
>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>> at
>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at
>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:565)
>> at
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1360)
>> at
>> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:392)
>> at
>> org.apache.hadoop.hdfs.web.AuthFilter.doFilter(AuthFilter.java:87)
>> at
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1331)
>> at
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:477)
>> at
>> org.eclipse.jetty.server.h

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Eugene Koifman]

TestHive_7 is explained by https://issues.apache.org/jira/browse/HIVE-6521,
which is in trunk but not 13.1


On Tue, May 13, 2014 at 6:50 PM, Eugene Koifman wrote:

> I downloaded src tar, built it and ran webhcat e2e tests.
> I see 2 failures (which I don't see on trunk)
>
> TestHive_7 fails with
> "got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"
>
> TestHeartbeat_1 fails to even launch the job.  This looks like the root
> cause
>
> ERROR | 13 May 2014 18:24:00,394 |
> org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
> java.lang.NullPointerException
> at
> org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
> at
> org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
> at
> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:170)
> at
> org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:153)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:64)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
> at
> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:107)
> at
> org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:103)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:396)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1557)
> at
> org.apache.hive.hcatalog.templeton.LauncherDelegator.queueAsUser(LauncherDelegator.java:103)
> at
> org.apache.hive.hcatalog.templeton.LauncherDelegator.enqueueController(LauncherDelegator.java:81)
> at
> org.apache.hive.hcatalog.templeton.JarDelegator.run(JarDelegator.java:55)
> at
> org.apache.hive.hcatalog.templeton.Server.mapReduceJar(Server.java:711)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1480)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1411)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1360)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1350)
> at
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:565)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1360)
> at
> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:392)
> at
> org.apache.hadoop.hdfs.web.AuthFilter.doFilter(AuthFilter.java:87)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1331)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:477)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1031)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:965)
> at
>

Re: [VOTE] Apache Hive 0.13.1 Release Candidate 1

[Eugene Koifman]

I downloaded src tar, built it and ran webhcat e2e tests.
I see 2 failures (which I don't see on trunk)

TestHive_7 fails with
"got percentComplete map 100% reduce 0%,  expected  map 100% reduce 100%"

TestHeartbeat_1 fails to even launch the job.  This looks like the root
cause

ERROR | 13 May 2014 18:24:00,394 |
org.apache.hive.hcatalog.templeton.CatchallExceptionMapper |
java.lang.NullPointerException
at
org.apache.hadoop.util.GenericOptionsParser.processGeneralOptions(GenericOptionsParser.java:312)
at
org.apache.hadoop.util.GenericOptionsParser.parseGeneralOptions(GenericOptionsParser.java:479)
at
org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:170)
at
org.apache.hadoop.util.GenericOptionsParser.(GenericOptionsParser.java:153)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:64)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
at
org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:107)
at
org.apache.hive.hcatalog.templeton.LauncherDelegator$1.run(LauncherDelegator.java:103)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1557)
at
org.apache.hive.hcatalog.templeton.LauncherDelegator.queueAsUser(LauncherDelegator.java:103)
at
org.apache.hive.hcatalog.templeton.LauncherDelegator.enqueueController(LauncherDelegator.java:81)
at
org.apache.hive.hcatalog.templeton.JarDelegator.run(JarDelegator.java:55)
at
org.apache.hive.hcatalog.templeton.Server.mapReduceJar(Server.java:711)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1480)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1411)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1360)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1350)
at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:565)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1360)
at
org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:392)
at
org.apache.hadoop.hdfs.web.AuthFilter.doFilter(AuthFilter.java:87)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1331)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:477)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1031)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:965)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:47)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at
org.eclipse.jetty.se

[VOTE] Apache Hive 0.13.1 Release Candidate 1

[Sushanth Sowmyan]

Apache Hive 0.13.1 Release Candidate 1 is available here:

http://people.apache.org/~khorgath/releases/0.13.1_RC1/artifacts/

Maven artifacts are available here:

https://repository.apache.org/content/repositories/orgapachehive-1013/

Source tag for RC1 is at : 
https://svn.apache.org/viewvc/hive/tags/release-0.13.1-rc1/

Voting will conclude in 72 hours.

Hive PMC Members: Please test and vote.

Thanks.
-Sushanth