[
https://issues.apache.org/jira/browse/HDFS-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325149#comment-14325149
]
Colin Patrick McCabe commented on HDFS-7188:
--------------------------------------------
{code}
if (syscalls::getpeername(sock, &peer,
reinterpret_cast<int*>(&len))) {
{code}
This seems a bit concerning. How do we know that {{int}} is the same length as
{{socklen_t}}? Why don't we just change the variable to be of type
{{socklen_t}}?
{code}
49 #ifdef _WIN32
50 memcpy(&clientId[0], &id, sizeof(uuid_t));
51 #else
52 memcpy(&clientId[0], id, sizeof(uuid_t));
53 #endif
{code}
I didn't look into this closely. Why is this necessary? Are we even using
libuuid on Windows? I almost think we should just drop the libuuid dependency
either way, since it's basically just putting a random number into a 128-bit
number... not exactly a very difficult thing to code (aside from the usual
issues with getting good random numbers in C)
{{GetInitNamenodeIndex}}: I realize your patch didn't add this function. But I
still haven't figured out what the heck this is doing in the client. The Java
client doesn't do anything with files under /tmp to determine which NN to
contact first... it just gets it from the configuration. I'd prefer to just do
what the Java client is doing here rather than implement this for N different
OSes (although maybe we should have a follow-on JIRA). Same with
StackPrinter.cc...
> support build libhdfs3 on windows
> ---------------------------------
>
> Key: HDFS-7188
> URL: https://issues.apache.org/jira/browse/HDFS-7188
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Environment: Windows System, Visual Studio 2010
> Reporter: Zhanwei Wang
> Assignee: Thanh Do
> Attachments: HDFS-7188-branch-HDFS-6994-0.patch,
> HDFS-7188-branch-HDFS-6994-1.patch, HDFS-7188-branch-HDFS-6994-2.patch
>
>
> libhdfs3 should work on windows
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
