Matt Foley created HDFS-3617:
Summary: Port HDFS-96 to branch-1 (support blocks greater than 2GB)
Key: HDFS-3617
URL: https://issues.apache.org/jira/browse/HDFS-3617
Project: Hadoop HDFS
Issue
Brahma Reddy Battula created HDFS-3618:
--
Summary: IF RC is other than zero are we assuming that Service is
down (What if NC command itself not found)
Key: HDFS-3618
URL:
See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1098/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 11637 lines...]
[INFO]
[INFO] ---
See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1098/changes
Changes:
[harsh] MAPREDUCE-3906. Fix inconsistency in documentation regarding
mapreduce.jobhistory.principal. Contributed by Eugene Koontz. (harsh)
[harsh] MAPREDUCE-3907. Document entries mapred-default.xml for the jobhistory
See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/308/
See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/308/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 17848 lines...]
[INFO] Deleting
I'm working with Jean-Baptiste to make hadoop work in OSGi.
OSGi works with classloader in a very specific way which leads to several
problems with hadoop.
Let me quickly explain how OSGi works. In OSGi, you deploy bundles, which
are jars with additional OSGi metadata. This metadata is used by
Guillaume,
I am not super familiar with OSGi. I have used it a little in the past,
but that was 5+ years ago. I am in favor of something that will fix the
CLASSPATH problems that we currently have and would allow for CLASSPATH
isolation between Hadoop itself and the applications that use
Hi Bobby,
Guillaume and I are working on trunk. So it makes sense to focus on
trunk for this kind of refactoring. We are working on a fork branch on
github. We can choose when merge our changes to trunk (or a dedicated
branch).
Regards
JB
On 07/09/2012 04:37 PM, Robert Evans wrote:
Right, that would surely be incompatible. The initial work I did was on
1.0.3 and those problems can be solved in a more simple (though less clean)
way in that branch, mainly because of the fact that there is a single jar
which contain everything, so that causes less problems in OSGi.
For trunk,
Junping Du created HDFS-3619:
Summary: isGoodBlockCandidate() in Balancer is not handling
properly if replica factor 3
Key: HDFS-3619
URL: https://issues.apache.org/jira/browse/HDFS-3619
Project: Hadoop
Guillaume,
The problem with Configuration is that it is public, so changing it does
not just impact Hadoop. It also impacts all of the projects that use it,
either directly as part of the Map/Reduce APIs or for storing their own
configuration. Within Hadoop proper there are several places where
Alejandro Abdelnur created HDFS-3620:
Summary: WebHdfsFileSystem getHomeDirectory() should not resolve
locally
Key: HDFS-3620
URL: https://issues.apache.org/jira/browse/HDFS-3620
Project: Hadoop
Thanks for the update guys.
We are going to look for a way to handle configurations in an OSGi way
without changing the API/dependency.
Regards
JB
On 07/09/2012 08:30 PM, Owen O'Malley wrote:
Changing the configurations is a big and very touchy job. It is touchy in
that it is very exposed
Harsh J created HDFS-3621:
-
Summary: Add a main method to HdfsConfiguration, for debug purposes
Key: HDFS-3621
URL: https://issues.apache.org/jira/browse/HDFS-3621
Project: Hadoop HDFS
Issue Type:
Robert Joseph Evans created HDFS-3622:
-
Summary: Backport HDFS-3541 to branch-0.23
Key: HDFS-3622
URL: https://issues.apache.org/jira/browse/HDFS-3622
Project: Hadoop HDFS
Issue Type:
Uma Maheswara Rao G created HDFS-3623:
-
Summary: BKJM: zkLatchWaitTimeout hard coded to 6000. Make use of
ZKSessionTimeout instead.
Key: HDFS-3623
URL: https://issues.apache.org/jira/browse/HDFS-3623
Colin Patrick McCabe created HDFS-3624:
--
Summary: fuse_dfs: improve user and group translation
Key: HDFS-3624
URL: https://issues.apache.org/jira/browse/HDFS-3624
Project: Hadoop HDFS
18 matches
Mail list logo