FYI - I created the RC3 a few days ago. So abandoning RC2. Hopefully we
won't find any issues there.
Thanks
Mukund
On Tue, Oct 8, 2024 at 11:46 PM Steve Loughran
wrote:
> On Sat, 5 Oct 2024 at 01:58, Wei-Chiu Chuang wrote:
>
> > Hey the 3.4.1 tarball is a whopping 929MB! The corresponding dock
On Sat, 5 Oct 2024 at 01:58, Wei-Chiu Chuang wrote:
> Hey the 3.4.1 tarball is a whopping 929MB! The corresponding docker image
> is over 1.1GB. Not that long ago, 3.2.3 was less than 500MB 2 years ago.
> 3.3.6 was less than 700MB a year ago.
> That AWS SDK v2 jar itself is more than 500MB.
>
fo
This is a real problem with that aWS SDK, but it is that or field support
calls forever.
Let me see if I can revisit my idea of having the release support project
produce a "lean" edition where we delete that bundle.jar
On Sat, 5 Oct 2024 at 01:58, Wei-Chiu Chuang wrote:
> Hey the 3.4.1 tarball
Sent: Wednesday, September 25, 2024 9:13:48 PM
To: Hadoop Common
Subject: [EXTERNAL] [VOTE] Release Apache Hadoop 3.4.1 RC2
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
A
Hey the 3.4.1 tarball is a whopping 929MB! The corresponding docker image
is over 1.1GB. Not that long ago, 3.2.3 was less than 500MB 2 years ago.
3.3.6 was less than 700MB a year ago.
That AWS SDK v2 jar itself is more than 500MB.
One issue I found with Ozone is protobuf classpath.
this test is
TL;DR I think the 3.4.1 RC2 is okay from an Ozone's perspective. Most of
the issues were introduced in 3.4.0 and not too terrible.
I am planning to introduce Hadoop 3.4.0 for Ozone 2.0 so incompatibilities
are acceptable.
Thanks for the tips.
Yes I had to bump the hadoop-thirdparty version as wel
I hope the following information will be helpful.
>From the perspective of compilation, Hadoop on JDK17 currently doesn’t face
many obstacles.
The code on the trunk branch can already be compiled directly on JDK17.
I will verify the situation for hadoop-3.4.1 and then provide feedback.
If we wa
you using the hadoop thirdparty jar? there is a 1.3.0 release out
On Wed, 2 Oct 2024 at 17:01, Wei-Chiu Chuang wrote:
> HBase project is adding support for Hadoop 3.4.0, and I had to add a few
> changes on top of that to let HBase shading to pass (license issues due to
> transitive dependencies
HBase project is adding support for Hadoop 3.4.0, and I had to add a few
changes on top of that to let HBase shading to pass (license issues due to
transitive dependencies and so on). Those are quite common when updating to
a new Hadoop version.
But apart from that it builds and unit tests passed
Please do!
On Tue, 1 Oct 2024 at 20:54, Wei-Chiu Chuang wrote:
> Hi I'm late to the party, but I'd like to build and test this release with
> Ozone and HBase.
>
> On Tue, Oct 1, 2024 at 2:12 AM Mukund Madhav Thakur
> wrote:
>
> > Thanks @Dongjoon Hyun for trying out the RC
> and
> > finding ou
Hi I'm late to the party, but I'd like to build and test this release with
Ozone and HBase.
On Tue, Oct 1, 2024 at 2:12 AM Mukund Madhav Thakur
wrote:
> Thanks @Dongjoon Hyun for trying out the RC and
> finding out this bug. This has to be fixed.
> It would be great if others can give the RC a
Thanks @Dongjoon Hyun for trying out the RC and
finding out this bug. This has to be fixed.
It would be great if others can give the RC a try such that we know of any
issues earlier.
Thanks
Mukund
On Tue, Oct 1, 2024 at 2:21 AM Steve Loughran
wrote:
> ok, we will have to consider that a -1
>
>
>
>
> > Do you think we can have an option to handle the overlapping ranges in
> Hadoop layer instead of introducing a breaking change to the users at the
> maintenance release?
>
>
On this one. We decided that we won't support overlapping ranges in
Vectored IO as that will cause complexity in memo
ok, we will have to consider that a -1
Interestingly we haven't seen that on any of our internal QE, maybe none of
the requests weren't overlapping.
I was just looking towards an =0 because of
https://issues.apache.org/jira/browse/HADOOP-19295
*Unlike the v1 sdk, PUT/POST of data now shares the
Unfortunately, it turns out to be a regression in addition to a breaking change.
In short, HADOOP-19098 (or more) makes Hadoop 3.4.1 fails even when users give
disjoint ranges.
I filed a Hadoop JIRA issue and a PR. Please take a look at that.
- HADOOP-19291. `CombinedFileRange.merge` should not
Thank you for 3.4.1 RC2.
HADOOP-19098 (Vector IO: consistent specified rejection of overlapping ranges)
seems to be a hard breaking change at 3.4.1.
Do you think we can have an option to handle the overlapping ranges in Hadoop
layer instead of introducing a breaking change to the users at the m
Apache Hadoop 3.4.1
With help from Steve I have put together a release candidate (RC2) for
Hadoop 3.4.1.
What we would like is for anyone who can to verify the tarballs, especially
anyone who can try the arm64 binaries as we want to include them too.
The RC is available at:
https://dist.apa
17 matches
Mail list logo
