On 16 December 2014 at 16:01, malcolm wrote:
> 1. Findbugs , 3 warnings in Java code (which of course I did not touch)
> 2. Test failures also with no connection to terror: A java socket timeout,
>
ongoing issues with (1) transition to java 7 builds and (2) some
intermittent tests that need to g
On 12/16/2014 11:01 AM, malcolm wrote:
This is weird, Jenkins complains about:
1. Findbugs , 3 warnings in Java code (which of course I did not touch)
The FB warnings seem to be a recent phenomenon. I have seen them on a
recent test run of my own and they come and go depending on the run. I
fter the call to strerror(). Please check the code snippet I sent
earlier
for HPUX.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Saturday, December 13, 2014 3:13 PM
To: common-dev@hadoop.apache.org
Subject: Re: Solaris Port SOLVED!
Wiping
lier
for HPUX.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Saturday, December 13, 2014 3:13 PM
To: common-dev@hadoop.apache.org
Subject: Re: Solaris Port SOLVED!
Wiping egg off face ...
After consulting with the Solaris team (and looking at the
r() is a valid one. For this you need to check errno
>> after the call to strerror(). Please check the code snippet I sent earlier
>> for HPUX.
>>
>> -- Asokan
>>
>> From: malcolm [malcolm.kaval...@oracle.com
On 14 December 2014 at 16:52, Allen Wittenauer wrote:
> Well, slight correction: only one thing in the code that has been
> replaced. There are a two patches waiting to get reviewed and applied that
> fix the rest of the shipping shell code: HADOOP-10788 and HADOOP-11346.
> HDFS-7460 is waiting
On Dec 14, 2014, at 8:38 AM, Allen Wittenauer wrote:
>
> On Dec 13, 2014, at 4:05 AM, Steve Loughran wrote:
>>
>> The shell scripts are also undertested and only intermittently maintained
>> —there's been recent work there in HADOOP-9902(?) which is a great
>> improvement to trunk. If you ca
On Dec 13, 2014, at 4:05 AM, Steve Loughran wrote:
>
> The shell scripts are also undertested and only intermittently maintained
> —there's been recent work there in HADOOP-9902(?) which is a great
> improvement to trunk. If you can help test the CLI on your OS, that will
> save you support cal
he code snippet I sent earlier for HPUX.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Saturday, December 13, 2014 3:13 PM
To: common-dev@hadoop.apache.org
Subject: Re: Solaris Port SOLVED!
Wiping egg off face ...
After consulting with the So
sent earlier for HPUX.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Saturday, December 13, 2014 3:13 PM
To: common-dev@hadoop.apache.org
Subject: Re: Solaris Port SOLVED!
Wiping egg off face ...
After consulting with the Solaris team (and lo
atMessageW (which returns messages in Unicode.) My requirement
was to
return messages in current system locale.
-- Asokan
From: malcolm
[malcolm.kaval...@oracle.com<mailto:malcolm.kaval...@oracle.com>]
Sent: Thursday, December 11, 2014 4:04 PM
To:common-
On 13 December 2014 at 09:29, malcolm wrote:
> I am not sure what you mean by a thread-local buffer (in native code). In
> Java this is pretty standard, but I couldn't find any implementation for C
> code.
There's stuff around; I don't know how well it works across different
platforms; certainl
t uses
FormatMessageW (which returns messages in Unicode.) My requirement was to
return messages in current system locale.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com<mailto:malcolm.kaval...@oracle.com>]
Sent: Thursday, December 11, 2014 4:04 PM
m.kaval...@oracle.com<mailto:malcolm.kaval...@oracle.com>]
Sent: Thursday, December 11, 2014 4:04 PM
To:common-dev@hadoop.apache.org<mailto:To:common-dev@hadoop.apache.org>
Subject: Re: Solaris Port
Hi Asok,
I googled and found that windows has strerror, and strerror_s (which is
the stre
On 12 December 2014 at 04:35, malcolm wrote:
> So, turns out that if I had naively changed all calls to terror or
> references to sys_errlist, to using strerror_r, then I would have broken
> code for Windows and HPUX (and possibly other OSes).
>
> If we are to assume that current code runs fine o
malcolm [malcolm.kaval...@oracle.com]
Sent: Thursday, December 11, 2014 4:04 PM
To:common-dev@hadoop.apache.org
Subject: Re: Solaris Port
Hi Asok,
I googled and found that windows has strerror, and strerror_s (which is
the strerror_r equivalent).
Is there a reason why you didn't use this call ?
essages in current system locale.
>>
>> -- Asokan
>> ________
>> From: malcolm [malcolm.kaval...@oracle.com]
>> Sent: Thursday, December 11, 2014 4:04 PM
>> To: common-dev@hadoop.apache.org
>> Subject: Re: Solaris Port
>>
>&
, December 11, 2014 4:04 PM
To: common-dev@hadoop.apache.org
Subject: Re: Solaris Port
Hi Asok,
I googled and found that windows has strerror, and strerror_s (which is
the strerror_r equivalent).
Is there a reason why you didn't use this call ?
On 12/11/2014 06:27 PM, Asokan, M wr
ent was to
return messages in current system locale.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Thursday, December 11, 2014 4:04 PM
To: common-dev@hadoop.apache.org
Subject: Re: Solaris Port
Hi Asok,
I googled and found that windows has str
Also Windows does not have snprintf(). The equivalent function
_snprintf() has a subtle difference in its interface.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Thursday, December 11, 2014 11:02 AM
To: common-dev@hadoop.apache.org
Subject:
or_r() since strerror() itself is
thread-safe. Also Windows does not have snprintf(). The equivalent function
_snprintf() has a subtle difference in its interface.
-- Asokan
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Thursday, December 11, 2014 11:02 AM
To
Fine with me, I volunteer to do this, if accepted.
On 12/11/2014 05:48 PM, Allen Wittenauer wrote:
sys_errlist was removed for a reason. Creating a fake sys_errlist on Solaris
will mean the libhadoop.so will need to be tied a specific build
(kernel/include pairing) and therefore limits upward
sys_errlist was removed for a reason. Creating a fake sys_errlist on Solaris
will mean the libhadoop.so will need to be tied a specific build
(kernel/include pairing) and therefore limits upward mobility/compatibility.
That doesn’t seem like a very good idea.
IMO, switching to strerror_r i
FYI, there are a couple more files that reference sys_errlist directly
(not just terror within exception.c) , but also hdfs_http_client.c and
NativeiO.c
On 12/11/2014 07:38 AM, malcolm wrote:
Hi Colin,
Exactly, as you noticed, the problem is the thread-local buffer needed
to return from terr
Hi Colin,
Exactly, as you noticed, the problem is the thread-local buffer needed
to return from terror.
Currently, terror just returns a static string from an array, this is
fast, simple and error-proof.
In order to use strerror_r inside terror, would require allocating a
buffer inside terr
On Wed, Dec 10, 2014 at 2:31 AM, malcolm wrote:
> Hi Colin,
>
> Thanks for the hints around JIRAs.
>
> You are correct errno still exists, however sys_errlist does not.
>
> Hadoop uses a function terror (defined in exception.c) which indexes
> sys_errlist by errno to return the error message from
On 10 December 2014 at 10:31, malcolm wrote:
> Also, I have been requested to ensure my port is available on 2.4,
> perceived as a more stable release. If I make changes to this branch are
> they automatically available for 2.6, or will I need multiple JIRAs ?
nobody is backporting patches to A
Hi Colin,
Thanks for the hints around JIRAs.
You are correct errno still exists, however sys_errlist does not.
Hadoop uses a function terror (defined in exception.c) which indexes
sys_errlist by errno to return the error message from the array. This
function is called 26 times in various plac
Hi Malcolm,
In general we file JIRAs for particular issues. So if one issue is
handling errlist on Solaris, that might be one JIRA. Another issue
might be handling socket write timeouts on Solaris. And so on. Most
of these should probably be HADOOP tickets since they sound like they
are mostly
Hi Colin,
A short summary of my changes are as follows:
- Native C source files: added 5, modified 6, requiring also changes to
CMakeLists.txt. Of course, all changes are "ifdeffed" for Solaris
appropriately and new files, are prefixed with solaris_ as well.
For example, Solaris does not ha
Hi Malcolm,
It's great that you are going to contribute! Please make your patches
against trunk.
2.2 is fairly old at this point. It hasn't been the focus of
development in more than a year.
We don't use github or pull requests.
Check the section on http://wiki.apache.org/hadoop/HowToContribu
I have ported Hadoop native libraries to Solaris 11 (both Sparc and Intel )
Oracle have agreed to release my changes to the community so that
Solaris platforms can benefit.
Reading the HowToContribute and GitandHadoop documents, I am not 100%
clear on how to get my changes into the main tree. I
32 matches
Mail list logo
