Technically speaking the docset is not 'too big', it is simply causes
too many native threads to be created for most 'default' Linux
distributions.
Run the sample program and you should with a Linux 2.4 system get around
220ish threads. The options without the change are as follows.
o Use build.compiler=classic (which kicks the JVM into green
threads which doesn't have a 'real' thread limit.
o Set ulimit -u to greater around 1024
o Modify /etc/security/limits.conf and nprocs to something
around 1024
So the 'fix' is a workaround. (Probably is the best solution for the
moment, but it isn't a bug in the code, more so a configuration problem
in the standard configuration of Linux distributions.
Just thought people might be interested (I spent about 2 hours
attempting to get my first CVS build running when I came across this
problem :).
Regards,
Matthew 'The new developer on the block' Tippett
Francisco Reverbel wrote:
> Found the cause: a recent change on server/build.xml made xdoclet
> to be called on a fileset too big (name="**/*.java").
>
> I will revert the change. But it is strange that nobody else saw
> this... I have tried two Linux machines (a laptop with 128M and a
> box with 384M) with the same result: xdoclet barfed on the big
> fileset. Maybe there is something in my Linux environment that made
> me run out of memory before anybody else.
>
>
>>leset>
>>Running xdoclet.XDocletMain loaded by
>>sun.misc.Launcher$AppClassLoader. Forked:\
>>true
>> [xdoclet] Running <mbeanInterface/>
>> [xdoclet] java.lang.OutOfMemoryError: unable to create new native thread
--
Matthew Tippett - [EMAIL PROTECTED]
Toronto, Canada - (416) 435-4118
public class TestThread extends Thread {
public static void main(String argv[]) {
int i=0;
while(true) {
TestThread thread = new TestThread();
try {
thread.start();
} catch (Throwable e) {
System.out.println("Maximum number of threads is "+Thread.activeCount());
System.exit(-1);
}
}
}
public void run() {
while (true) {
try {
sleep(10000);
} catch (Exception e) {
}
}
}
}
