Hi !
I am interested in working of Jobtracker, Taskracker and Namenode stuff.
My interest is in Scheduler working.
As harsh mentioned for mapreduce , i have run a wordcount program and saw
the flow of control from job submission, execution and completion.
How do i go about it ?
Thanks,
Arun
--
alfredo config should be in a file not readable by users
Key: HADOOP-7621
URL: https://issues.apache.org/jira/browse/HADOOP-7621
Project: Hadoop Common
Issue Type: Bug
Compon
[
https://issues.apache.org/jira/browse/HADOOP-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron T. Myers reopened HADOOP-5983:
I can confirm that this issue still exists on branch-0.20-security. Reopening
it so it can be
I updated HowToContribute, it people like this prose I'll advertise
the change to *-dev.
Thanks,
Eli
On Fri, Sep 9, 2011 at 2:53 PM, Eli Collins wrote:
> On Fri, Sep 9, 2011 at 1:15 PM, Aaron T. Myers wrote:
>> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins wrote:
>>
>>> Patches for a specific b
On Fri, Sep 9, 2011 at 1:15 PM, Aaron T. Myers wrote:
> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins wrote:
>
>> Patches for a specific branch should be named: jira-xyz-branch.patch
>> where "branch" may be abbreviated, eg hdfs-123-security.patch
>>
>
> +1, if we ever hope to implement HADOOP-74
Review board already works. Hbase uses it extensively.
On Fri, Sep 9, 2011 at 2:15 PM, Kirby Bohling wrote:
> On Fri, Sep 9, 2011 at 4:04 PM, Doug Cutting wrote:
> > On 09/09/2011 01:38 PM, Kirby Bohling wrote:
> >> Someday I wish Apache would find/adopt a distributed version control
> >> syste
On 09/09/2011 02:15 PM, Kirby Bohling wrote:
> Fair enough Doug. Somebody else will have to do that, I don't have
> commit access (a pre-requisite for access to the private lists). I'd
> make the suggestion there, but I literally can't.
Such suggestions have been made before. What's lacking are
On Fri, Sep 9, 2011 at 4:04 PM, Doug Cutting wrote:
> On 09/09/2011 01:38 PM, Kirby Bohling wrote:
>> Someday I wish Apache would find/adopt a distributed version control
>> system (I know about git.apache.org, but I mean pushing that further),
>> and use something like gerrit or review board. So
On 09/09/2011 01:38 PM, Kirby Bohling wrote:
> Someday I wish Apache would find/adopt a distributed version control
> system (I know about git.apache.org, but I mean pushing that further),
> and use something like gerrit or review board. So if you have a
> patch, or a series of patches, you'd just
On Fri, Sep 9, 2011 at 3:15 PM, Aaron T. Myers wrote:
> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins wrote:
>
>> Patches for a specific branch should be named: jira-xyz-branch.patch
>> where "branch" may be abbreviated, eg hdfs-123-security.patch
>>
>
> +1, if we ever hope to implement HADOOP-74
On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins wrote:
> Patches for a specific branch should be named: jira-xyz-branch.patch
> where "branch" may be abbreviated, eg hdfs-123-security.patch
>
+1, if we ever hope to implement HADOOP-7435 [1], it will be necessary to
standardize the branch-name-in-p
On 09/09/2011 01:08 PM, Allen Wittenauer wrote:
> s,patch,txt, since jira doesn't appear to pass a content-type to indicate it
> is readable by the browser (as you mentioned earlier).
I think Jira uses the content-type that the browser posts with. My
browser (Chrome on Ubuntu) posts .patch files
On Sep 9, 2011, at 12:57 PM, Eli Collins wrote:
>
> Patches for trunk should be named: jira-xyz.patch
> eg hdfs-123.patch
s,patch,txt, since jira doesn't appear to pass a content-type to indicate it is
readable by the browser (as you mentioned earlier).
On Fri, Sep 9, 2011 at 12:52 PM, Doug Cutting wrote:
> On 09/09/2011 11:12 AM, Eli Collins wrote:
>> Personally I like version numbers as well, it allows me to refer to a
>> specific version of the patch (vs a patch on a given time of
>> date/date).
>
> Re-using the name doesn't hide the old vers
On 09/09/2011 11:12 AM, Eli Collins wrote:
> Personally I like version numbers as well, it allows me to refer to a
> specific version of the patch (vs a patch on a given time of
> date/date).
Re-using the name doesn't hide the old versions, it just makes them
gray. They're still listed, with dat
Both Hadoop and virtualization are means to an end. That end is to consolidate
workloads traditionally deployed to separate servers so the average utilization
and ROI of a given server increases.
Companies looking to consolidate data-intensive computation may be better
served moving to Hadoop i
Agreed. Furthermore, if I have 10+ versions of a patch, when getting
feedback knowing for with version would be handy, having a single name makes
this correlation difficult.
Thxs.
Alejandro
[PS: I know, I should code better not have to go thru several versions]
On Fri, Sep 9, 2011 at 11:08 AM,
On Fri, Sep 9, 2011 at 11:38 PM, Ravi Prakash wrote:
> But what if I want to see an incremental diff between two patches? I don't
> want to review the whole patch everytime. Maybe I just want to re-review the
> changes made to a patch. I would then have sort the patches manually using
> time. I th
Thanks all for your feedback on this, I'll research some more and gather some
benchmarks, also what about the provisioning of long running services via HOD,
is anyone looking at this project or has done work on this?
Regards
> From: mse...@navteq.com
> To: common-dev@hadoop.apache.org; mapreduc
Personally I like version numbers as well, it allows me to refer to a
specific version of the patch (vs a patch on a given time of
date/date).
I also notice some people use .txt which browsers can view in place vs
.patch which will download by default unless you register a viewer.
Thanks,
Eli
O
How about we the how to contribute page with a simple standard?
jira-xyz.patch # for trunk
jira-xyz-branch.patch # for a release branch, could use a shortened
name, eg "20x" for branch-20-security and "append" for
branch-20-append.
Thanks,
Eli
On Fri, Sep 9, 2011 at 10:32 AM, Robert Evans wro
But what if I want to see an incremental diff between two patches? I don't
want to review the whole patch everytime. Maybe I just want to re-review the
changes made to a patch. I would then have sort the patches manually using
time. I think its better to have version numbers in that case
On Fri,
All profiles should build the javadoc
-
Key: HADOOP-7620
URL: https://issues.apache.org/jira/browse/HADOOP-7620
Project: Hadoop Common
Issue Type: Improvement
Reporter: Owen O'Malley
Currentl
Why would you want to take a perfectly good machine and then try to virtualize
it?
I mean if I have 4 quad core cpus, I can run a lot of simultaneous map tasks.
However if I virtualize the box, I lose at least 1 core per VM so I end up with
4 nodes that have less capabilities and performance tha
Can I ask, though that we do add branch information in the patches. Too often
a patch is intended to apply to some branch other then trunk, and there is no
easy way to tell what branch it was intended for.
--Bobby Evans
On 9/9/11 10:52 AM, "Mattmann, Chris A (388J)"
wrote:
Wow, I didn't kn
[
https://issues.apache.org/jira/browse/HADOOP-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen O'Malley resolved HADOOP-6553.
---
Resolution: Duplicate
HADOOP-6620 fixed this.
> Delegation tokens get NPE when the renewer
Hi Folks,I was looking through the following wiki page:
http://wiki.apache.org/hadoop/HadoopResearchProjects and was wondering if
there's been any work done (or any interest to do work) for the following
topics:
Integration of Virtualization (such as Xen) with Hadoop toolsHow does one
integr
Wow, I didn't know that!
Learn something new everyday, thanks guys.
Cheers,
Chris
On Sep 9, 2011, at 9:48 AM, Doug Cutting wrote:
> On 09/09/2011 07:27 AM, Ted Dunning wrote:
>> If you post the same patch with the same name, JIRA helps you out by greying
>> all the earlier versions out.
>
> In
On 09/09/2011 07:27 AM, Ted Dunning wrote:
> If you post the same patch with the same name, JIRA helps you out by greying
> all the earlier versions out.
Indeed. That's the best practice, not to add version numbers to patch
files, for this very reason. We should perhaps note this on:
http://wik
Incorrect setting JAVA_HOME variable under Cygwin on windows
Key: HADOOP-7619
URL: https://issues.apache.org/jira/browse/HADOOP-7619
Project: Hadoop Common
Issue Type: Bug
Affe
If you post the same patch with the same name, JIRA helps you out by greying
all the earlier versions out.
On Fri, Sep 9, 2011 at 7:03 AM, John George wrote:
> +1. Changing default to 'sorted by date' helps.
>
> John Vijoe George Edackattukudy
>
> On Sep 9, 2011, at 9:01 AM, "Uma Maheswara Rao G
+1. Changing default to 'sorted by date' helps.
John Vijoe George Edackattukudy
On Sep 9, 2011, at 9:01 AM, "Uma Maheswara Rao G 72686"
wrote:
>
> +1, that is nice point.
>
> Thanks,
> Uma
> - Original Message -
> From: Vinod Kumar Vavilapalli
> Date: Friday, September 9, 2011 3:09
+1, that is nice point.
Thanks,
Uma
- Original Message -
From: Vinod Kumar Vavilapalli
Date: Friday, September 9, 2011 3:09 pm
Subject: JIRA attachments order
To: common-dev@hadoop.apache.org
> Can someone with JIRA admin privileges see if the default sorting
> order for
> attachments
+1. In addition, I've found easier for identifying the right patch to use a
version suffix, like HADOOP-1234v2.patch. Maybe we should recommend
something like that as a naming convention in the HowToContribute
On Fri, Sep 9, 2011 at 2:38 AM, Vinod Kumar Vavilapalli <
vino...@hortonworks.com> wrote
Sometimes when running hadoop jobs using the 'hadoop jar' command there
are issues with the classloader. I presume these are caused by classes
that are loaded BEFORE the commands main is invoced. For example, when
relying on the MapWritable in the command, it is not possible to use a
class that
Can someone with JIRA admin privileges see if the default sorting order for
attachments be changed to be by date instead of by name?
Ordering by date helps in picking up the latest patches easily.
Thanks,
+Vinod
start-dfs.sh and stop-dfs.sh are not working properly
-
Key: HADOOP-7618
URL: https://issues.apache.org/jira/browse/HADOOP-7618
Project: Hadoop Common
Issue Type: Bug
Components:
37 matches
Mail list logo
