I didn't create it, but I've checked it pretty thoroughly. It's well
formed. There are no circular references. This stuff has been working
for awhile in production environments.
It looks as if the problem may have been the way they were calling the
digester's parse method. They were using the class loader to get a
resource's URL and then converting it to a string. They then passed
this string to the parse method. Just passing the resource as a stream
did the trick.
I think it's fixed.
Now, on to attempting to embed Apache DS in my JUnit tests.
-K
On Jun 23, 2008, at 10:09 AM, Sean Hennessy wrote:
Is the XSD file well formed?
Do you receive any complaint from xml editor (eg:XMLSpy) opening the
XSD file?
What are the chances the XSD file have a circular reference
definition?
-----Original Message-----
From: Kathryn Huxtable [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 21, 2008 1:15 AM
To: Maven Users List
Subject: Re: Too many open files during surefire test
Getting closer. If I do
mvn surefire:test
Everything works fine. If I do
mvn test
I get the "too many open files" message.
I get this even if I set forkMode to "never".
I still think this is a spurious bug in Maven and not in the code
I'm working on, simply because the error happens on the first file
it tries to open, which is an XSD file being used by a SAX parser in
commons-digester. This isn't rocket science.
-K, slogging on and unable to sleep. I'm in GMT-0600.
On Jun 20, 2008, at 3:33 PM, Kathryn Huxtable wrote:
Thanks. I'm running on Mac OS X 10.5.3. (The latest.) The ulimit for
files is unlimited.
I have a Windows system and an Ubuntu system in the house. (I work
from home.) I'll try it on those platforms, too.
I'm inclined to think that the error is bogus, simply because the
test
has barely started.
I'll take your advice on debugging it, though.
-K
On Jun 20, 2008, at 3:19 PM, Jon Seymour wrote:
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]
---------------------------------------------------------------------
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]
