reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yunseong Lee (JIRA)" <>
Subject [jira] [Commented] (REEF-1231) Too many open files in NetworkConnectionServiceTest
Date Wed, 09 Mar 2016 02:25:40 GMT


Yunseong Lee commented on REEF-1231:

I've updated the title to describe the exact problem. I'll update the description as well.
Could anyone confirm that sharing {{NioEventLoopGroups}} across {{Transport}}s is safe? Or
does anyone guide us with a better approach?

> Too many open files in NetworkConnectionServiceTest
> ---------------------------------------------------
>                 Key: REEF-1231
>                 URL:
>             Project: REEF
>          Issue Type: Bug
>         Environment: OS: Ubuntu 12.04 (VirtualBox VM)
> OS: Ubuntu 14.04
> JDK: HotSpot 1.7.0_80
>            Reporter: Yunseong Lee
>            Priority: Blocker
>         Attachments: reef-0.14.0-rc1-java-ubuntu.log
> While making {{NameLookupClient}} injectable in REEF-703, and removing the deprecated
Constructor in REEF-1124, {{replyLookupQueue}} has become NOT shared between {{NameClient}}
and {{NameLookupClient}}. A question regarding this was actually raised by [~MariiaMykhailova]
at REEF-703, but the JIRA was resolved without a clear answer.
> This change has not caused any problem in OSX, Windows, and Travis CI's Ubuntu. In other
Ubuntu machines, however, {{reef-io}} tests fail due to “too many open files” exception.
Tests passed on my Ubuntu VM by increasing the maximum number of open files with “ulimit
-n 9999” command.
> But increasing the maximum number is just a workaround; I think a cleaner solution will
be to share {{replyLookupQueue}} as we used to. Any thought?

This message was sent by Atlassian JIRA

View raw message