user object in the subject in UGI should be reused in case of a relogin.
-
Key: HADOOP-6687
URL: https://issues.apache.org/jira/browse/HADOOP-6687
Project: Hadoop Common
Remove redundant exception class name in unwrapped exceptions thrown at the RPC
client
--
Key: HADOOP-6686
URL: https://issues.apache.org/jira/browse/HADOOP-6686
Proj
> We've long-delayed declaring 1.0 because we were afraid to commit to
> supporting a given API for a longer term. Now folks are willing to make
> that long-term commitment to an API, yet seem reluctant to call it 1.0.
The commitment is to the new APIs. "Folks" are reluctant to cut a
release with
Allen Wittenauer wrote:
My main point was that suddenly people seem to be hot to declare something 1.0.
I'm trying to understand why [...]
My rationale for suggesting a release named 1.0 was that I prefer that
release numbers say something about compatibility. The compatibility
rules we've
Change the generic serialization framework API to use serialization-specific
bytes instead of Map for configuration
--
Key: HADOOP-6685
Create a wrapper for TFile that handles generic serialization
-
Key: HADOOP-6684
URL: https://issues.apache.org/jira/browse/HADOOP-6684
Project: Hadoop Common
Issue Type: New Featur
Todd Lipcon wrote:
I was seeing errors in 18 without escape analysis explicitly enabled. So
unless it became enabled by default in 18, I don't think that was the issue.
That's not good. The security fixes in this JVM do hint it's something
to deploy sooner rather than later.
http://isc.sans.
On Apr 6, 2010, at 6:02 AM, Steve Loughran wrote:
> Allen Wittenauer wrote:
>> On Apr 5, 2010, at 5:06 PM, Chris K Wensel wrote:
>>> we need a well healed 1.0 sooner than later.
>> Why?
>
> I think it would be good for a 0.21 with the newly renamed artifacts
> hadoop-common, hadoop-hdfs and had
I was seeing errors in 18 without escape analysis explicitly enabled. So
unless it became enabled by default in 18, I don't think that was the issue.
-Todd
On Tue, Apr 6, 2010 at 5:48 AM, Steve Loughran wrote:
>
> I know everyone has had bad experiences w/ Java 1.6.0_18 and was sticking
> with
Drew Farris wrote:
On Fri, Apr 2, 2010 at 8:23 AM, Enis Söztutar wrote:
.Do we have any build-specific reason that cannot be done with ivy.
It can be done with ivy, but it's generally far more manageable to do
everything with maven because there is considerably less configuration
required. Le
Allen Wittenauer wrote:
On Apr 5, 2010, at 5:06 PM, Chris K Wensel wrote:
we need a well healed 1.0 sooner than later.
Why?
I think it would be good for a 0.21 with the newly renamed artifacts
hadoop-common, hadoop-hdfs and hadoop-mapred out there; I think the new
APIs should be made av
Chris Douglas wrote:
Thus far the changes suggested for a 1.0 branch are:
- de-deprecate "classic" mapred APIs (no Jira issue yet)
Why? Tom and Owen's proposal preserves compatibility with the
deprecated FileSystem and mapred APIs up to 1.0. After Tom cuts a
release- from either the 0.21 branc
I know everyone has had bad experiences w/ Java 1.6.0_18 and was
sticking with JVM releases they trusted, but the set of security patches
that have come out with the _19 release change the situation. There are
enough server-side vulnerabilities there to make upgrading something to
consider if
13 matches
Mail list logo
