[ https://issues.apache.org/jira/browse/HADOOP-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725017#action_12725017
]
Chris Douglas commented on HADOOP-6109:
---------------------------------------
{noformat}
[exec] -1 overall.
[exec]
[exec] +1 @author. The patch does not contain any @author tags.
[exec]
[exec] -1 tests included. The patch doesn't appear to include any new or modified
tests.
[exec] Please justify why no new tests are needed for this patch.
[exec] Also please list what manual steps were performed to verify
this patch.
[exec]
[exec] +1 javadoc. The javadoc tool did not generate any warning messages.
[exec]
[exec] -1 javac. The applied patch generated 64 javac compiler warnings (more than
the trunk's current 124 warnings).
[exec]
[exec] +1 findbugs. The patch does not introduce any new Findbugs warnings.
[exec]
[exec] +1 release audit. The applied patch does not increase the total number of
release audit warnings.
{noformat}
The javac objection is spurious. The patch adds no warnings.
> Handle large (several MB) text input lines in a reasonable amount of time
> -------------------------------------------------------------------------
>
> Key: HADOOP-6109
> URL: https://issues.apache.org/jira/browse/HADOOP-6109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: io
> Affects Versions: 0.19.0
> Environment: Linux 2.6 kernel, java 1.6 AMD Dual-Core Opteron 2.6GHz with 1M
L1/L2 cache 1.8G RAM
> Reporter: thushara wijeratna
> Assignee: thushara wijeratna
> Attachments: HADOOP-1234.patch, HADOOP-1234.patch
>
>
> problem:
> =======
> hadoop was timing out on a simple pass-through job (with the default 10 min timeout)
> cause:
> =====
> i hunted this down to how Text lines are being processed inside org.apache.hadoop.util.LineReader.
> i have a fix, a task that took more than 20 minutes and still failed to complete, completes
with this fix in under 30 s.
> i attach the patch (for trunk)
> the problem traces:
> ================
> hadoop version: 0.19.0
> userlogs on slave node:
> 2009-05-29 13:57:33,551 WARN org.apache.hadoop.mapred.TaskRunner: Parent died. Exiting
attempt_200905281652_0013_m_000006_1
> [root@domU-12-31-38-01-7C-92 attempt_200905281652_0013_m_000006_1]#
> tellingly, the last input line processed right before this WARN is 19K. (i log the full
input line in the map function for debugging)
> output on map-reduce task:
> Task attempt_200905281652_0013_m_000006_2 failed to report status for 600 seconds. Killing!
> 09/05/29 14:08:01 INFO mapred.JobClient: map 99% reduce 32%
> 09/05/29 14:18:05 INFO mapred.JobClient: map 98% reduce 32%
> java.io.IOException: Job failed!
> at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1217)
> at com.adxpose.data.mr.DailyHeatmapAggregator.run(DailyHeatmapAggregator.java:547)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at com.adxpose.data.mr.DailyHeatmapAggregator.main(DailyHeatmapAggregator.java:553)
> 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 org.apache.hadoop.util.RunJar.main(RunJar.java:165)
> at org.apache.hadoop.mapred.JobShell.run(JobShell.java:54)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
> at org.apache.hadoop.mapred.JobShell.main(JobShell.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The new git repositories for HDFS and Map/Reduce,
git://git.apache.org/hadoop-{mapreduce,hdfs}.git are up.
There are two open issues:
(1) What to do with the defunct git mirror that points to core
(2) What to call the common mirror
For (1), I'd advocate simply deleting it. There doesn't seem to be a
compelling case for maintaining an archive of a mirror next to its
active replacements.
For (2), the git mirror is currently being built as hadoop-common.git.
Since it will contain the pre-0.21 tagged releases/branches and
developers pulling from the old mirror will error out either way, I'd
lean toward calling it hadoop.git, but am mostly ambivalent on this.
The ticket for this is INFRA-2108. -C
Rebalancing is already built into hadoop. http://hadoop.apache.org/core/docs/r0.17.2/hdfs_user_guide.html#Rebalancer On Sun, Jun 28, 2009 at 9:01 AM, arun kumar <arunkumar_skcet@yahoo.com>wrote: > I am a beginner and I am interested in implementing a Cluster Re-balancing > scheme. I will keep searching regarding, meanwhile if anybody is working on > or knows anything, please let me know. >
Hello,
I am a beginner and I am interested in implementing a Cluster Re-balancing scheme. I will
keep searching regarding, meanwhile if anybody is working on or knows anything, please let
me know.
Thank you,
Arun
Hi, I would also be interested in having a 0.19.2 release, or even more releases. If you are starting to run your cluster, you don't know which version you should take. Some releases were unstable (eg taskstrackers running out of memory, or executing maps sequentially after a certain number of jobs, multifileoutputformat not working with threads, ..). If we are upgrading to a major version number, we are nearly always hitting a bug which makes our system unreliable. Also now with yahoo's release of their own version, what happens if I use that version? Will there be more releases after that one from yahoo? Can I migrate my cluster back to the official branch afterwards without losing data? Thibaut jason hadoop wrote: > > I want to feed some mapside join patches in, time to get off my duff and > submit them :) > > > On Mon, Jun 15, 2009 at 12:33 PM, Scott Carey > <scott@richrelevance.com>wrote: > >> I am still interested in seeing a 0.19.2 release soon. The 0.19.2-dev >> and >> 0.18.4-dev branches have been close to dormant for over a month, yet >> contain >> many critical fixes. >> >> >> With the Yahoo distribution out there, 0.20.1 is a slightly lower >> priority >> for me. Additionally, several other components are not yet 0.20.x >> compatible anyway. >> >> >> What does the rest of the community think? >> >> -Scott >> >> On 5/27/09 4:08 PM, "Owen O'Malley" <omalley@apache.org> wrote: >> >> If no one else does, I'll roll 0.18.4, 0.19.2, and 0.20.1 next week. >> >> -- Owen >> >> > > > -- > Pro Hadoop, a book to guide you from beginner to hadoop mastery, > http://www.amazon.com/dp/1430219424?tag=jewlerymall > www.prohadoopbook.com a community for Hadoop Professionals > > -- View this message in context: http://www.nabble.com/0.19.2-release-needed-tp23748571p24242623.html Sent from the Hadoop core-dev mailing list archive at Nabble.com.
I create bug record in https://issues.apache.org/jira/browse/HADOOP-6114 with attached patch for trunk. Dmitry. 2009/6/28 Dhruba Borthakur <dhruba@gmail.com> > From my understanding, getLen() always returned the length of the file in > bytes. > > thank, > dhruba > > > On Fri, Jun 26, 2009 at 9:20 AM, Dima Rzhevskiy <dima@rzhevskiy.info> > wrote: > > > Hi all > > I try get length of file hadoop(RawFilesysten or hdfs) . > > In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend > that > > this method "return the length of this file, in blocks" > > But method return size in bytes. > > > > Is this bug in documentation or implememtation? > > I use hadoop-0.18.3. > > > > > > Dmitry Rzhevskiy. > > > -- С уважением, Ржевский Дмитрий, www.rzhevskiy.info тел. +7(926)426-55-55
[ https://issues.apache.org/jira/browse/HADOOP-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas updated HADOOP-6109:
----------------------------------
Component/s: (was: util)
io
> Handle large (several MB) text input lines in a reasonable amount of time
> -------------------------------------------------------------------------
>
> Key: HADOOP-6109
> URL: https://issues.apache.org/jira/browse/HADOOP-6109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: io
> Affects Versions: 0.19.0
> Environment: Linux 2.6 kernel, java 1.6 AMD Dual-Core Opteron 2.6GHz with 1M
L1/L2 cache 1.8G RAM
> Reporter: thushara wijeratna
> Attachments: HADOOP-1234.patch, HADOOP-1234.patch
>
>
> problem:
> =======
> hadoop was timing out on a simple pass-through job (with the default 10 min timeout)
> cause:
> =====
> i hunted this down to how Text lines are being processed inside org.apache.hadoop.util.LineReader.
> i have a fix, a task that took more than 20 minutes and still failed to complete, completes
with this fix in under 30 s.
> i attach the patch (for trunk)
> the problem traces:
> ================
> hadoop version: 0.19.0
> userlogs on slave node:
> 2009-05-29 13:57:33,551 WARN org.apache.hadoop.mapred.TaskRunner: Parent died. Exiting
attempt_200905281652_0013_m_000006_1
> [root@domU-12-31-38-01-7C-92 attempt_200905281652_0013_m_000006_1]#
> tellingly, the last input line processed right before this WARN is 19K. (i log the full
input line in the map function for debugging)
> output on map-reduce task:
> Task attempt_200905281652_0013_m_000006_2 failed to report status for 600 seconds. Killing!
> 09/05/29 14:08:01 INFO mapred.JobClient: map 99% reduce 32%
> 09/05/29 14:18:05 INFO mapred.JobClient: map 98% reduce 32%
> java.io.IOException: Job failed!
> at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1217)
> at com.adxpose.data.mr.DailyHeatmapAggregator.run(DailyHeatmapAggregator.java:547)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at com.adxpose.data.mr.DailyHeatmapAggregator.main(DailyHeatmapAggregator.java:553)
> 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 org.apache.hadoop.util.RunJar.main(RunJar.java:165)
> at org.apache.hadoop.mapred.JobShell.run(JobShell.java:54)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
> at org.apache.hadoop.mapred.JobShell.main(JobShell.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas updated HADOOP-6109:
----------------------------------
Assignee: thushara wijeratna
Status: Patch Available (was: Open)
> Handle large (several MB) text input lines in a reasonable amount of time
> -------------------------------------------------------------------------
>
> Key: HADOOP-6109
> URL: https://issues.apache.org/jira/browse/HADOOP-6109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: io
> Affects Versions: 0.19.0
> Environment: Linux 2.6 kernel, java 1.6 AMD Dual-Core Opteron 2.6GHz with 1M
L1/L2 cache 1.8G RAM
> Reporter: thushara wijeratna
> Assignee: thushara wijeratna
> Attachments: HADOOP-1234.patch, HADOOP-1234.patch
>
>
> problem:
> =======
> hadoop was timing out on a simple pass-through job (with the default 10 min timeout)
> cause:
> =====
> i hunted this down to how Text lines are being processed inside org.apache.hadoop.util.LineReader.
> i have a fix, a task that took more than 20 minutes and still failed to complete, completes
with this fix in under 30 s.
> i attach the patch (for trunk)
> the problem traces:
> ================
> hadoop version: 0.19.0
> userlogs on slave node:
> 2009-05-29 13:57:33,551 WARN org.apache.hadoop.mapred.TaskRunner: Parent died. Exiting
attempt_200905281652_0013_m_000006_1
> [root@domU-12-31-38-01-7C-92 attempt_200905281652_0013_m_000006_1]#
> tellingly, the last input line processed right before this WARN is 19K. (i log the full
input line in the map function for debugging)
> output on map-reduce task:
> Task attempt_200905281652_0013_m_000006_2 failed to report status for 600 seconds. Killing!
> 09/05/29 14:08:01 INFO mapred.JobClient: map 99% reduce 32%
> 09/05/29 14:18:05 INFO mapred.JobClient: map 98% reduce 32%
> java.io.IOException: Job failed!
> at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1217)
> at com.adxpose.data.mr.DailyHeatmapAggregator.run(DailyHeatmapAggregator.java:547)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at com.adxpose.data.mr.DailyHeatmapAggregator.main(DailyHeatmapAggregator.java:553)
> 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 org.apache.hadoop.util.RunJar.main(RunJar.java:165)
> at org.apache.hadoop.mapred.JobShell.run(JobShell.java:54)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
> at org.apache.hadoop.mapred.JobShell.main(JobShell.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
>From my understanding, getLen() always returned the length of the file in bytes. thank, dhruba On Fri, Jun 26, 2009 at 9:20 AM, Dima Rzhevskiy <dima@rzhevskiy.info> wrote: > Hi all > I try get length of file hadoop(RawFilesysten or hdfs) . > In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend that > this method "return the length of this file, in blocks" > But method return size in bytes. > > Is this bug in documentation or implememtation? > I use hadoop-0.18.3. > > > Dmitry Rzhevskiy. >
[ https://issues.apache.org/jira/browse/HADOOP-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Weil updated HADOOP-6116:
-------------------------------
Status: Patch Available (was: Open)
> Sqoop depends on commons-cli, which is not in its ivy.xml.
> ----------------------------------------------------------
>
> Key: HADOOP-6116
> URL: https://issues.apache.org/jira/browse/HADOOP-6116
> Project: Hadoop Common
> Issue Type: Bug
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
> Attachments: HADOOP-6116.patch
>
>
> Sqoop's ivy.xml needs commons-cli in order to build from scratch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Weil updated HADOOP-6116:
-------------------------------
Attachment: HADOOP-6116.patch
The new dependency in ivy.xml. Aaron Kimball actually made this code change on my computer
while we were together; I'm just submitting it here.
> Sqoop depends on commons-cli, which is not in its ivy.xml.
> ----------------------------------------------------------
>
> Key: HADOOP-6116
> URL: https://issues.apache.org/jira/browse/HADOOP-6116
> Project: Hadoop Common
> Issue Type: Bug
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
> Attachments: HADOOP-6116.patch
>
>
> Sqoop's ivy.xml needs commons-cli in order to build from scratch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Weil updated HADOOP-6116:
-------------------------------
Status: Patch Available (was: Open)
Adding the dependency to ivy.xml. Aaron Kimball actually made this change on my computer
while we were together; I'm just committing it.
> Sqoop depends on commons-cli, which is not in its ivy.xml.
> ----------------------------------------------------------
>
> Key: HADOOP-6116
> URL: https://issues.apache.org/jira/browse/HADOOP-6116
> Project: Hadoop Common
> Issue Type: Bug
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
>
> Sqoop's ivy.xml needs commons-cli in order to build from scratch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Weil updated HADOOP-6116:
-------------------------------
Status: Open (was: Patch Available)
> Sqoop depends on commons-cli, which is not in its ivy.xml.
> ----------------------------------------------------------
>
> Key: HADOOP-6116
> URL: https://issues.apache.org/jira/browse/HADOOP-6116
> Project: Hadoop Common
> Issue Type: Bug
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
>
> Sqoop's ivy.xml needs commons-cli in order to build from scratch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Weil updated HADOOP-6116:
-------------------------------
Summary: Sqoop depends on commons-cli, which is not in its ivy.xml. (was: Sqoop depends
on commons-cli, but it is not in its ivy.xml.)
> Sqoop depends on commons-cli, which is not in its ivy.xml.
> ----------------------------------------------------------
>
> Key: HADOOP-6116
> URL: https://issues.apache.org/jira/browse/HADOOP-6116
> Project: Hadoop Common
> Issue Type: Bug
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
>
> Sqoop's ivy.xml needs commons-cli in order to build from scratch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Sqoop depends on commons-cli, but it is not in its ivy.xml.
-----------------------------------------------------------
Key: HADOOP-6116
URL: https://issues.apache.org/jira/browse/HADOOP-6116
Project: Hadoop Common
Issue Type: Bug
Components: contrib/sqoop
Affects Versions: 0.21.0
Reporter: Kevin Weil
Priority: Minor
Sqoop's ivy.xml needs commons-cli in order to build from scratch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724906#action_12724906
]
Kevin Weil commented on HADOOP-6115:
------------------------------------
I have this working except for in the case of optimized local importing. Not sure why this
is failing ATM because the same command line statement succeeds, but I expect to have a patch
by the end of the weekend.
> Sqoop should allow a "where" clause to avoid having to export entire tables
> ---------------------------------------------------------------------------
>
> Key: HADOOP-6115
> URL: https://issues.apache.org/jira/browse/HADOOP-6115
> Project: Hadoop Common
> Issue Type: Improvement
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
>
> Sqoop currently only exports at the granularity of a table. This doesn't work well on
systems with large tables, where the overhead of performing a full dump each time is significant.
Allowing the user to specify a where clause is a relatively simple task which will give Sqoop
a lot more flexibility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Sqoop should allow a where clause in its export statements
----------------------------------------------------------
Key: HADOOP-6115
URL: https://issues.apache.org/jira/browse/HADOOP-6115
Project: Hadoop Common
Issue Type: Improvement
Components: contrib/sqoop
Affects Versions: 0.21.0
Reporter: Kevin Weil
Priority: Minor
Sqoop currently only exports at the granularity of a table. This doesn't work well on systems
with large tables, where the overhead of performing a full dump each time is significant.
Allowing the user to specify a where clause is a relatively simple task which will give Sqoop
a lot more flexibility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Weil updated HADOOP-6115:
-------------------------------
Summary: Sqoop should allow a "where" clause to avoid having to export entire tables
(was: Sqoop should allow a where clause in its export statements)
> Sqoop should allow a "where" clause to avoid having to export entire tables
> ---------------------------------------------------------------------------
>
> Key: HADOOP-6115
> URL: https://issues.apache.org/jira/browse/HADOOP-6115
> Project: Hadoop Common
> Issue Type: Improvement
> Components: contrib/sqoop
> Affects Versions: 0.21.0
> Reporter: Kevin Weil
> Priority: Minor
>
> Sqoop currently only exports at the granularity of a table. This doesn't work well on
systems with large tables, where the overhead of performing a full dump each time is significant.
Allowing the user to specify a where clause is a relatively simple task which will give Sqoop
a lot more flexibility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Rzhevskiy updated HADOOP-6114:
-------------------------------------
Comment: was deleted
(was: project compiled but some tests filed (befor modificatios tests failed too too)
)
> bug in documentation: org.apache.hadoop.fs.FileStatus.getLen()
> ---------------------------------------------------------------
>
> Key: HADOOP-6114
> URL: https://issues.apache.org/jira/browse/HADOOP-6114
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.18.3, 0.20.0
> Reporter: Dmitry Rzhevskiy
> Attachments: HADOOP-6114.patch
>
>
> In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend that this method
"return the length of this file, in blocks"
> But method return size in bytes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Rzhevskiy updated HADOOP-6114:
-------------------------------------
Attachment: HADOOP-6114.patch
trunk of project compiled but some tests failed ( tests failed, before applying patch too)
> bug in documentation: org.apache.hadoop.fs.FileStatus.getLen()
> ---------------------------------------------------------------
>
> Key: HADOOP-6114
> URL: https://issues.apache.org/jira/browse/HADOOP-6114
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.18.3, 0.20.0
> Reporter: Dmitry Rzhevskiy
> Attachments: HADOOP-6114.patch
>
>
> In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend that this method
"return the length of this file, in blocks"
> But method return size in bytes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724841#action_12724841
]
Hudson commented on HADOOP-5925:
--------------------------------
Integrated in Hadoop-Common-trunk #9 (See [http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/9/])
. EC2 scripts should exit on error.
> EC2 scripts should exit on error
> --------------------------------
>
> Key: HADOOP-5925
> URL: https://issues.apache.org/jira/browse/HADOOP-5925
> Project: Hadoop Common
> Issue Type: Improvement
> Components: contrib/ec2
> Reporter: Tom White
> Assignee: Tom White
> Fix For: 0.21.0
>
> Attachments: hadoop-5925.patch
>
>
> For example, if an ec2-authorize command fails the script should stop so that the problem
is easier to debug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724840#action_12724840
]
Hudson commented on HADOOP-5897:
--------------------------------
Integrated in Hadoop-Common-trunk #9 (See [http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/9/])
. Promote new name-node metrics to branch 0.20.
> Add more Metrics to Namenode to capture heap usage
> --------------------------------------------------
>
> Key: HADOOP-5897
> URL: https://issues.apache.org/jira/browse/HADOOP-5897
> Project: Hadoop Common
> Issue Type: Improvement
> Components: dfs, metrics
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Fix For: 0.21.0
>
> Attachments: 5897.rel20.patch, stats.1.patch, stats.patch, stats.patch
>
>
> Recently we had GC issues, where Namenode used more heap than usual. There was no growth
indicated by the data in current Metrics to justify the heap usage. Adding more stats such
as:
> - Counter to track blocks that are pending deletion
> - BlocksMap hashmap capacity
> - Counter to track excess number of blocks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724839#action_12724839
]
Hudson commented on HADOOP-6112:
--------------------------------
Integrated in Hadoop-Common-trunk #9 (See [http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/9/])
. Fix hudsonPatchQueueAdmin for different projects.
> to fix hudsonPatchQueueAdmin for different projects
> ---------------------------------------------------
>
> Key: HADOOP-6112
> URL: https://issues.apache.org/jira/browse/HADOOP-6112
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Reporter: Giridharan Kesavan
> Assignee: Giridharan Kesavan
> Attachments: HADOOP-6112.patch
>
>
> To fix hudsonPatchQueueAdmin process for different hadoop projects.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
On Fri, Jun 26, 2009 at 11:10 AM, Aaron Kimball<aaron@cloudera.com> wrote: > Any progress on this over the last few days? Did the > infrastructure-dev team provide an ETA when git repos can be set up? > I've got some work in the pipeline, would be great to clear the dust > out of my development process and get back on track ;) I sent email to Jukka and he has been on vacation this week. He will try and set us up soon. -- Owen
Of course the 4' is much closer to my choice #2, which makes me happy too. +1
[ https://issues.apache.org/jira/browse/HADOOP-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Rzhevskiy updated HADOOP-6114:
-------------------------------------
Attachment: (was: HADOOP-6114.patch)
> bug in documentation: org.apache.hadoop.fs.FileStatus.getLen()
> ---------------------------------------------------------------
>
> Key: HADOOP-6114
> URL: https://issues.apache.org/jira/browse/HADOOP-6114
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.18.3, 0.20.0
> Reporter: Dmitry Rzhevskiy
>
> In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend that this method
"return the length of this file, in blocks"
> But method return size in bytes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Rzhevskiy updated HADOOP-6114:
-------------------------------------
Attachment: HADOOP-6114.patch
project compiled but some tests filed (befor modificatios tests failed too too)
> bug in documentation: org.apache.hadoop.fs.FileStatus.getLen()
> ---------------------------------------------------------------
>
> Key: HADOOP-6114
> URL: https://issues.apache.org/jira/browse/HADOOP-6114
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.18.3, 0.20.0
> Reporter: Dmitry Rzhevskiy
> Attachments: HADOOP-6114.patch
>
>
> In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend that this method
"return the length of this file, in blocks"
> But method return size in bytes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
bug in documentation: org.apache.hadoop.fs.FileStatus.getLen()
---------------------------------------------------------------
Key: HADOOP-6114
URL: https://issues.apache.org/jira/browse/HADOOP-6114
Project: Hadoop Common
Issue Type: Bug
Affects Versions: 0.20.0, 0.18.3
Reporter: Dmitry Rzhevskiy
In javadoc method org.apache.hadoop.fs.FileStatus.getLen() writtend that this method "return
the length of this file, in blocks"
But method return size in bytes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
So will you post the new ones? --- Jim Kellerman, Powerset (Live Search, Microsoft Corporation) > -----Original Message----- > From: Nigel Daley [mailto:ndaley@yahoo-inc.com] > Sent: Friday, June 26, 2009 4:51 PM > To: core-dev@hadoop.apache.org > Subject: Re: New subproject logos > > I just spent some time with the graphic designer. The lower case > version didn't look good because of the tail on the hadoop "p" meant > mapreduce had to be too small. > > I'll checkin cleaned up vector CMYK and RGB versions of the 3 logos. > > Nige > > > On Jun 26, 2009, at 10:33 AM, Doug Cutting wrote: > > > I like them except I think they should be all lowercase, to be > > consistent with the style of the existing Hadoop logo. > > > > Doug > > > > Nigel Daley wrote: > >> Here are some logos for the new subprojects > >> http://www.flickr.com/photos/88199325@N00/3661433605/ > >> Please vote +1 if you like 'em and -1 if you don't. > >> Cheers, > >> Nige >
I just spent some time with the graphic designer. The lower case version didn't look good because of the tail on the hadoop "p" meant mapreduce had to be too small. I'll checkin cleaned up vector CMYK and RGB versions of the 3 logos. Nige On Jun 26, 2009, at 10:33 AM, Doug Cutting wrote: > I like them except I think they should be all lowercase, to be > consistent with the style of the existing Hadoop logo. > > Doug > > Nigel Daley wrote: >> Here are some logos for the new subprojects >> http://www.flickr.com/photos/88199325@N00/3661433605/ >> Please vote +1 if you like 'em and -1 if you don't. >> Cheers, >> Nige
[ https://issues.apache.org/jira/browse/HADOOP-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhiyong zhang resolved HADOOP-5775.
-----------------------------------
Resolution: Fixed
Fix Version/s: 0.21.0
solved in HDFS-447
> HdfsProxy Unit Test should not depend on HDFSPROXY_CONF_DIR environment
> -----------------------------------------------------------------------
>
> Key: HADOOP-5775
> URL: https://issues.apache.org/jira/browse/HADOOP-5775
> Project: Hadoop Common
> Issue Type: Bug
> Components: contrib/hdfsproxy
> Reporter: zhiyong zhang
> Assignee: zhiyong zhang
> Fix For: 0.21.0
>
> Attachments: HADOOP-5775.patch
>
>
> as war target read user-certs.xml and user-permissions.xml from $HDFSPROXY_CONF_DIR.
If a user set this environment and have some files in it, it could potentially cause the unit
test to fail if the conf files does not match what the unit test needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724755#action_12724755
]
Konstantin Shvachko commented on HADOOP-5897:
---------------------------------------------
+1
Committed to branch 0.20.
> Add more Metrics to Namenode to capture heap usage
> --------------------------------------------------
>
> Key: HADOOP-5897
> URL: https://issues.apache.org/jira/browse/HADOOP-5897
> Project: Hadoop Common
> Issue Type: Improvement
> Components: dfs, metrics
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Fix For: 0.21.0
>
> Attachments: 5897.rel20.patch, stats.1.patch, stats.patch, stats.patch
>
>
> Recently we had GC issues, where Namenode used more heap than usual. There was no growth
indicated by the data in current Metrics to justify the heap usage. Adding more stats such
as:
> - Counter to track blocks that are pending deletion
> - BlocksMap hashmap capacity
> - Counter to track excess number of blocks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
thushara wijeratna updated HADOOP-6109:
---------------------------------------
Attachment: HADOOP-1234.patch
> Handle large (several MB) text input lines in a reasonable amount of time
> -------------------------------------------------------------------------
>
> Key: HADOOP-6109
> URL: https://issues.apache.org/jira/browse/HADOOP-6109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: util
> Affects Versions: 0.19.0
> Environment: Linux 2.6 kernel, java 1.6 AMD Dual-Core Opteron 2.6GHz with 1M
L1/L2 cache 1.8G RAM
> Reporter: thushara wijeratna
> Attachments: HADOOP-1234.patch, HADOOP-1234.patch
>
>
> problem:
> =======
> hadoop was timing out on a simple pass-through job (with the default 10 min timeout)
> cause:
> =====
> i hunted this down to how Text lines are being processed inside org.apache.hadoop.util.LineReader.
> i have a fix, a task that took more than 20 minutes and still failed to complete, completes
with this fix in under 30 s.
> i attach the patch (for trunk)
> the problem traces:
> ================
> hadoop version: 0.19.0
> userlogs on slave node:
> 2009-05-29 13:57:33,551 WARN org.apache.hadoop.mapred.TaskRunner: Parent died. Exiting
attempt_200905281652_0013_m_000006_1
> [root@domU-12-31-38-01-7C-92 attempt_200905281652_0013_m_000006_1]#
> tellingly, the last input line processed right before this WARN is 19K. (i log the full
input line in the map function for debugging)
> output on map-reduce task:
> Task attempt_200905281652_0013_m_000006_2 failed to report status for 600 seconds. Killing!
> 09/05/29 14:08:01 INFO mapred.JobClient: map 99% reduce 32%
> 09/05/29 14:18:05 INFO mapred.JobClient: map 98% reduce 32%
> java.io.IOException: Job failed!
> at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1217)
> at com.adxpose.data.mr.DailyHeatmapAggregator.run(DailyHeatmapAggregator.java:547)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at com.adxpose.data.mr.DailyHeatmapAggregator.main(DailyHeatmapAggregator.java:553)
> 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 org.apache.hadoop.util.RunJar.main(RunJar.java:165)
> at org.apache.hadoop.mapred.JobShell.run(JobShell.java:54)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
> at org.apache.hadoop.mapred.JobShell.main(JobShell.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724741#action_12724741
]
thushara wijeratna commented on HADOOP-6109:
--------------------------------------------
correct Chris - the speculated over-allocation is the only significant difference between
ByteArrayOutputStream and Text class, with regard to increasing capacity.
i have tested this and can confirm the perf improvements. after running the hadoop tests i
will attach the patch.
thanks,
> Handle large (several MB) text input lines in a reasonable amount of time
> -------------------------------------------------------------------------
>
> Key: HADOOP-6109
> URL: https://issues.apache.org/jira/browse/HADOOP-6109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: util
> Affects Versions: 0.19.0
> Environment: Linux 2.6 kernel, java 1.6 AMD Dual-Core Opteron 2.6GHz with 1M
L1/L2 cache 1.8G RAM
> Reporter: thushara wijeratna
> Attachments: HADOOP-1234.patch
>
>
> problem:
> =======
> hadoop was timing out on a simple pass-through job (with the default 10 min timeout)
> cause:
> =====
> i hunted this down to how Text lines are being processed inside org.apache.hadoop.util.LineReader.
> i have a fix, a task that took more than 20 minutes and still failed to complete, completes
with this fix in under 30 s.
> i attach the patch (for trunk)
> the problem traces:
> ================
> hadoop version: 0.19.0
> userlogs on slave node:
> 2009-05-29 13:57:33,551 WARN org.apache.hadoop.mapred.TaskRunner: Parent died. Exiting
attempt_200905281652_0013_m_000006_1
> [root@domU-12-31-38-01-7C-92 attempt_200905281652_0013_m_000006_1]#
> tellingly, the last input line processed right before this WARN is 19K. (i log the full
input line in the map function for debugging)
> output on map-reduce task:
> Task attempt_200905281652_0013_m_000006_2 failed to report status for 600 seconds. Killing!
> 09/05/29 14:08:01 INFO mapred.JobClient: map 99% reduce 32%
> 09/05/29 14:18:05 INFO mapred.JobClient: map 98% reduce 32%
> java.io.IOException: Job failed!
> at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1217)
> at com.adxpose.data.mr.DailyHeatmapAggregator.run(DailyHeatmapAggregator.java:547)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at com.adxpose.data.mr.DailyHeatmapAggregator.main(DailyHeatmapAggregator.java:553)
> 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 org.apache.hadoop.util.RunJar.main(RunJar.java:165)
> at org.apache.hadoop.mapred.JobShell.run(JobShell.java:54)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
> at org.apache.hadoop.mapred.JobShell.main(JobShell.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724695#action_12724695
]
Chris Douglas commented on HADOOP-6109:
---------------------------------------
You might want to try the same experiment with a larger io.file.buffer.size, say 1 or 2MB.
Though the growth remains linear, at least it grows by more than 4k per read.
Rather than growing a separate buffer and copying that into Text, replacing the current code
in Text::setCapacity with {{bytes = Arrays.copyOf(bytes, Math.max(len, length << 1))}}
should improve Text's performance. I don't think there's any reason why Text needs to be exactly
the length of the largest value it's held.
> Handle large (several MB) text input lines in a reasonable amount of time
> -------------------------------------------------------------------------
>
> Key: HADOOP-6109
> URL: https://issues.apache.org/jira/browse/HADOOP-6109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: util
> Affects Versions: 0.19.0
> Environment: Linux 2.6 kernel, java 1.6 AMD Dual-Core Opteron 2.6GHz with 1M
L1/L2 cache 1.8G RAM
> Reporter: thushara wijeratna
> Attachments: HADOOP-1234.patch
>
>
> problem:
> =======
> hadoop was timing out on a simple pass-through job (with the default 10 min timeout)
> cause:
> =====
> i hunted this down to how Text lines are being processed inside org.apache.hadoop.util.LineReader.
> i have a fix, a task that took more than 20 minutes and still failed to complete, completes
with this fix in under 30 s.
> i attach the patch (for trunk)
> the problem traces:
> ================
> hadoop version: 0.19.0
> userlogs on slave node:
> 2009-05-29 13:57:33,551 WARN org.apache.hadoop.mapred.TaskRunner: Parent died. Exiting
attempt_200905281652_0013_m_000006_1
> [root@domU-12-31-38-01-7C-92 attempt_200905281652_0013_m_000006_1]#
> tellingly, the last input line processed right before this WARN is 19K. (i log the full
input line in the map function for debugging)
> output on map-reduce task:
> Task attempt_200905281652_0013_m_000006_2 failed to report status for 600 seconds. Killing!
> 09/05/29 14:08:01 INFO mapred.JobClient: map 99% reduce 32%
> 09/05/29 14:18:05 INFO mapred.JobClient: map 98% reduce 32%
> java.io.IOException: Job failed!
> at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1217)
> at com.adxpose.data.mr.DailyHeatmapAggregator.run(DailyHeatmapAggregator.java:547)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at com.adxpose.data.mr.DailyHeatmapAggregator.main(DailyHeatmapAggregator.java:553)
> 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 org.apache.hadoop.util.RunJar.main(RunJar.java:165)
> at org.apache.hadoop.mapred.JobShell.run(JobShell.java:54)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
> at org.apache.hadoop.mapred.JobShell.main(JobShell.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/HADOOP-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724644#action_12724644
]
Tsz Wo (Nicholas), SZE commented on HADOOP-2366:
------------------------------------------------
After the project split, this problem needs two separated patches, one for Common and the
other one for HDFS. I think we should change Configuration and StringUtils in this issue
and create a new HDFS issue for the rest.
> Space in the value for dfs.data.dir can cause great problems
> ------------------------------------------------------------
>
> Key: HADOOP-2366
> URL: https://issues.apache.org/jira/browse/HADOOP-2366
> Project: Hadoop Common
> Issue Type: Bug
> Components: conf
> Reporter: Ted Dunning
> Assignee: Michele (aka pirroh) Catasta
> Attachments: HADOOP-2366-trimmed.patch, HADOOP-2366.patch
>
>
> The following configuration causes problems:
> <property>
> <name>dfs.data.dir</name>
> <value>/mnt/hstore2/hdfs, /home/foo/dfs</value>
> <description>
> Determines where on the local filesystem an DFS data node should store its bl
> ocks. If this is a comma-delimited list of directories, then data will be stor
> ed in all named directories, typically on different devices. Directories that
> do not exist are ignored.
> </description>
> </property>
> The problem is that the space after the comma causes the second directory for storage
to be " /home/foo/dfs" which is in a directory named <SPACE> which contains a sub-dir
named "home" in the hadoop datanodes default directory. This will typically cause the user's
home partition to fill, but will be very hard for the user to understand since a directory
with a whitespace name is hard to understand.
> My proposed solution would be to trimLeft all path names from this and similar property
after splitting on comma. This still allows spaces in file and directory names but avoids
this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
It looks better when the elephant stands on the ground, imo. Common should be moved down. Right now C overlaps with upper H. It should be below to match the other 2 logos. Enlargement of the elephant should be really small if needed at all. +1 --Konstantin Doug Cutting wrote: > Enis Soztutar wrote: >> +1 with a minor suggestion: how about we enlarge the elephants so that >> the height matches both lines, and she can stand on the ground : ) > > +1 That would probably look better, if someone has the time to make this > change. > > Doug >
Any progress on this over the last few days? Did the infrastructure-dev team provide an ETA when git repos can be set up? I've got some work in the pipeline, would be great to clear the dust out of my development process and get back on track ;) Thanks! - Aaron On Mon, Jun 22, 2009 at 10:52 AM, Owen O'Malley<omalley@apache.org> wrote: > > On Jun 19, 2009, at 8:11 PM, Todd Lipcon wrote: > >> Any git users here know how this will affect git.apache.org? Will there >> now >> be three repos there? > > I sent email to infrastructure-dev asking for the repositories to be set up. > And yes, there will be 3 repositories there. > > -- Owen >
[ https://issues.apache.org/jira/browse/HADOOP-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amar Kamat updated HADOOP-5921:
-------------------------------
Release Note: jobtracker fails if it cannot create jobtracker.info (if sufficient datanodes
are not up). With this patch it waits forever for it to create.
> JobTracker does not come up because of NotReplicatedYetException
> ----------------------------------------------------------------
>
> Key: HADOOP-5921
> URL: https://issues.apache.org/jira/browse/HADOOP-5921
> Project: Hadoop Common
> Issue Type: Bug
> Components: mapred
> Affects Versions: 0.20.0
> Reporter: Amareshwari Sriramadasu
> Assignee: Amar Kamat
> Fix For: 0.20.1
>
> Attachments: HADOOP-5921-v1.0.patch, HADOOP-5921-v2.4.patch, HADOOP-5921-v2.5.patch
>
>
> Sometimes (On a big cluster) Jobtracker does not come up, because Info file could not
be replicated on dfs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
+1 for 4' :) -- amr Ted Dunning wrote: > On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting <cutting@apache.org> wrote: > > >> Oops, I added a new option that I called (4), but should have called (5): >> >> (4) Send create/resolve to -dev and all others to -issues (a new >> >>> list) plus prohibit all comment edits and permit comment deletion >>> only by admins. (Closing is not generally interesting, since it's >>> only done to seal an issue once its included in a release.) >>> >>> >> Lots of folks +1'd (4) after this, and I thought they were voting for my >> (4), not Owen's. >> >> If anyone meant to vote for Owen's, not mine, please speak up. >> >> Sorry for the confusion! >> >> > > > Ahhh.... > > I *didn't* vote for (4) because I missed the overload. > > +1 for 4' > >