[jira] [Commented] (HADOOP-11090) [Umbrella] Support Java 8 in Hadoop

2016-09-07 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470855#comment-15470855
 ] 

Benoit Sigoure commented on HADOOP-11090:
-

Nope.  What else is known to break?

> [Umbrella] Support Java 8 in Hadoop
> ---
>
> Key: HADOOP-11090
> URL: https://issues.apache.org/jira/browse/HADOOP-11090
> Project: Hadoop Common
>  Issue Type: New Feature
>Reporter: Mohammad Kamrul Islam
>Assignee: Mohammad Kamrul Islam
>
> Java 8 is coming quickly to various clusters. Making sure Hadoop seamlessly 
> works  with Java 8 is important for the Apache community.
>   
> This JIRA is to track  the issues/experiences encountered during Java 8 
> migration. If you find a potential bug , please create a separate JIRA either 
> as a sub-task or linked into this JIRA.
> If you find a Hadoop or JVM configuration tuning, you can create a JIRA as 
> well. Or you can add  a comment  here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-11090) [Umbrella] Support Java 8 in Hadoop

2016-09-06 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468561#comment-15468561
 ] 

Benoit Sigoure commented on HADOOP-11090:
-

Is this JIRA still relevant?  I've also been running Hadoop+HBase on JDK8 just 
fine for quite some time now, but curious to know whether there are any known 
outstanding issues.

> [Umbrella] Support Java 8 in Hadoop
> ---
>
> Key: HADOOP-11090
> URL: https://issues.apache.org/jira/browse/HADOOP-11090
> Project: Hadoop Common
>  Issue Type: New Feature
>Reporter: Mohammad Kamrul Islam
>Assignee: Mohammad Kamrul Islam
>
> Java 8 is coming quickly to various clusters. Making sure Hadoop seamlessly 
> works  with Java 8 is important for the Apache community.
>   
> This JIRA is to track  the issues/experiences encountered during Java 8 
> migration. If you find a potential bug , please create a separate JIRA either 
> as a sub-task or linked into this JIRA.
> If you find a Hadoop or JVM configuration tuning, you can create a JIRA as 
> well. Or you can add  a comment  here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-12910) Add new FileSystem API to support asynchronous method calls

2016-06-08 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-12910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321033#comment-15321033
 ] 

Benoit Sigoure commented on HADOOP-12910:
-

bq. Features such as chaining are attractive, cool, fashionable and I-like-it, 
however, nonessential. Today we don't have any async API so that users cannot 
possibly do anything to work around it – when a blocking call is invoked, the 
caller is blocked. Once we have an async API as simple as returning Future. The 
caller can possibly use other mean or library to do chaining. Please correct me 
if you disagree.

I disagree.  It's not "fashionable".  It's key to have good, composable 
asynchronous APIs.  I don't know what sort of experience you've had with 
asynchronous programming, but mine is that non-composable asynchronous APIs 
suck and are harder to work with.  Writing async code is already harder than 
writing sync code, so not adding extra burden with APIs that don't compose well 
makes a significant difference on developer productivity and code quality.

> Add new FileSystem API to support asynchronous method calls
> ---
>
> Key: HADOOP-12910
> URL: https://issues.apache.org/jira/browse/HADOOP-12910
> Project: Hadoop Common
>  Issue Type: New Feature
>  Components: fs
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Xiaobing Zhou
> Attachments: HADOOP-12910-HDFS-9924.000.patch, 
> HADOOP-12910-HDFS-9924.001.patch, HADOOP-12910-HDFS-9924.002.patch
>
>
> Add a new API, namely FutureFileSystem (or AsynchronousFileSystem, if it is a 
> better name).  All the APIs in FutureFileSystem are the same as FileSystem 
> except that the return type is wrapped by Future, e.g.
> {code}
>   //FileSystem
>   public boolean rename(Path src, Path dst) throws IOException;
>   //FutureFileSystem
>   public Future rename(Path src, Path dst) throws IOException;
> {code}
> Note that FutureFileSystem does not extend FileSystem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-12910) Add new FileSystem API to support asynchronous method calls

2016-06-06 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-12910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15317847#comment-15317847
 ] 

Benoit Sigoure commented on HADOOP-12910:
-

One of the key things that {{Deferred}} and [Finagle's 
{{Future}}|https://twitter.github.io/finagle/guide/Futures.html#sequential-composition]
 both enable is composition.  This allows you to chain multiple asynchronous 
operations in a type-safe fashion.

For example, when making an RPC call to HBase, a client might first need to do 
a lookup in ZooKeeper, which asynchronously returns a byte array, then parse a 
RegionInfo out of the byte array and make an RPC call to an HBase server, which 
returns some response of type {{FooResponse}}.  In this semi-hypothetical 
pipeline, {{Deferred}} and {{Future}} allow you to build a string of 
asynchronous operations, in which the (successful) output of one operation is 
the input of the next operation.  I don't see how the proposed 
{{FutureWithCallback}} interface can cater to such use cases, which will lead 
to asynchronous APIs that are difficult to compose.

In the proposal for trunk at least with {{CompletionStage}} you get that with 
{{thenApply}}, but I hope this means that not too many APIs will be created 
with {{FutureWithCallback}}, as they'll probably stick around for a while and 
be hard to get rid of.

> Add new FileSystem API to support asynchronous method calls
> ---
>
> Key: HADOOP-12910
> URL: https://issues.apache.org/jira/browse/HADOOP-12910
> Project: Hadoop Common
>  Issue Type: New Feature
>  Components: fs
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Xiaobing Zhou
> Attachments: HADOOP-12910-HDFS-9924.000.patch, 
> HADOOP-12910-HDFS-9924.001.patch, HADOOP-12910-HDFS-9924.002.patch
>
>
> Add a new API, namely FutureFileSystem (or AsynchronousFileSystem, if it is a 
> better name).  All the APIs in FutureFileSystem are the same as FileSystem 
> except that the return type is wrapped by Future, e.g.
> {code}
>   //FileSystem
>   public boolean rename(Path src, Path dst) throws IOException;
>   //FutureFileSystem
>   public Future rename(Path src, Path dst) throws IOException;
> {code}
> Note that FutureFileSystem does not extend FileSystem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-12910) Add new FileSystem API to support asynchronous method calls

2016-05-31 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-12910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308275#comment-15308275
 ] 

Benoit Sigoure commented on HADOOP-12910:
-

Yes {{Deferred}} is 3-clause BSD, see the license @ 
https://github.com/OpenTSDB/async/blob/master/COPYING

> Add new FileSystem API to support asynchronous method calls
> ---
>
> Key: HADOOP-12910
> URL: https://issues.apache.org/jira/browse/HADOOP-12910
> Project: Hadoop Common
>  Issue Type: New Feature
>  Components: fs
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Xiaobing Zhou
> Attachments: HADOOP-12910-HDFS-9924.000.patch, 
> HADOOP-12910-HDFS-9924.001.patch, HADOOP-12910-HDFS-9924.002.patch
>
>
> Add a new API, namely FutureFileSystem (or AsynchronousFileSystem, if it is a 
> better name).  All the APIs in FutureFileSystem are the same as FileSystem 
> except that the return type is wrapped by Future, e.g.
> {code}
>   //FileSystem
>   public boolean rename(Path src, Path dst) throws IOException;
>   //FutureFileSystem
>   public Future rename(Path src, Path dst) throws IOException;
> {code}
> Note that FutureFileSystem does not extend FileSystem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Created] (HADOOP-12363) Hadoop binary distributions contain many copies of the same jars

2015-08-28 Thread Benoit Sigoure (JIRA) 
Benoit Sigoure created HADOOP-12363:
---

 Summary: Hadoop binary distributions contain many copies of the 
same jars
 Key: HADOOP-12363
 URL: https://issues.apache.org/jira/browse/HADOOP-12363
 Project: Hadoop Common
  Issue Type: Improvement
Reporter: Benoit Sigoure
Priority: Minor


[I noticed this 2 years 
ago|https://twitter.com/tsunanet/status/384917643162972161] but this is bugging 
me again so I'm finally filing a bug ;o

The Hadoop binary distribution is insanely redundant.  Over 80% of the size of 
the ~200MB tarballs distributed both by Apache upstream and by Cloudera is made 
of duplicate files.

Back when I was complaining about CDH 4.4.0, the Hadoop tarball contained [3477 
duplicate files, some of which had 98 copies in the 
tarball|http://tsunanet.net/~tsuna/cdh440-dup-files.txt]!

Now I'm looking at the official {{hadoop-2.7.1.tar.gz}} and I'm seeing 7 copies 
of {{jackson-mapper-asl-1.9.13.jar}}, {{jersey-server-1.9.jar}}, 
{{protobuf-java-2.5.0.jar}}, etc, 6 copies of {{guava-11.0.2.jar}}, 
{{xz-1.0.jar}}, {{commons-logging-1.1.3.jar}}, etc, 5 copies of 
{{snappy-java-1.0.4.1.jar}}, etc etc etc.  All in all there are well over 200 
files that appear at least twice in the tarball, and that account for 118MB 
worth of files that could just be replaced with a symlink (assuming you don't 
want to change the structure of the tarball at all).

This is really not necessary :)

Can we fix the distribution?  I'm sure Cloudera and others will fix their 
distributions as well once this is fixed upstream (their distros exhibit a 
substantially more acute version of this problem).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HADOOP-11990) DNS#reverseDns fails with a NumberFormatException when using an IPv6 DNS server

2015-05-17 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14547499#comment-14547499
 ] 

Benoit Sigoure commented on HADOOP-11990:
-

After some more Googling, this appears to be a JDK bug: [JDK-6991580: IPv6 
Nameservers in resolv.conf throws 
NumberFormatException|https://bugs.openjdk.java.net/browse/JDK-6991580].  Don't 
know if there's anything that can be done in {{DNS.java}} to workaround this 
bug.

 DNS#reverseDns fails with a NumberFormatException when using an IPv6 DNS 
 server
 ---

 Key: HADOOP-11990
 URL: https://issues.apache.org/jira/browse/HADOOP-11990
 Project: Hadoop Common
  Issue Type: Bug
  Components: net
Affects Versions: 2.5.1
 Environment: java version 1.7.0_45
 Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
 Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Reporter: Benoit Sigoure

 With this resolv.conf:
 {code}
 nameserver 192.168.1.1
 nameserver 2604:5500:3::3
 nameserver 2604:5500:3:3::3
 {code}
 Starting HBase yields the following:
 {code}
 Caused by: java.lang.NumberFormatException: For input string: 5500:3::3
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 at java.lang.Integer.parseInt(Integer.java:492)
 at java.lang.Integer.parseInt(Integer.java:527)
 at com.sun.jndi.dns.DnsClient.init(DnsClient.java:122)
 at com.sun.jndi.dns.Resolver.init(Resolver.java:61)
 at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:570)
 at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:430)
 at 
 com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231)
 at 
 com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139)
 at 
 com.sun.jndi.toolkit.url.GenericURLDirContext.getAttributes(GenericURLDirContext.java:103)
 at 
 javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
 at org.apache.hadoop.net.DNS.reverseDns(DNS.java:84)
 at org.apache.hadoop.net.DNS.getHosts(DNS.java:241)
 at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:344)
 at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:362)
 at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:341)
 at 
 org.apache.hadoop.hbase.regionserver.RSRpcServices.getHostname(RSRpcServices.java:825)
 at 
 org.apache.hadoop.hbase.regionserver.RSRpcServices.init(RSRpcServices.java:782)
 at 
 org.apache.hadoop.hbase.master.MasterRpcServices.init(MasterRpcServices.java:195)
 at 
 org.apache.hadoop.hbase.master.HMaster.createRpcServices(HMaster.java:477)
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.init(HRegionServer.java:492)
 at org.apache.hadoop.hbase.master.HMaster.init(HMaster.java:333)
 at 
 org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.init(HMasterCommandLine.java:276)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at 
 org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:139)
 ... 7 more
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HADOOP-11990) DNS#reverseDns fails with a NumberFormatException when using an IPv6 DNS server

2015-05-17 Thread Benoit Sigoure (JIRA) 
Benoit Sigoure created HADOOP-11990:
---

 Summary: DNS#reverseDns fails with a NumberFormatException when 
using an IPv6 DNS server
 Key: HADOOP-11990
 URL: https://issues.apache.org/jira/browse/HADOOP-11990
 Project: Hadoop Common
  Issue Type: Bug
  Components: net
Affects Versions: 2.5.1
 Environment: java version 1.7.0_45
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Reporter: Benoit Sigoure


With this resolv.conf:

{code}
nameserver 192.168.1.1
nameserver 2604:5500:3::3
nameserver 2604:5500:3:3::3
{code}

Starting HBase yields the following:

{code}
Caused by: java.lang.NumberFormatException: For input string: 5500:3::3
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at com.sun.jndi.dns.DnsClient.init(DnsClient.java:122)
at com.sun.jndi.dns.Resolver.init(Resolver.java:61)
at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:570)
at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:430)
at 
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231)
at 
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139)
at 
com.sun.jndi.toolkit.url.GenericURLDirContext.getAttributes(GenericURLDirContext.java:103)
at 
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
at org.apache.hadoop.net.DNS.reverseDns(DNS.java:84)
at org.apache.hadoop.net.DNS.getHosts(DNS.java:241)
at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:344)
at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:362)
at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:341)
at 
org.apache.hadoop.hbase.regionserver.RSRpcServices.getHostname(RSRpcServices.java:825)
at 
org.apache.hadoop.hbase.regionserver.RSRpcServices.init(RSRpcServices.java:782)
at 
org.apache.hadoop.hbase.master.MasterRpcServices.init(MasterRpcServices.java:195)
at 
org.apache.hadoop.hbase.master.HMaster.createRpcServices(HMaster.java:477)
at 
org.apache.hadoop.hbase.regionserver.HRegionServer.init(HRegionServer.java:492)
at org.apache.hadoop.hbase.master.HMaster.init(HMaster.java:333)
at 
org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.init(HMasterCommandLine.java:276)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at 
org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:139)
... 7 more
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HADOOP-11990) DNS#reverseDns fails with a NumberFormatException when using an IPv6 DNS server

2015-05-17 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14547549#comment-14547549
 ] 

Benoit Sigoure commented on HADOOP-11990:
-

No, that one is a bug related to splitting on dots, which was another issue.  I 
guess is issue more related to HADOOP-11890.

 DNS#reverseDns fails with a NumberFormatException when using an IPv6 DNS 
 server
 ---

 Key: HADOOP-11990
 URL: https://issues.apache.org/jira/browse/HADOOP-11990
 Project: Hadoop Common
  Issue Type: Bug
  Components: net
Affects Versions: 2.5.1
 Environment: java version 1.7.0_45
 Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
 Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Reporter: Benoit Sigoure

 With this resolv.conf:
 {code}
 nameserver 192.168.1.1
 nameserver 2604:5500:3::3
 nameserver 2604:5500:3:3::3
 {code}
 Starting HBase yields the following:
 {code}
 Caused by: java.lang.NumberFormatException: For input string: 5500:3::3
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 at java.lang.Integer.parseInt(Integer.java:492)
 at java.lang.Integer.parseInt(Integer.java:527)
 at com.sun.jndi.dns.DnsClient.init(DnsClient.java:122)
 at com.sun.jndi.dns.Resolver.init(Resolver.java:61)
 at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:570)
 at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:430)
 at 
 com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231)
 at 
 com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139)
 at 
 com.sun.jndi.toolkit.url.GenericURLDirContext.getAttributes(GenericURLDirContext.java:103)
 at 
 javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
 at org.apache.hadoop.net.DNS.reverseDns(DNS.java:84)
 at org.apache.hadoop.net.DNS.getHosts(DNS.java:241)
 at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:344)
 at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:362)
 at org.apache.hadoop.net.DNS.getDefaultHost(DNS.java:341)
 at 
 org.apache.hadoop.hbase.regionserver.RSRpcServices.getHostname(RSRpcServices.java:825)
 at 
 org.apache.hadoop.hbase.regionserver.RSRpcServices.init(RSRpcServices.java:782)
 at 
 org.apache.hadoop.hbase.master.MasterRpcServices.init(MasterRpcServices.java:195)
 at 
 org.apache.hadoop.hbase.master.HMaster.createRpcServices(HMaster.java:477)
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.init(HRegionServer.java:492)
 at org.apache.hadoop.hbase.master.HMaster.init(HMaster.java:333)
 at 
 org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.init(HMasterCommandLine.java:276)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at 
 org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:139)
 ... 7 more
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HADOOP-9944) RpcRequestHeaderProto defines callId as uint32 while ipc.Client.CONNECTION_CONTEXT_CALL_ID is signed (-3)

2013-10-31 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810371#comment-13810371
 ] 

Benoit Sigoure commented on HADOOP-9944:


!http://i.imgur.com/2ClmQri.gif!

Where to start... I don't even ...

Was there NO WAY you could have worked around this in your Java code?  Really?
Especially after having cut already 2 major releases with this code?

When will Hadoop finally grow up and provide guarantees both in terms of API 
compatibility and wire-level compatibility?

If you got the API wrong, well, too bad.  Live with it.  Don't fucking break it.

(ノಠ益ಠ)ノ彡┻━┻

 RpcRequestHeaderProto defines callId as uint32 while 
 ipc.Client.CONNECTION_CONTEXT_CALL_ID is signed (-3)
 -

 Key: HADOOP-9944
 URL: https://issues.apache.org/jira/browse/HADOOP-9944
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Arun C Murthy
Assignee: Arun C Murthy
Priority: Blocker
 Fix For: 2.1.1-beta

 Attachments: HADOOP-9944.patch, HADOOP-9944.patch, HADOOP-9944.patch


 RpcRequestHeaderProto defines callId as uint32 while 
 ipc.Client.CONNECTION_CONTEXT_CALL_ID is signed (-3).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HADOOP-7206) Integrate Snappy compression

2011-03-27 Thread Benoit Sigoure (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011893#comment-13011893
 ] 

Benoit Sigoure commented on HADOOP-7206:


Allen, I agree that situation with back-porting everything in Hadoop has gotten 
to a ridiculous point.  So while I understand and share your desire to stop 
back-porting things or splitting things out, you also have to understand the 
desire of users like us whose business greatly depends on Hadoop/HBase and 
where we need to move forward quickly.  If we were to wait until Apache 
releases a version of Hadoop we can use in production with HBase (proper 
append, no data loss, etc), we'd still be waiting.  So although I don't like 
the current situation with Hadoop either, I'm glad someone did the grungy work 
of back-porting things or splitting some things out so we could move forward.

What Todd is proposing is simply a way to make Snappy available quickly to 
users like us, and we'd be very happy about that.  I think it's in everyone's 
interest to make this available as soon as possible and not wait for a future 
Hadoop release.

Note: we're not Cloudera customers, but we use CDH because It Just Works.

 Integrate Snappy compression
 

 Key: HADOOP-7206
 URL: https://issues.apache.org/jira/browse/HADOOP-7206
 Project: Hadoop Common
  Issue Type: New Feature
Reporter: Eli Collins

 Google release Zippy as an open source (APLv2) project called Snappy 
 (http://code.google.com/p/snappy). This tracks integrating it into Hadoop.
 {quote}
 Snappy is a compression/decompression library. It does not aim for maximum 
 compression, or compatibility with any other compression library; instead, it 
 aims for very high speeds and reasonable compression. For instance, compared 
 to the fastest mode of zlib, Snappy is an order of magnitude faster for most 
 inputs, but the resulting compressed files are anywhere from 20% to 100% 
 bigger. On a single core of a Core i7 processor in 64-bit mode, Snappy 
 compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec 
 or more.
 {quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HADOOP-6504) Invalid example in the documentation of org.apache.hadoop.util.Tool

2010-02-26 Thread Benoit Sigoure (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HADOOP-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benoit Sigoure updated HADOOP-6504:
---

Status: Patch Available  (was: Open)

 Invalid example in the documentation of org.apache.hadoop.util.Tool
 ---

 Key: HADOOP-6504
 URL: https://issues.apache.org/jira/browse/HADOOP-6504
 Project: Hadoop Common
  Issue Type: Bug
  Components: documentation
Affects Versions: 0.20.1
Reporter: Benoit Sigoure
Priority: Trivial
 Attachments: HADOOP-6504.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The example with the class {{MyApp}} doesn't work.
 The {{run}} method needs to return an int ({{return 0;}} needs to be added at 
 the end of the method) and {{main}} does a {{new Sort()}} instead of {{new 
 MyApp()}}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (HADOOP-6504) Invalid example in the documentation of org.apache.hadoop.util.Tool

2010-01-21 Thread Benoit Sigoure (JIRA) 
Invalid example in the documentation of org.apache.hadoop.util.Tool
---

 Key: HADOOP-6504
 URL: https://issues.apache.org/jira/browse/HADOOP-6504
 Project: Hadoop Common
  Issue Type: Bug
  Components: documentation
Affects Versions: 0.20.1
Reporter: Benoit Sigoure


The example with the class {{MyApp}} doesn't work.
The {{run}} method needs to return an int ({{return 0;}} needs to be added at 
the end of the method) and {{main}} does a {{new Sort()}} instead of {{new 
MyApp()}}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (HADOOP-6504) Invalid example in the documentation of org.apache.hadoop.util.Tool

2010-01-21 Thread Benoit Sigoure (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HADOOP-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benoit Sigoure updated HADOOP-6504:
---

Priority: Trivial  (was: Major)

 Invalid example in the documentation of org.apache.hadoop.util.Tool
 ---

 Key: HADOOP-6504
 URL: https://issues.apache.org/jira/browse/HADOOP-6504
 Project: Hadoop Common
  Issue Type: Bug
  Components: documentation
Affects Versions: 0.20.1
Reporter: Benoit Sigoure
Priority: Trivial
   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The example with the class {{MyApp}} doesn't work.
 The {{run}} method needs to return an int ({{return 0;}} needs to be added at 
 the end of the method) and {{main}} does a {{new Sort()}} instead of {{new 
 MyApp()}}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.