The way I would debug this is start maven in debug mode (search for -Xdebug in the mvn launcher and add the relevant options to MAVEN_OPTS). Fire up your remote java debugger (e.g. in Eclipse or equivalent) then set a break point on the exception. You also need to set the forking option to never in your pom's surefire plugin configuration so that the tests run in the main maven process otherwise the breakpoint won't fire.
If you are running on a unix that has lsof installed, once the breakpoint fires and while still paused on the breakpoint, fire up lsof to work out which files are being held open by the mvn Java process. If you don't have lsof, then at least you might get some insight into what files are the issue. Also, consider upping the ulimit setting for max open files [ if it is particularly low ]. jon. On Sat, Jun 21, 2008 at 6:10 AM, Kathryn Huxtable <[EMAIL PROTECTED]> wrote: > Nope, that's not it. I reduced it down to one test and it still fails and it > fails in setUp. -K > > On Jun 20, 2008, at 3:03 PM, Kathryn Huxtable wrote: > >> I'll take a look. It's not my code, or it would have been in maven to >> begin with. -K >> >> On Jun 20, 2008, at 12:58 PM, Jon Seymour wrote: >> >>> Haven't seen the error myself, but I suspect the problem you are >>> seeing is caused by a resource leak in your base code or your tests. >>> The reason you are seeing it in surefire and not in testrunner is that >>> surefire creates a new class loader for every test which means that >>> each test will be getting its own copy of the leaked resources, >>> thereby exhausting the underlying pool of OS resources faster. >>> >>> I'd be inclined to check that you are being hygenic with respect to >>> the closure of IO streams, especially on exception paths. >>> >>> Regards, >>> >>> jon seymour. >>> >>> On Fri, Jun 20, 2008 at 8:01 PM, Kathryn Huxtable >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> I should have added that I'm running Maven 2.0.9 and >>>> maven-surefire-plugin >>>> 2.4.3. I'm supplying the argLine of -Xmx300M and I'm specifying a >>>> resource >>>> directory as an additional class path element. If I don't specify the >>>> memory >>>> I get out of memory errors. Specifying more doesn't help. >>>> >>>> -K >>>> >>>> On Jun 20, 2008, at 4:51 AM, Kathryn Huxtable wrote: >>>> >>>>> I'm converting a project from ant to maven and I'm getting a "Too many >>>>> open files" error during testing when it tries to open some config >>>>> files in >>>>> a SAX parser. >>>>> >>>>> I don't get this error when using the TestRunner class from the command >>>>> line. >>>>> >>>>> I don't think the specific file is relevant, and I don't think it's >>>>> opening that many files... >>>>> >>>>> Any ideas? Has anyone seen this before? >>>>> >>>>> -K >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
