Yeah, actually they pass for me as well in Mac with only 256. So I'm thinking it could somehow be vmware, or maybe I have some bad network config, do the tests open a lot of sockets?
The java versions are almost identical CentOS % java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) MacOSX % java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode) So I'm thinking it must either be some sort of networking configuration, or some sort of vmware specific problem. Either way, looks like it might be an environment not a software problem. -Anthony On Mon, Aug 16, 2010 at 07:20:21AM -0700, Bryan Duxbury wrote: > The Java unit tests *do* run in a single VM, so there is a chance that if > things are leaked you could have later tests contaminated. I made this > change to the test suite so that the tests would execute very quickly. > > By all signs, the ulimit on my Mac is 256, but my tests pass. > > On Sun, Aug 15, 2010 at 11:20 PM, Anthony Molinaro < > antho...@alumni.caltech.edu> wrote: > > > Okay, so I got it to pass the tests. I started playing with the number > > of threads in the async test since that was the first that failed, and > > that works, but seemed odd. 100 works fine, 400 works fine, 490 causes > > a test several past the async test to fail. > > > > This makes me think somehow junit is running everything in the same > > java vm, and it's somehow leaking some file descriptors with my version > > of java (or maybe in thrift lib, hard to say). > > > > Since the problem was open file descriptors, I checked and my ulimit > > was 1024, so with 500 threads in the async test, if for some reason > > some of the tests open a bunch of network connections or something, > > and fail to close them you could run out of file descriptors and things > > would start failing. > > > > So I upped my limit to 65535 and now the tests pass. So not sure if > > this warrants a ticket or not, it could be an issue with file descriptors > > leaking somewhere, it could maybe be a problem with the version of > > java I'm running (although we've been running cassandra and our own > > high throughput, high traffic webserver with it, without issue, although > > not on vmware which is the 'machine' I'm running on). > > > > Bryan, what is your file descriptor limit set to? > > > > Anyway, still want a ticket? > > > > -Anthony > > > > > > On Sun, Aug 15, 2010 at 02:19:14PM -0700, Bryan Duxbury wrote: > > > On my local machine, the java library tests cleanly. The errors in your > > > build output seem to be related to available file handles, which should > > > never be an issue. I'm not sure this is a real bug or not, but could you > > > please open a ticket for us to investigate? > > > > > > On Sat, Aug 14, 2010 at 1:37 PM, Anthony Molinaro < > > > antho...@alumni.caltech.edu> wrote: > > > > > > > -1 from me, make check fails on Centos 5.3 because of java failures > > > > > > > > % java -version > > > > java version "1.6.0_20" > > > > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > > > > Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > > > > > > > > Build/check output attached > > > > > > > > -Anthony > > > > > > > > -- > > > > > > ------------------------------------------------------------------------ > > > > Anthony Molinaro < > > antho...@alumni.caltech.edu> > > > > > > > > -- > > ------------------------------------------------------------------------ > > Anthony Molinaro <antho...@alumni.caltech.edu> > > -- ------------------------------------------------------------------------ Anthony Molinaro <antho...@alumni.caltech.edu>
