[
https://issues.apache.org/jira/browse/BOOKKEEPER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104760#comment-13104760
]
Matthieu Morel commented on BOOKKEEPER-67:
------------------------------------------
Flavio, I suppose the output you show is from a macosx system.
I confirm that on macosx, the default JVM (1.6.0_26 on my machine) actually
seems to _ignore_ the soft max open file limit, and uses a hardcoded limit of
10240. Some hints there
http://lists.apple.com/archives/Java-dev/2008/Aug/msg00212.html
Attached is a small program that outputs the current number of open files and
maximum number of open files for a java process, as seen by the JVM. (pardon
the circumvoluted way to fetch the info!) You run it as: java
-Dcom.sun.management.jmxremote.port=4086
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -cp . ShowFileDescriptorsInfo
output on macosx 10.6.8:
$ ulimit -a | grep files
open files (-n) 256
$ java -Dcom.sun.management.jmxremote.port=4086
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -cp . ShowFileDescriptorsInfo
OpenFileDescriptorCount -> 43
MaxFileDescriptorCount -> 10240
On linux (RHEL4.8), the soft limit is taken into account by the JVM (standard
oracle/sun), therefore we reach the default soft limit of 1024, and things
break (I tracked the creation of files in bookkeeper.bookie.FileInfo and can
confirm that).
$ ulimit -a |grep files
open files (-n) 1024
$ java -Dcom.sun.management.jmxremote.port=4086
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -cp . ShowFileDescriptorsInfo
OpenFileDescriptorCount -> 15
MaxFileDescriptorCount -> 1024
I'm not sure if we need to create that many ledgers in this test, couldn't the
same point be made with 100 ledgers? Then the test would pass out of the box on
linux as well.
> BookieReadWriteTest gets blocked and never finishes
> ---------------------------------------------------
>
> Key: BOOKKEEPER-67
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-67
> Project: Bookkeeper
> Issue Type: Bug
> Environment: RHEL4.8 and Debian 6
> Reporter: Matthieu Morel
> Attachments: BookieReadWriteTest-RHEL4.8.log,
> ShowFileDescriptorsInfo.java
>
>
> I systematically reproduce this behaviour on the linux boxes I tested with.
> The test gets stuck acquiring permits from a semaphore, normally used for
> throttling:
> "main" prio=10 tid=0x08058c00 nid=0x588d waiting on condition [0xf723c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xb5619728> (a
> java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
> at
> org.apache.bookkeeper.client.LedgerHandle.asyncAddEntry(LedgerHandle.java:394)
> at
> org.apache.bookkeeper.client.LedgerHandle.asyncAddEntry(LedgerHandle.java:366)
> at
> org.apache.bookkeeper.test.BookieReadWriteTest.testShutdown(BookieReadWriteTest.java:815)
> The issue might come from the synchronization mechanism used in the test
> itself.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
