Re: Different JIRA permissions for HADOOP and HDFS

[Akira AJISAKA]

I'm doing the following steps to reduce the number of contributors:

1. Find committers who have only contributor role
2. Add them into committer role
3. Remove them from contributor role

However, this is a temporary solution.
Probably we need to do one of the followings in the near future.

* Create contributor2 role to increase the limit
* Remove contributors who have not been active for a long time

Regards,
Akira

On 6/18/16 10:24, Zheng, Kai wrote:

Hi Akira,

Some contributors (not committer) I know were found lost and we can't assign 
tasks to. Any way I can add them or have to trouble others for that each time 
when there is a new one? Thanks!

Regards,
Kai

-Original Message-
From: Akira AJISAKA [mailto:ajisa...@oss.nttdata.co.jp]
Sent: Monday, June 06, 2016 12:47 AM
To: common-dev@hadoop.apache.org
Subject: Re: Different JIRA permissions for HADOOP and HDFS

Now I can't add any more contributors in HADOOP Common, so I'll remove the 
contributors who have committers role to make the group smaller.
Please tell me if you have lost your roles by mistake.

Regards,
Akira

On 5/18/16 13:48, Akira AJISAKA wrote:

In HADOOP/HDFS/MAPREDUCE/YARN, I removed the administrators from
contributor group. After that, added Varun into contributor roles.
# Ray is already added into contributor roles.

Hi contributors/committers, please tell me if you have lost your roles
by mistake.


just remove a big chunk of the committers from all the lists

In Apache Hadoop Project bylaws, "A Committer is considered emeritus
by their own declaration or by not contributing in any form to the
project for over six months." Therefore we can remove them from the
list, but I'm thinking this is the last option.

Regards,
Akira

On 5/18/16 09:07, Allen Wittenauer wrote:


We should probably just remove a big chunk of the committers from all
the lists.  Most of them have disappeared from Hadoop anyway.  (The
55% growth in JIRA issues in patch available state in the past year
alone a pretty good testament to that fact.)


On May 17, 2016, at 4:40 PM, Akira Ajisaka  wrote:


Is there some way for us to add a "Contributors2" group with the
same permissions as a workaround?  Or we could try to clean out
contributors who are no longer active, but that might be hard to figure out.


Contributors2 seems fine. AFAIK, committers sometimes cleaned out
contributors who are no longer active.
http://search-hadoop.com/m/uOzYt77s6mnzcRu1/v=threaded

Another option: Can we remove committers from contributor group to
reduce the number of contributors? I've already removed myself from
contributor group and it works well.

Regards,
Akira

On 5/18/16 03:16, Robert Kanter wrote:

We've also had a related long-standing issue (or at least I have)
where I can't add any more contributors to HADOOP or HDFS because
JIRA times out on looking up their username.  I'm guessing we have
too many contributors for those projects.  I bet YARN and MAPREDUCE are close.
Is there some way for us to add a "Contributors2" group with the
same permissions as a workaround?  Or we could try to clean out
contributors who are no longer active, but that might be hard to figure out.

- Robert

On Tue, May 17, 2016 at 11:12 AM, Ray Chiang mailto:rchi...@cloudera.com>> wrote:

   Similar issue for me.  I can't modify HDFS and HADOOP JIRAs now.

   -Ray


   On Tue, May 17, 2016 at 9:54 AM, Varun Saxena
   mailto:vsaxena.va...@gmail.com>>
   wrote:

   > Hi,
   >
   > I do not have permissions for any project other than YARN as well.
   Unable
   > to assign a JIRA in MAPREDUCE for instance.
   > Can somebody give me permission ?
   >
   > Regards,
   > Varun Saxena.
   >
   >
   > On Tue, May 17, 2016 at 11:03 AM, Vinayakumar B <
   > vinayakumarb.apa...@gmail.com
   > wrote:
   >
   > > Thanks Akira.
   > > On 17 May 2016 10:59, "Akira Ajisaka" mailto:aajis...@apache.org>> wrote:
   > >
   > > > Hi Vinay,
   > > >
   > > > Added you into committer roles for HADOOP/MAPREDUCE/YARN.
   > > >
   > > > Regards,
   > > > Akira
   > > >
   > > > On 5/17/16 13:45, Vinayakumar B wrote:
   > > >
   > > >> Hi Junping,
   > > >>
   > > >> It looks like, I too dont have permissions in projects except
   HDFS.
   > > >>
   > > >> Please grant me also to the group.
   > > >>
   > > >> Thanks in advance,
   > > >> -Vinay
   > > >> On 17 May 2016 6:10 a.m., "Sangjin Lee" mailto:sj...@apache.org>> wrote:
   > > >>
   > > >> Thanks Junping! It seems to work now.
   > > >>
   > > >> On Mon, May 16, 2016 at 5:22 PM, Junping Du
   mailto:j...@hortonworks.com>>
   > > wrote:
   > > >>
   > > >> Someone fix the permission issue so that Administrator,
   committer and
   > > >>> reporter can edit the issue now.
   > > >>>
   > > >>> Sangjin, it sounds like you were not in JIRA's committer
   list before
   > > and
   > > >>> I
   > > >>> just add you into committer roles for 4 projects. Hope it
   works for
   > > >>> you now.​
   > > >>>
   > > >>>
   > > >>> Th

RE: Different JIRA permissions for HADOOP and HDFS

[Zheng, Kai]

Hi Akira,

Some contributors (not committer) I know were found lost and we can't assign 
tasks to. Any way I can add them or have to trouble others for that each time 
when there is a new one? Thanks!

Regards,
Kai

-Original Message-
From: Akira AJISAKA [mailto:ajisa...@oss.nttdata.co.jp] 
Sent: Monday, June 06, 2016 12:47 AM
To: common-dev@hadoop.apache.org
Subject: Re: Different JIRA permissions for HADOOP and HDFS

Now I can't add any more contributors in HADOOP Common, so I'll remove the 
contributors who have committers role to make the group smaller.
Please tell me if you have lost your roles by mistake.

Regards,
Akira

On 5/18/16 13:48, Akira AJISAKA wrote:
> In HADOOP/HDFS/MAPREDUCE/YARN, I removed the administrators from 
> contributor group. After that, added Varun into contributor roles.
> # Ray is already added into contributor roles.
>
> Hi contributors/committers, please tell me if you have lost your roles 
> by mistake.
>
>> just remove a big chunk of the committers from all the lists
> In Apache Hadoop Project bylaws, "A Committer is considered emeritus 
> by their own declaration or by not contributing in any form to the 
> project for over six months." Therefore we can remove them from the 
> list, but I'm thinking this is the last option.
>
> Regards,
> Akira
>
> On 5/18/16 09:07, Allen Wittenauer wrote:
>>
>> We should probably just remove a big chunk of the committers from all 
>> the lists.  Most of them have disappeared from Hadoop anyway.  (The 
>> 55% growth in JIRA issues in patch available state in the past year 
>> alone a pretty good testament to that fact.)
>>
>>> On May 17, 2016, at 4:40 PM, Akira Ajisaka  wrote:
>>>
 Is there some way for us to add a "Contributors2" group with the 
 same permissions as a workaround?  Or we could try to clean out 
 contributors who are no longer active, but that might be hard to figure 
 out.
>>>
>>> Contributors2 seems fine. AFAIK, committers sometimes cleaned out 
>>> contributors who are no longer active.
>>> http://search-hadoop.com/m/uOzYt77s6mnzcRu1/v=threaded
>>>
>>> Another option: Can we remove committers from contributor group to 
>>> reduce the number of contributors? I've already removed myself from 
>>> contributor group and it works well.
>>>
>>> Regards,
>>> Akira
>>>
>>> On 5/18/16 03:16, Robert Kanter wrote:
 We've also had a related long-standing issue (or at least I have) 
 where I can't add any more contributors to HADOOP or HDFS because 
 JIRA times out on looking up their username.  I'm guessing we have 
 too many contributors for those projects.  I bet YARN and MAPREDUCE are 
 close.
 Is there some way for us to add a "Contributors2" group with the 
 same permissions as a workaround?  Or we could try to clean out 
 contributors who are no longer active, but that might be hard to figure 
 out.

 - Robert

 On Tue, May 17, 2016 at 11:12 AM, Ray Chiang >>> > wrote:

Similar issue for me.  I can't modify HDFS and HADOOP JIRAs now.

-Ray


On Tue, May 17, 2016 at 9:54 AM, Varun Saxena
mailto:vsaxena.va...@gmail.com>>
wrote:

> Hi,
>
> I do not have permissions for any project other than YARN as well.
Unable
> to assign a JIRA in MAPREDUCE for instance.
> Can somebody give me permission ?
>
> Regards,
> Varun Saxena.
>
>
> On Tue, May 17, 2016 at 11:03 AM, Vinayakumar B <
> vinayakumarb.apa...@gmail.com
> wrote:
>
> > Thanks Akira.
> > On 17 May 2016 10:59, "Akira Ajisaka" >>>> wrote:
> >
> > > Hi Vinay,
> > >
> > > Added you into committer roles for HADOOP/MAPREDUCE/YARN.
> > >
> > > Regards,
> > > Akira
> > >
> > > On 5/17/16 13:45, Vinayakumar B wrote:
> > >
> > >> Hi Junping,
> > >>
> > >> It looks like, I too dont have permissions in projects except
HDFS.
> > >>
> > >> Please grant me also to the group.
> > >>
> > >> Thanks in advance,
> > >> -Vinay
> > >> On 17 May 2016 6:10 a.m., "Sangjin Lee" >>>> wrote:
> > >>
> > >> Thanks Junping! It seems to work now.
> > >>
> > >> On Mon, May 16, 2016 at 5:22 PM, Junping Du
mailto:j...@hortonworks.com>>
> > wrote:
> > >>
> > >> Someone fix the permission issue so that Administrator,
committer and
> > >>> reporter can edit the issue now.
> > >>>
> > >>> Sangjin, it sounds like you were not in JIRA's committer
list before
> > and
> > >>> I
> > >>> just add you into committer roles for 4 projects. Hope it

[jira] [Created] (HADOOP-13290) Appropriate use of generics in FairCallQueue

[Konstantin Shvachko (JIRA)]

Konstantin Shvachko created HADOOP-13290:


 Summary: Appropriate use of generics in FairCallQueue
 Key: HADOOP-13290
 URL: https://issues.apache.org/jira/browse/HADOOP-13290
 Project: Hadoop Common
  Issue Type: Bug
  Components: ipc
Affects Versions: 2.6.0
Reporter: Konstantin Shvachko


# {{BlockingQueue}} is intermittently used with and without generic parameters 
in {{FairCallQueue}} class. Should be parameterized.
# Same for {{FairCallQueue}}. Should be parameterized. Could be a bit more 
tricky for that one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[jira] [Created] (HADOOP-13289) Remove unused variables in TestFairCallQueue

[Konstantin Shvachko (JIRA)]

Konstantin Shvachko created HADOOP-13289:


 Summary: Remove unused variables in TestFairCallQueue
 Key: HADOOP-13289
 URL: https://issues.apache.org/jira/browse/HADOOP-13289
 Project: Hadoop Common
  Issue Type: Bug
  Components: test
Reporter: Konstantin Shvachko


# Remove unused member {{alwaysZeroScheduler}} and related initialization in 
{{TestFairCallQueue}}
# Remove unused local vriable {{sched}} in 
{{testOfferSucceedsWhenScheduledLowPriority()}}

And propagate to applicable release branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: Hadoop CI with alternate architectures.

[Konstantin Boudnik]

On Wed, May 18, 2016 at 08:29AM, Allen Wittenauer wrote:
>   That’s really a question for infrastructure-...@apache.org . They
>   manage the ASF build infrastructure which Apache Hadoop and lots of
>   other projects utilize.  (Bigtop uses something custom, which I think
>   is funded by Cloudera.)

Nope, Bigtop CI is not sponsored by Cloudera.

Besides, Bigtop is running itw own CI because we are producing a lot of
binary artifacts and don't won't to run a risk of clogging ASF-wide CI.

Cos
--
  Take care,
Konstantin (Cos) Boudnik


-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[jira] [Created] (HADOOP-13288) Guard null stats key in FileSystemStorageStatistics

[Mingliang Liu (JIRA)]

Mingliang Liu created HADOOP-13288:
--

 Summary: Guard null stats key in FileSystemStorageStatistics
 Key: HADOOP-13288
 URL: https://issues.apache.org/jira/browse/HADOOP-13288
 Project: Hadoop Common
  Issue Type: Sub-task
Reporter: Mingliang Liu
Assignee: Mingliang Liu


Currently in {{FileSystemStorageStatistics}} we simply returns data from 
{{FileSystem#Statistics}}. However there is no null key check, which leads to  
NPE problems to downstream applications. For example, we got a NPE when passing 
a null key to {{FileSystemStorageStatistics#getLong()}}, exception stack as 
following:
{quote}
NullPointerException
at 
org.apache.hadoop.fs.FileSystemStorageStatistics.fetch(FileSystemStorageStatistics.java:80)
at 
org.apache.hadoop.fs.FileSystemStorageStatistics.getLong(FileSystemStorageStatistics.java:108)
at 
org.apache.tez.runtime.metrics.FileSystemStatisticsUpdater2.updateCounters(FileSystemStatisticsUpdater2.java:60)
at 
org.apache.tez.runtime.metrics.TaskCounterUpdater.updateCounters(TaskCounterUpdater.java:118)
at org.apache.tez.runtime.RuntimeTask.setFrameworkCounters(RuntimeTask.java:172)
at 
org.apache.tez.runtime.task.TaskRunner2Callable.callInternal(TaskRunner2Callable.java:100)
at 
org.apache.tez.runtime.task.TaskRunner2Callable.callInternal(TaskRunner2Callable.java:37)
at org.apache.tez.common.CallableWithNdc.call(CallableWithNdc.java:36)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{quote}

This jira is to add null stat key check to {{FileSystemStorageStatistics}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[jira] [Created] (HADOOP-13287) TestS3ACredentials#testInstantiateFromURL fails if AWS secret key contains '+'.

[Chris Nauroth (JIRA)]

Chris Nauroth created HADOOP-13287:
--

 Summary: TestS3ACredentials#testInstantiateFromURL fails if AWS 
secret key contains '+'.
 Key: HADOOP-13287
 URL: https://issues.apache.org/jira/browse/HADOOP-13287
 Project: Hadoop Common
  Issue Type: Bug
  Components: fs/s3, test
Reporter: Chris Nauroth
Assignee: Chris Nauroth
Priority: Minor


HADOOP-3733 fixed accessing S3A with credentials on the command line for an AWS 
secret key containing a '/'.  The patch added a new test suite: 
{{TestS3ACredentialsInURL}}.  One of the tests fails if your AWS secret key 
contains a '+'.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: hadoop-build-tools/src/main/resources/META-INF/

[Xiao Chen]

Thanks Steve for reporting the issue and Sean for the suggestion. This is
indeed from HADOOP-12893
 (blush).

I'm no maven expert so appreciate any recommendations.

The reason for the current way is that for the L&N to be patched into a
jar, it seems that maven remote resource plugin
 (which
named itself to be the typical Apache licensing way) requires the files to
be under src/main/resources. This was mentioned in their example
,
and I wasn't able to trick it to pack things not in there. I wish there
were more examples to help in our case.

So, in HADOOP-12893 I put a step to copy the L&N into
hadoop-build-tools/src/main/resources dir, to allow it get packed into the
jar. I thought about symlink but don't think it's a good way for Windows
builds.

It's not committed because we don't want an extra copy of L&N, we could
list it in .gitignore.


P.S. Tried a bit with Sean's suggestion of making it under
target/generated-sources, but couldn't get the plugin to include it. I'm
happy to try out more elegant solutions if you have any suggestions.

Thanks!


-Xiao

On Fri, Jun 17, 2016 at 7:34 AM, Sean Busbey  wrote:

> If it's generated and we're following The Maven Way, it should be in
> target. probably in target/generated-sources
>
> On Fri, Jun 17, 2016 at 9:33 AM, Steve Loughran 
> wrote:
> >
> > I see (presumably from the licensing work), that I'm now getting
> hadoop-build-tools/src/main/resources/META-INF/ as an untracked directory.
> >
> > If this is generated, should it be in the source tree? And if so, should
> it be committed, or listed in .gitignore?
> >
> > -
> > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> > For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> >
>
>
>
> --
> busbey
>
> -
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>
>

[jira] [Created] (HADOOP-13286) add a scale test to do gunzip and linecount

[Steve Loughran (JIRA)]

Steve Loughran created HADOOP-13286:
---

 Summary: add a scale test to do gunzip and linecount
 Key: HADOOP-13286
 URL: https://issues.apache.org/jira/browse/HADOOP-13286
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 2.8.0
Reporter: Steve Loughran
Assignee: Steve Loughran


the HADOOP-13203 patch proposal showed that there were performance problems 
downstream which weren't surfacing in the current scale tests.

Trying to decompress the .gz test file and then go through it with LineReader 
models a basic use case: parse a .csv.gz data source. 

Add this, with metric printing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: hadoop-build-tools/src/main/resources/META-INF/

[Sean Busbey]

If it's generated and we're following The Maven Way, it should be in
target. probably in target/generated-sources

On Fri, Jun 17, 2016 at 9:33 AM, Steve Loughran  wrote:
>
> I see (presumably from the licensing work), that I'm now getting  
> hadoop-build-tools/src/main/resources/META-INF/ as an untracked directory.
>
> If this is generated, should it be in the source tree? And if so, should it 
> be committed, or listed in .gitignore?
>
> -
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>



-- 
busbey

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

hadoop-build-tools/src/main/resources/META-INF/

[Steve Loughran]

I see (presumably from the licensing work), that I'm now getting  
hadoop-build-tools/src/main/resources/META-INF/ as an untracked directory.

If this is generated, should it be in the source tree? And if so, should it be 
committed, or listed in .gitignore?

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

[Apache Jenkins Server]

For more details, see 
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/66/

[Jun 16, 2016 11:17:06 AM] (vinayakumarb) HDFS-10256. Use 
GenericTestUtils.getTestDir method in tests for
[Jun 16, 2016 3:55:56 PM] (junping_du) YARN-5083. YARN CLI for AM logs does not 
give any error message if
[Jun 16, 2016 4:46:05 PM] (cnauroth) HADOOP-12875. [Azure Data Lake] Support 
for contract test and unit test
[Jun 16, 2016 5:10:33 PM] (arp) HDFS-10532. Typo in RollingUpgrade docs. 
(Contributed by Yiqun Lin)
[Jun 16, 2016 6:13:35 PM] (raviprak) HADOOP-3733. "s3x:" URLs break when Secret 
Key contains a slash, even if
[Jun 16, 2016 6:18:02 PM] (cnauroth) HADOOP-13241. document s3a better. 
Contributed by Steve Loughran.
[Jun 16, 2016 10:22:00 PM] (xyao) HADOOP-13255. KMSClientProvider should check 
and renew tgt when doing
[Jun 16, 2016 11:48:05 PM] (cmccabe) HADOOP-12975. Add jitter to 
CachingGetSpaceUsed's thread (Elliott Clark
[Jun 17, 2016 1:20:49 AM] (shv) HADOOP-13189. FairCallQueue makes callQueue 
larger than the configured
[Jun 17, 2016 2:03:54 AM] (aajisaka) MAPREDUCE-6542. HistoryViewer uses 
SimpleDateFormat, but
[Jun 17, 2016 6:35:20 AM] (cnauroth) HADOOP-13242. Authenticate to Azure Data 
Lake using client ID and keys.




-1 overall


The following subsystems voted -1:
unit


The following subsystems voted -1 but
were configured to be filtered/ignored:
cc checkstyle javac javadoc pylint shellcheck shelldocs whitespace


The following subsystems are considered long running:
(runtime bigger than 1h  0m  0s)
unit


Specific tests:

Failed CTEST tests :

   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_test_libhdfs_zerocopy_hdfs_static 
   test_test_native_mini_dfs 
   test_test_libhdfs_threaded_hdfs_static 
   test_te