FAQ
Hi Dan,

I looked into this a bit. I think it's a bug. As a workaround, you can edit
the client configuration in CM -> Services -> MapReduce -> Configuration ->
Gateway -> "MapReduce Client Configuration Safety Valve for mapred-site.xml".
You need to paste in:

<property>
<name>mapred.userlog.retain.hours</name>
<value>96</value>
</property>

Go to top level -> Cluster -> Action -> Deploy Client Configuration. This
puts the config on the client side, and seems to work in my testing. Any
new job's conf xml should also show 96.

Cheers,
bc

On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
wrote:
I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
(although this also happened on CDH4.0.1 and Cloudera Manager 4.0.4)

In Cloudera Manager I have the mapred.userlog.retain.hours set to 96,
but my logs are retained for less time than that. Looking at job
configurations it shows that the mapred.userlog.retain.hours is set to
the default of 24..

Any ideas? I am not setting this property in any client code/files
that are being sent as a part of the job.

Is there a tasktracker-specific property that needs to be set?
Thanks
Dan


--
Dan Richelson, Software Engineer

Tendril
2560 55th St. | Boulder, Colorado 80301
M 303-709-2214
www.tendrilinc.com

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender.
Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the company.
Finally, the recipient should check this email and any attachments for the
presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.

Search Discussions

  • Dan Richelson at Jan 17, 2013 at 10:47 pm
    Hi BC, thanks for looking in to this. I don't have a 'Gateway' item in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce config,
    restarted the cluster, and deployed the client configs. I then started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png
    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround, you can edit
    the client configuration in CM -> Services -> MapReduce -> Configuration ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client Configuration. This
    puts the config on the client side, and seems to work in my testing. Any new
    job's conf xml should also show 96.

    Cheers,
    bc
    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson wrote:

    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager 4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours set to 96,
    but my logs are retained for less time than that. Looking at job
    configurations it shows that the mapred.userlog.retain.hours is set to
    the default of 24..

    Any ideas? I am not setting this property in any client code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the presence of viruses.
    The company accepts no liability for any damage caused by any virus transmitted by this email.
  • Dan Richelson at Jan 18, 2013 at 4:20 pm
    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72) is
    there.
    Any other ideas?
    thanks
    Dan
    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson wrote:

    Hi BC, thanks for looking in to this. I don't have a 'Gateway' item in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce config,
    restarted the cluster, and deployed the client configs. I then started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the client
    configuration, CM will put it on all the hosts that participate in the
    MapReduce service. Is your local machine (where you submit the job) part of
    the MR cluster? If not, you could download the MR client config and manually
    untar it locally.

    So, in summary, check whether your /etc/hadoop/conf/mapred-site.xml has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround, you can
    edit
    the client configuration in CM -> Services -> MapReduce -> Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client Configuration.
    This
    puts the config on the client side, and seems to work in my testing. Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager 4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours set to 96,
    but my logs are retained for less time than that. Looking at job
    configurations it shows that the mapred.userlog.retain.hours is set to
    the default of 24..

    Any ideas? I am not setting this property in any client code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the presence of viruses.
    The company accepts no liability for any damage caused by any virus transmitted by this email.
  • bc Wong at Jan 18, 2013 at 5:27 pm
    Do the submitted jobs show 72 in their job conf? If so, then they should
    take effect. Do the new jobs get their logs deleted before 72 hours?

    Cheers,
    bc
    On Fri, Jan 18, 2013 at 8:19 AM, Dan Richelson wrote:

    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72) is
    there.
    Any other ideas?
    thanks
    Dan
    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson <
    drichelson@tendrilinc.com>
    wrote:
    Hi BC, thanks for looking in to this. I don't have a 'Gateway' item in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce config,
    restarted the cluster, and deployed the client configs. I then started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the client
    configuration, CM will put it on all the hosts that participate in the
    MapReduce service. Is your local machine (where you submit the job) part of
    the MR cluster? If not, you could download the MR client config and manually
    untar it locally.

    So, in summary, check whether your /etc/hadoop/conf/mapred-site.xml has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround, you can
    edit
    the client configuration in CM -> Services -> MapReduce ->
    Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client Configuration.
    This
    puts the config on the client side, and seems to work in my testing.
    Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager 4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours set to 96,
    but my logs are retained for less time than that. Looking at job
    configurations it shows that the mapred.userlog.retain.hours is set
    to
    the default of 24..

    Any ideas? I am not setting this property in any client code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.
  • Dan Richelson at Jan 18, 2013 at 5:46 pm
    bc,
    The behavior has not changed. Logs are not retained for more than 24
    hours, and the job conf shows 24. When I programmatically set the
    mapred.userlog.retain.hours property in a job submission (Java
    mapreduce started using hadoop client classes), the job configuration
    changes, but the default is still set to 24. We use Oozie for
    triggering most jobs, but also have test fixtures that start Pig,
    Hive, Sqoop, and MapReduce jobs via Java clients.
    thanks
    Dan
    On Fri, Jan 18, 2013 at 10:27 AM, bc Wong wrote:
    Do the submitted jobs show 72 in their job conf? If so, then they should
    take effect. Do the new jobs get their logs deleted before 72 hours?

    Cheers,
    bc

    On Fri, Jan 18, 2013 at 8:19 AM, Dan Richelson wrote:

    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72) is
    there.
    Any other ideas?
    thanks
    Dan
    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi BC, thanks for looking in to this. I don't have a 'Gateway' item in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce config,
    restarted the cluster, and deployed the client configs. I then started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the client
    configuration, CM will put it on all the hosts that participate in the
    MapReduce service. Is your local machine (where you submit the job) part
    of
    the MR cluster? If not, you could download the MR client config and
    manually
    untar it locally.

    So, in summary, check whether your /etc/hadoop/conf/mapred-site.xml has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround, you
    can
    edit
    the client configuration in CM -> Services -> MapReduce ->
    Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client Configuration.
    This
    puts the config on the client side, and seems to work in my testing.
    Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager 4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours set to
    96,
    but my logs are retained for less time than that. Looking at job
    configurations it shows that the mapred.userlog.retain.hours is set
    to
    the default of 24..

    Any ideas? I am not setting this property in any client code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the presence of viruses.
    The company accepts no liability for any damage caused by any virus transmitted by this email.
  • bc Wong at Jan 18, 2013 at 7:58 pm
    Oozie imposes its own defaults. I don't have a workaround for jobs that are
    submitted via Oozie. Can you check whether the other clients (command line,
    Hive, etc) work?

    Cheers,
    bc
    On Fri, Jan 18, 2013 at 9:45 AM, Dan Richelson wrote:

    bc,
    The behavior has not changed. Logs are not retained for more than 24
    hours, and the job conf shows 24. When I programmatically set the
    mapred.userlog.retain.hours property in a job submission (Java
    mapreduce started using hadoop client classes), the job configuration
    changes, but the default is still set to 24. We use Oozie for
    triggering most jobs, but also have test fixtures that start Pig,
    Hive, Sqoop, and MapReduce jobs via Java clients.
    thanks
    Dan
    On Fri, Jan 18, 2013 at 10:27 AM, bc Wong wrote:
    Do the submitted jobs show 72 in their job conf? If so, then they should
    take effect. Do the new jobs get their logs deleted before 72 hours?

    Cheers,
    bc


    On Fri, Jan 18, 2013 at 8:19 AM, Dan Richelson <
    drichelson@tendrilinc.com>
    wrote:
    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72) is
    there.
    Any other ideas?
    thanks
    Dan
    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi BC, thanks for looking in to this. I don't have a 'Gateway' item
    in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce config,
    restarted the cluster, and deployed the client configs. I then
    started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the
    client
    configuration, CM will put it on all the hosts that participate in the
    MapReduce service. Is your local machine (where you submit the job)
    part
    of
    the MR cluster? If not, you could download the MR client config and
    manually
    untar it locally.

    So, in summary, check whether your /etc/hadoop/conf/mapred-site.xml
    has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround, you
    can
    edit
    the client configuration in CM -> Services -> MapReduce ->
    Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client
    Configuration.
    This
    puts the config on the client side, and seems to work in my
    testing.
    Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager
    4.0.4)
    In Cloudera Manager I have the mapred.userlog.retain.hours set to
    96,
    but my logs are retained for less time than that. Looking at job
    configurations it shows that the mapred.userlog.retain.hours is
    set
    to
    the default of 24..

    Any ideas? I am not setting this property in any client code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.
  • Harsh J at Jan 19, 2013 at 6:43 am
    For regular java based submits: If the /etc/hadoop/conf (or any other conf
    dir) is on the classpath of the application, its properties are auto-read
    and used.

    For Oozie based submits: Required job config should be part of the
    <configuration> fields in the WF/etc.

    On Sat, Jan 19, 2013 at 1:55 AM, Dan Richelson wrote:

    We only submit jobs via the mentioned methods,so I'd have to do some
    digging on how to get a job started from the command line.. Should I
    expect a map reduce job submitted using the Java client:
    JobClient.runJob(jobConf); to behave using the cloudera manager
    settings? (it does not)
    thanks
    Dan
    On Fri, Jan 18, 2013 at 12:58 PM, bc Wong wrote:
    Oozie imposes its own defaults. I don't have a workaround for jobs that are
    submitted via Oozie. Can you check whether the other clients (command line,
    Hive, etc) work?

    Cheers,
    bc


    On Fri, Jan 18, 2013 at 9:45 AM, Dan Richelson <
    drichelson@tendrilinc.com>
    wrote:
    bc,
    The behavior has not changed. Logs are not retained for more than 24
    hours, and the job conf shows 24. When I programmatically set the
    mapred.userlog.retain.hours property in a job submission (Java
    mapreduce started using hadoop client classes), the job configuration
    changes, but the default is still set to 24. We use Oozie for
    triggering most jobs, but also have test fixtures that start Pig,
    Hive, Sqoop, and MapReduce jobs via Java clients.
    thanks
    Dan
    On Fri, Jan 18, 2013 at 10:27 AM, bc Wong wrote:
    Do the submitted jobs show 72 in their job conf? If so, then they
    should
    take effect. Do the new jobs get their logs deleted before 72 hours?

    Cheers,
    bc


    On Fri, Jan 18, 2013 at 8:19 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72) is
    there.
    Any other ideas?
    thanks
    Dan
    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi BC, thanks for looking in to this. I don't have a 'Gateway'
    item
    in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce
    config,
    restarted the cluster, and deployed the client configs. I then
    started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the
    client
    configuration, CM will put it on all the hosts that participate in
    the
    MapReduce service. Is your local machine (where you submit the job)
    part
    of
    the MR cluster? If not, you could download the MR client config and
    manually
    untar it locally.

    So, in summary, check whether your /etc/hadoop/conf/mapred-site.xml
    has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong <bcwalrus@cloudera.com>
    wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround,
    you
    can
    edit
    the client configuration in CM -> Services -> MapReduce ->
    Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client
    Configuration.
    This
    puts the config on the client side, and seems to work in my
    testing.
    Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager
    4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours set
    to
    96,
    but my logs are retained for less time than that. Looking at
    job
    configurations it shows that the mapred.userlog.retain.hours is
    set
    to
    the default of 24..

    Any ideas? I am not setting this property in any client
    code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential
    and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the
    sender.
    Please note that any views or opinions presented in this email
    are
    solely
    those of the author and do not necessarily represent those of
    the
    company.
    Finally, the recipient should check this email and any
    attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.

    --



    --
    Harsh J
  • Dan Richelson at Jan 30, 2013 at 12:04 am
    Thanks for all your help. Here is what I ended up doing and it seems
    to work as a default for all jobs regardless of how they were started
    (Java client, or oozie)
    Using Cloudera Manager 4.1.2 and CDH4.1.2 (MRV1)
    In Cloudera Manager:
    Services->mapreduce->Configuration
    Service-Wide
    Advanced: add this to the MapReduce Service Configuration Safety
    Valve for mapred-site.xml
    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>72</value>
    </property>
    I also added the same xml snippet into the 'Advanced' section for
    Jobtracker, TaskTracker, and Client.

    Next, restart the mapreduce service.
    Then go back into the mapreduce service configuration and in the top
    right click 'Actions' then 'Deploy Client Configuration'

    You may not need the property set in all those places, but this is
    what worked for me.
    Dan
    On Fri, Jan 18, 2013 at 11:42 PM, Harsh J wrote:
    For regular java based submits: If the /etc/hadoop/conf (or any other conf
    dir) is on the classpath of the application, its properties are auto-read
    and used.

    For Oozie based submits: Required job config should be part of the
    <configuration> fields in the WF/etc.

    On Sat, Jan 19, 2013 at 1:55 AM, Dan Richelson wrote:

    We only submit jobs via the mentioned methods,so I'd have to do some
    digging on how to get a job started from the command line.. Should I
    expect a map reduce job submitted using the Java client:
    JobClient.runJob(jobConf); to behave using the cloudera manager
    settings? (it does not)
    thanks
    Dan
    On Fri, Jan 18, 2013 at 12:58 PM, bc Wong wrote:
    Oozie imposes its own defaults. I don't have a workaround for jobs that
    are
    submitted via Oozie. Can you check whether the other clients (command
    line,
    Hive, etc) work?

    Cheers,
    bc


    On Fri, Jan 18, 2013 at 9:45 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    bc,
    The behavior has not changed. Logs are not retained for more than 24
    hours, and the job conf shows 24. When I programmatically set the
    mapred.userlog.retain.hours property in a job submission (Java
    mapreduce started using hadoop client classes), the job configuration
    changes, but the default is still set to 24. We use Oozie for
    triggering most jobs, but also have test fixtures that start Pig,
    Hive, Sqoop, and MapReduce jobs via Java clients.
    thanks
    Dan

    On Fri, Jan 18, 2013 at 10:27 AM, bc Wong <bcwalrus@cloudera.com>
    wrote:
    Do the submitted jobs show 72 in their job conf? If so, then they
    should
    take effect. Do the new jobs get their logs deleted before 72 hours?

    Cheers,
    bc


    On Fri, Jan 18, 2013 at 8:19 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72)
    is
    there.
    Any other ideas?
    thanks
    Dan

    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong <bcwalrus@cloudera.com>
    wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi BC, thanks for looking in to this. I don't have a 'Gateway'
    item
    in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce
    config,
    restarted the cluster, and deployed the client configs. I then
    started
    a new mapreduce job from my local machine and it still shows the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the
    client
    configuration, CM will put it on all the hosts that participate in
    the
    MapReduce service. Is your local machine (where you submit the
    job)
    part
    of
    the MR cluster? If not, you could download the MR client config
    and
    manually
    untar it locally.

    So, in summary, check whether your
    /etc/hadoop/conf/mapred-site.xml
    has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong <bcwalrus@cloudera.com>
    wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a workaround,
    you
    can
    edit
    the client configuration in CM -> Services -> MapReduce ->
    Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client
    Configuration.
    This
    puts the config on the client side, and seems to work in my
    testing.
    Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS 5.
    (although this also happened on CDH4.0.1 and Cloudera Manager
    4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours set
    to
    96,
    but my logs are retained for less time than that. Looking at
    job
    configurations it shows that the mapred.userlog.retain.hours
    is
    set
    to
    the default of 24..

    Any ideas? I am not setting this property in any client
    code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential
    and
    intended
    solely for the use of the individual or entity to whom they
    are
    addressed.
    If you have received this email in error please notify the
    sender.
    Please note that any views or opinions presented in this email
    are
    solely
    those of the author and do not necessarily represent those of
    the
    company.
    Finally, the recipient should check this email and any
    attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the
    sender.
    Please note that any views or opinions presented in this email
    are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any
    attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.

    --



    --
    Harsh J


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the presence of viruses.
    The company accepts no liability for any damage caused by any virus transmitted by this email.
  • bc Wong at Jan 30, 2013 at 8:46 pm
    Thanks for the update, Dan. Glad you manage to work around it. We're also
    fixing this in our next release.

    Cheers,
    bc
    On Tue, Jan 29, 2013 at 4:04 PM, Dan Richelson wrote:

    Thanks for all your help. Here is what I ended up doing and it seems
    to work as a default for all jobs regardless of how they were started
    (Java client, or oozie)
    Using Cloudera Manager 4.1.2 and CDH4.1.2 (MRV1)
    In Cloudera Manager:
    Services->mapreduce->Configuration
    Service-Wide
    Advanced: add this to the MapReduce Service Configuration Safety
    Valve for mapred-site.xml
    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>72</value>
    </property>
    I also added the same xml snippet into the 'Advanced' section for
    Jobtracker, TaskTracker, and Client.

    Next, restart the mapreduce service.
    Then go back into the mapreduce service configuration and in the top
    right click 'Actions' then 'Deploy Client Configuration'

    You may not need the property set in all those places, but this is
    what worked for me.
    Dan
    On Fri, Jan 18, 2013 at 11:42 PM, Harsh J wrote:
    For regular java based submits: If the /etc/hadoop/conf (or any other conf
    dir) is on the classpath of the application, its properties are auto-read
    and used.

    For Oozie based submits: Required job config should be part of the
    <configuration> fields in the WF/etc.


    On Sat, Jan 19, 2013 at 1:55 AM, Dan Richelson <
    drichelson@tendrilinc.com>
    wrote:
    We only submit jobs via the mentioned methods,so I'd have to do some
    digging on how to get a job started from the command line.. Should I
    expect a map reduce job submitted using the Java client:
    JobClient.runJob(jobConf); to behave using the cloudera manager
    settings? (it does not)
    thanks
    Dan
    On Fri, Jan 18, 2013 at 12:58 PM, bc Wong wrote:
    Oozie imposes its own defaults. I don't have a workaround for jobs
    that
    are
    submitted via Oozie. Can you check whether the other clients (command
    line,
    Hive, etc) work?

    Cheers,
    bc


    On Fri, Jan 18, 2013 at 9:45 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    bc,
    The behavior has not changed. Logs are not retained for more than 24
    hours, and the job conf shows 24. When I programmatically set the
    mapred.userlog.retain.hours property in a job submission (Java
    mapreduce started using hadoop client classes), the job configuration
    changes, but the default is still set to 24. We use Oozie for
    triggering most jobs, but also have test fixtures that start Pig,
    Hive, Sqoop, and MapReduce jobs via Java clients.
    thanks
    Dan

    On Fri, Jan 18, 2013 at 10:27 AM, bc Wong <bcwalrus@cloudera.com>
    wrote:
    Do the submitted jobs show 72 in their job conf? If so, then they
    should
    take effect. Do the new jobs get their logs deleted before 72
    hours?
    Cheers,
    bc


    On Fri, Jan 18, 2013 at 8:19 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi bc,
    I checked the /etc/hadoop/conf/mapred-site.xml on all nodes of my
    cluster and the desired value for mapred.userlog.retain.hours (72)
    is
    there.
    Any other ideas?
    thanks
    Dan

    On Thu, Jan 17, 2013 at 5:54 PM, bc Wong <bcwalrus@cloudera.com>
    wrote:
    On Thu, Jan 17, 2013 at 2:47 PM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    Hi BC, thanks for looking in to this. I don't have a 'Gateway'
    item
    in
    the mapreduce configuration.
    I did add the property element to 4 places in the MapReduce
    config,
    restarted the cluster, and deployed the client configs. I then
    started
    a new mapreduce job from my local machine and it still shows
    the
    default 24 property.
    Here is the screenshot of my mapreduce configuration page:
    http://i.imgur.com/8gzSk.png

    It's the client safety valve that matters. When you redeploy the
    client
    configuration, CM will put it on all the hosts that participate
    in
    the
    MapReduce service. Is your local machine (where you submit the
    job)
    part
    of
    the MR cluster? If not, you could download the MR client config
    and
    manually
    untar it locally.

    So, in summary, check whether your
    /etc/hadoop/conf/mapred-site.xml
    has
    retain hours set correctly.

    Cheers,
    bc

    On Thu, Jan 17, 2013 at 1:58 PM, bc Wong <
    bcwalrus@cloudera.com>
    wrote:
    Hi Dan,

    I looked into this a bit. I think it's a bug. As a
    workaround,
    you
    can
    edit
    the client configuration in CM -> Services -> MapReduce ->
    Configuration
    ->
    Gateway -> "MapReduce Client Configuration Safety Valve for
    mapred-site.xml". You need to paste in:

    <property>
    <name>mapred.userlog.retain.hours</name>
    <value>96</value>
    </property>

    Go to top level -> Cluster -> Action -> Deploy Client
    Configuration.
    This
    puts the config on the client side, and seems to work in my
    testing.
    Any
    new
    job's conf xml should also show 96.

    Cheers,
    bc

    On Mon, Jan 14, 2013 at 11:13 AM, Dan Richelson
    <drichelson@tendrilinc.com>
    wrote:
    I am running CDH4.1.2 and Cloudera Manager 4.1.2 on CentOS
    5.
    (although this also happened on CDH4.0.1 and Cloudera
    Manager
    4.0.4)

    In Cloudera Manager I have the mapred.userlog.retain.hours
    set
    to
    96,
    but my logs are retained for less time than that. Looking at
    job
    configurations it shows that the mapred.userlog.retain.hours
    is
    set
    to
    the default of 24..

    Any ideas? I am not setting this property in any client
    code/files
    that are being sent as a part of the job.

    Is there a tasktracker-specific property that needs to be
    set?
    Thanks
    Dan


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are
    confidential
    and
    intended
    solely for the use of the individual or entity to whom they
    are
    addressed.
    If you have received this email in error please notify the
    sender.
    Please note that any views or opinions presented in this
    email
    are
    solely
    those of the author and do not necessarily represent those
    of
    the
    company.
    Finally, the recipient should check this email and any
    attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by
    any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential
    and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the
    sender.
    Please note that any views or opinions presented in this email
    are
    solely
    those of the author and do not necessarily represent those of
    the
    company.
    Finally, the recipient should check this email and any
    attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any
    virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments
    for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and
    intended
    solely for the use of the individual or entity to whom they are
    addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are
    solely
    those of the author and do not necessarily represent those of the
    company.
    Finally, the recipient should check this email and any attachments for
    the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.

    --



    --
    Harsh J


    --
    Dan Richelson, Software Engineer

    Tendril
    2560 55th St. | Boulder, Colorado 80301
    M 303-709-2214
    www.tendrilinc.com

    This email and any files transmitted with it are confidential and intended
    solely for the use of the individual or entity to whom they are addressed.
    If you have received this email in error please notify the sender.
    Please note that any views or opinions presented in this email are solely
    those of the author and do not necessarily represent those of the company.
    Finally, the recipient should check this email and any attachments for the
    presence of viruses.
    The company accepts no liability for any damage caused by any virus
    transmitted by this email.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupscm-users @
categorieshadoop
postedJan 17, '13 at 8:58p
activeJan 30, '13 at 8:46p
posts9
users3
websitecloudera.com
irc#hadoop

3 users in discussion

Dan Richelson: 4 posts bc Wong: 4 posts Harsh J: 1 post

People

Translate

site design / logo © 2022 Grokbase