Howdy, >> - try combining multiple jars into a single jar: make a temporary >> directory, unpack each jar into it, then jar up the temporary >> directory. Again, you'd need to do this on a per-classloader >> basis >> >> If doing this, be careful of signed jars. You'll need to unsign them >> by removing any META-INF/*.SF, META-INF/*.RSA, and META-INF/MANIFEST.MF >> files. > >I was playing around with this and achieved a decent amount of success. >Can the same be done with the tomcat supplied jar's (say /server/lib/*) >without negative effect?
Yes, you can do the same with tomcat jars, they're not signed. >> - try increasing the number of file descriptors at the os level. >> With a solaris machine, that's rlim_fd_cur and rlim_fd_max in >> /etc/system. I'm not sure about linux (/proc/sys/fs/file-max?) > >This is the last thing I'm looking into. I'd much rather get the >application to behave than to tune a kernel for a poorly performing app, >but if nothing else works I'll finish with that. It's not a kernel tune, on Solaris at least, it's just the ulimit command. Not only is this a safe and easy thing to do, it's a standard practice in large application deployment environments. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
