If I use "provided" libs on the application server (wildfly), do I gain performance?

3

Imagine the following scenario. I have a WildFly 8.0.0 application server running with default settings from "factory". On this server I squeeze 4 simple web applications. These applications use some similar libs as:

  • Spring Framework;
  • Primefaces;
  • Spring Security;
  • ...

Only each application packages the libs it uses itself. Then she bundles spring jars, primefaces, some commons and so on. In fact all applications do this packaging in WEB-INF/lib . Even they pack the same version of Spring as Primefaces ...

Now comes some doubts:

  • If I remove the common libs between applications and put WildFly /standalone/lib and set these libs as provided would I gain performance in those apps?
  • If there are different versions packaged in the applications, can this be a problem? For example: in one application I put Spring 3.0 and in the other pack Spring 4.0. Can this conflict in any of the applications, or does WildFly isolate these libs so that one does not interfere with the other?
  • asked by anonymous 13.05.2014 / 22:04

    1 answer

    2

    In theory you can have several benefits when using the same libraries sharing between applications:

  • Less memory usage , since there will be only one instance of each class, in the Classloader of shared libraries, instead of one for each application, in the particular Classloader created for each them.

  • Less bandwidth usage and deploy faster , because the packet gets much smaller. Java applications that I have seen have packages in the range of 50 to 100MB, but the application code itself is generally 10% of that size, the rest being composed only of third-party libraries.

  • Best performance , if you consider the greater cache usage the JVM and the operating system can do since the executed classes are the same.

  • >

    However, there are also some disadvantages:

  • All applications need to be up to date to use the same versions of all APIs, which is often not feasible in a corporate environment.

  • Updating an API needs to be synchronized with updating all applications, which makes it very difficult to administer the servers.

  • Assembling the application WAR or EAR package must be careful because if an application contains the same dependencies as the shared lib, "dreaded" Classloader conflicts can occur, which generate bizarre and hard-to-identify errors.

  • Speaking more specifically about the problems of different classes in different Classloaders, this does not dignify that always problems will occur. But if there are two versions of the same library, Wildfly may occur to load the classes you do not want it to carry.

    This happened a lot with me on Tomcat. The general rule is: the container will always load the incorrect version of the class!

    Another approach that would give you a bit more flexibility is the use of modules . You could package each framework into a custom module and make your applications depend on those modules. This is an interesting alternative because it allows each application to use only the required libs and even different versions of the same framework.

    Creating modules is a common technique for adding new database drivers, as described this link .

        
    14.05.2014 / 20:37