JBoss has jar limit ?

[LukaszP]

Hi
I've encountered a serious problem in JBoss (because of the compatibility
issues we are still using JBoss 3.2.1). After the number of jar files
reaches a certain number (in this case 84) adding another jar crashes the
server. Some services (like Log4jService) just fail during loading (I get a
ClassNotFoundException). It's not about the size of the libraries (I've
tried removing a big jar and adding two small ones) but about the number.
I've tried many options for allocating more memory for application,
libraries, heap etc. but it didn't work.
I've also tried to to repeat the situation I described on another machine.
It took more libraries, but did also occur.
Has anybody an advice ?
Regards

 

[jgrabell]

Has anybody an advice ?

I have limited experience with JBoss, but in general you can repackage
several jars into one as a stop-gap measure:

To extract jar1.jar, jar2.jar and jar3.jar:
jar -xvf jar1.jar
jar -xvf jar2.jar
jar -xvf jar3.jar

then to create a new jar run:
jar -cvf newjar.jar ./com ./org (whatever directories were extracted
from the other jars).

http://en.wikipedia.org/wiki/JAR_(file_format)

Watch out for signed jars. I wouldn't recommend this unless you have
no other option and need to make progress. An upgrade might be in
order.

 

[LukaszP]

I have limited experience with JBoss, but in general you can repackage
several jars into one as a stop-gap measure:

To extract jar1.jar, jar2.jar and jar3.jar:
jar -xvf jar1.jar
jar -xvf jar2.jar
jar -xvf jar3.jar

then to create a new jar run:
jar -cvf newjar.jar ./com ./org (whatever directories were extracted
from the other jars).

I thought of that, but it's rather a solution, not an explanation .
Maybe anyone has an explanation ?
Regards

 

[jgrabell]

I thought of that, but it's rather a solution, not an explanation .
Maybe anyone has an explanation ?

Might be the number of open file descriptors. Is it running on UNIX?

 

[Brandon McCombs]

Might be the number of open file descriptors. Is it running on UNIX?

Even if it was running on UNIX I don't see how there could be enough
files in the JARs(if all the files in each JAR was being opened all at
once), let alone just the JARs themselves that would cause the OS to run
out of file descriptors. The various UNIX flavors should have a minimum
of around 32768 file descriptors, if not more. That may not be the exact
number but I just know that it shouldn't be a couple hundred file
descriptors like your question alludes to. I've seen Windows XP have
over 700,000 file handles open and it didn't even phase it.

 

[jmcgill]

The various UNIX flavors should have a minimum
of around 32768 file descriptors, if not more. That may not be the exact
number but I just know that it shouldn't be a couple hundred file
descriptors like your question alludes to.

I've seen this limit at 256 (per process) on different systems, but not
lately. It can be ulimit-ed for the user.

 

[jgrabell]

I've seen this limit at 256 (per process) on different systems, but not
lately. It can be ulimit-ed for the user.

File descriptors include sockets, open libraries etc, maybe some other
touch points into kernel resources. In my Solaris experience, and I
think 4096 was the default hard limit on Solaris, but as you say, the
soft limit can be lower. If 256 were the maximum, it could be very
easy to exceed the limit.

A search of the jboss site for file descriptors or MAX_FD turns up
several results.

 

[jgrabell]

Even if it was running on UNIX I don't see how there could be enough

files in the JARs(if all the files in each JAR was being opened all at
once), let alone just the JARs themselves that would cause the OS to run
out of file descriptors.

You don't need a file descriptor for each file in a jar file; one for
each jar.

The various UNIX flavors should have a minimum
of around 32768 file descriptors, if not more.

Typically the per process file descriptor limit is not set to be the
system maximum.

That may not be the exact
number but I just know that it shouldn't be a couple hundred file
descriptors like your question alludes to. I've seen Windows XP have
over 700,000 file handles open and it didn't even phase it.

Windows files objects are not the same as UNIX file descriptors except
that they both point to filenames.

Thanks for the insightful feedback.