hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Meng Mao <meng...@gmail.com>
Subject Re: duplicate tasks getting started/killed
Date Thu, 11 Feb 2010 06:37:52 GMT
Right, so have you ever seen your non-idempotent DEFINE command have an
incorrect result? That would essentially point to duplicate attempts
behaving badly.

To your second question -- I think spec exec assumes that not all machines
run at the same speed. If a machine is free (not used for some other
attempt), then Hadoop might schedule an attempt right away on it. It's
possible, depending on the granularity of the work or issues with the
original attempt, that this later attempt finishes first, and thus becomes
the committing attempt.


On Wed, Feb 10, 2010 at 12:10 PM, prasenjit mukherjee <
pmukherjee@quattrowireless.com> wrote:

> Correctness of the results actually  depends on my DEFINE command. If
> the commands are  idempotent ( which is not in my case ) then I
> believe it wont have any affect on the results, otherwise it will
> indeed make the results incorrect. For example if my command fetches
> some data and appends to a mysql db in that case it is undesirable.
>
> I have a question though, why in the first place the second attempt
> was kicked off just seconds after the first one. I mean what is the
> rationale behind kicking off a second attempt immediately afterwards ?
> Baffling...
>
> -Prasen
>
> On Wed, Feb 10, 2010 at 10:32 PM, Meng Mao <mengmao@gmail.com> wrote:
> > That cleanup action looks promising in terms of preventing duplication.
> What
> > I'd meant was, could you ever find an instance where the results of your
> > DEFINE statement were made incorrect by multiple attempts?
> >
> > On Wed, Feb 10, 2010 at 5:05 AM, prasenjit mukherjee <
> > pmukherjee@quattrowireless.com> wrote:
> >
> >> Below is the log :
> >>
> >> attempt_201002090552_0009_m_000001_0
> >>    /default-rack/ip-10-242-142-193.ec2.internal
> >>    SUCCEEDED
> >>    100.00%
> >>    9-Feb-2010 07:04:37
> >>    9-Feb-2010 07:07:00 (2mins, 23sec)
> >>
> >>  attempt_201002090552_0009_m_000001_1
> >>    Task attempt: /default-rack/ip-10-212-147-129.ec2.internal
> >>    Cleanup Attempt: /default-rack/ip-10-212-147-129.ec2.internal
> >>    KILLED
> >>    100.00%
> >>    9-Feb-2010 07:05:34
> >>    9-Feb-2010 07:07:10 (1mins,
> >>
> >> So, here is the time-line for both the  attempts :
> >> attempt_1's start_time=07:04:37 ,         end_time=07:07:00
> >> attempt_2's          start_time=07:05:34,
> end_time=07:07:10
> >>
> >> -Thanks,
> >> Prasen
> >>
> >> On Wed, Feb 10, 2010 at 1:15 PM, Meng Mao <mengmao@gmail.com> wrote:
> >> > Can you confirm that duplication is happening in the case that one
> >> attempt
> >> > gets underway but killed before the other's completion?
> >> > I believe by default (though I'm not sure for Pig), each attempt's
> output
> >> is
> >> > first isolated to a path keyed to its attempt id, and only committed
> when
> >> > one and only one attempt is complete.
> >> >
> >> > On Tue, Feb 9, 2010 at 9:52 PM, prasenjit mukherjee <
> >> > pmukherjee@quattrowireless.com> wrote:
> >> >
> >> >> Any thoughts on this problem ? I am using a DEFINE command ( in PIG
)
> >> >> and hence the actions are not idempotent. Because of which duplicate
> >> >> execution does have an affect on my results. Any way to overcome that
> >> >> ?
> >>
> >
>

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