Malcolm Taylor created HADOOP-16556:
---
Summary: Fix some LGTM alerts
Key: HADOOP-16556
URL: https://issues.apache.org/jira/browse/HADOOP-16556
Project: Hadoop Common
Issue Type: Improvement
Hi Prabhu,
Sorry for the delayed response; it actually was the
maximum-allocation-vcores setting. I interpreted the description for
maximum-allocation-vcores as the per-container setting, when it actually
seems to be the full allocation across the cluster.
Cheers,
Malcolm
On Tue, Apr 2, 2019 at
cation-mb=256
yarn.scheduler.maximum-allocation-mb=16384
yarn.scheduler.minimum-allocation-vcores=1
yarn.scheduler.maximum-allocation-vcores=16
Thanks for the help,
Malcolm
--
Malcolm McFarland
Cavulus
[
https://issues.apache.org/jira/browse/HADOOP-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Malcolm Kavalsky resolved HADOOP-11655.
---
Resolution: Fixed
Release Note: Updating Solaris 11.2 to the latest SRU ( 17th
Malcolm Kavalsky created HADOOP-11954:
-
Summary: Solaris does not support RLIMIT_MEMLOCK as in Linux
Key: HADOOP-11954
URL: https://issues.apache.org/jira/browse/HADOOP-11954
Project: Hadoop
Malcolm Kavalsky created HADOOP-11953:
-
Summary: Binary flags for NativeIO incorrect on Solaris
Key: HADOOP-11953
URL: https://issues.apache.org/jira/browse/HADOOP-11953
Project: Hadoop Common
Malcolm Kavalsky created HADOOP-11952:
-
Summary: Native compilation on Solaris fails on Yarn due to use of
FTS
Key: HADOOP-11952
URL: https://issues.apache.org/jira/browse/HADOOP-11952
Project
Malcolm Kavalsky created HADOOP-11848:
-
Summary: Incorrect arguments to sizeof in DomainSocket.c
Key: HADOOP-11848
URL: https://issues.apache.org/jira/browse/HADOOP-11848
Project: Hadoop Common
Malcolm Kavalsky created HADOOP-11655:
-
Summary: Native compilation fails on Solaris due to use of
getgrouplist function.
Key: HADOOP-11655
URL: https://issues.apache.org/jira/browse/HADOOP-11655
Malcolm Kavalsky created HADOOP-11623:
-
Summary: Native compilation fails on Solaris due to use of syscall
function.
Key: HADOOP-11623
URL: https://issues.apache.org/jira/browse/HADOOP-11623
the same errors
anyway.)
On 12/16/2014 06:57 AM, malcolm wrote:
Done, and added the comment as you requested.
I attached a second patch file to the JIRA (with .002 appended as per
convention) assuming Jenkins knows to take the latest version, since I
understand that I cannot remove the
:
Thanks, Malcom. I reviewed it. The only thing you still have to do
is hit "submit patch" to get a Jenkins run. See our HowToContribute
wiki page for more details.
wiki.apache.org/hadoop/HowToContribute
best,
Colin
On Sat, Dec 13, 2014 at 9:22 PM, malcolm wrote:
I am checking on
olaris and Linux (though my changes only affect Solaris
platforms).
JIRA newbie question:
I have filed the JIRA attaching the patch HADOOP-11403 against the
trunk, asking for reviewers in the comments section.
Is there any other protocol I should follow ?
Thanks,
Malcolm
On 12/14/2014 01:08 AM,
Malcolm Kavalsky created HADOOP-11403:
-
Summary: Solaris does not support sys_errlist requires use of
strerror instead
Key: HADOOP-11403
URL: https://issues.apache.org/jira/browse/HADOOP-11403
st is referenced directly
(NativeIO and hdfs_http_client.c), I replaced this direct access instead
with a call to terror.
Thanks for all your help and patience,
I'll file a JIRA asap,
Cheers,
Malcolm
On 12/13/2014 05:26 PM, malcolm wrote:
Thanks Asokan,
Looked up Gcc's thread local vari
. The more I
think about it, the more this seems to be the right thing to do.
Cheers,
Malcolm
On 12/13/2014 04:38 PM, Asokan, M wrote:
Malcom,
Gcc supports thread-local variables. See
https://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html
I am not sure about native compilers on So
.
If this is OK with you, I will open a jira for this.
Thanks,
Malcolm
On 12/12/2014 11:10 PM, Colin McCabe wrote:
Just use snprintf to copy the error message from strerror_r into a
thread-local buffer of 64 bytes or so. Then preserve the existing
terror() interface.
Can you open a jira
code.
You could probably look at libwinutils.c in Hadoop source. It uses
FormatMessageW (which returns messages in Unicode.) My requirement was to
return messages in current system locale.
-- Asokan
____
From: malcolm [malcolm.kaval...@oracle.com]
Sent: Thursday
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:
upward mobility/compatibility.
That doesn’t seem like a very good idea.
IMO, switching to strerror_r is much preferred, since other than the brain-dead
GNU libc version, is highly portable and should work regardless of the kernel
or OS in place.
On Dec 11, 2014, at 5:20 AM, malcolm wrote:
FYI
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
thing else, so I leave
you to make the call.
Thanks for your patience,
Malcolm
On 12/10/2014 09:54 PM, Colin McCabe wrote:
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.
H
h are
they automatically available for 2.6, or will I need multiple JIRAs ?
Thanks,
Malcolm
On 12/10/2014 10:45 AM, Colin McCabe wrote:
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 han
ngle patch file with all changes. Perhaps it would
be better to file multiple JIRAs for each change, perhaps grouped, one
per issue ? Or should I file a JIRA for each modified source file ?
Thank you,
Malcolm
On 12/08/2014 09:53 PM, Colin McCabe wrote:
Hi Malcolm,
It's great that yo
understanding that I need to
generate a Jira number for my changes, and to name my branch accordingly ?
Does all this make sense ?
Thanks,
Malcolm
Linux version.
BTW, even on 2.2, not all tests passed successfully ( on Ubuntu 12.04).
Thanks,
Malcolm
Extract from the test log (running with -fae flag to keep going):
Failed tests:
TestSymlinkLocalFSFileContext>SymlinkBaseTest.testStatLinkToFile:244 null
TestSymlinkLocalFSFileCont
i.e.
who to send the changes to, for example.
Thanks,
Malcolm
27 matches
Mail list logo
