12

We have a web application made in Java, which uses struts2, spring and JasperReport. This application runs on glassfish 4.0.

The libraries of the application are in the WEB-INF/lib folder, and also in glassfish are installed 4 more than uses the same libraries.

Glassfish is configured to use 1024mb for heapspace and 512m for permgen, and the most of the memory consumption when i use libraries per application is in the struts actions and spring aop classes (using netbeans profiler).

The problem we are having is the amount of memory consumed by having libraries in the classloader per application because is to high and generates PermGen errors and we have also noticed that the application run slower with more users.

because of that we try to use shared-libraries, put it in domain1/lib folder and found that with a single deployed application the load time and memory consumption is much lower, and the application works faster in general. But when we deploy the rest of the applications on the server only the first application loaded works well and the rest has errors when we calls struts2 actions. We believe that is because each application has slightly different settings on struts2 and log4j.

We have also tried to put only certain libraries on glassfish and leaving only struts2 in the application but it shows InvocationTargetException errors because all libraries depend the lib from apache-common and it dont matter if we put those lib on one place or another. Also if we put it in both places the application don’t start.

  1. there any special settings or best practices for using shared-libraries?
  2. Is there a way to use shared-libraries but load settings per application? or we have to change the settings to make them all the same?
Aegis
  • 113
  • 7
  • 27
  • In Glassfish 4, to share library among many applications you have to put in in `/domains//lib/ext`. You can try to override your specific properties files so they will be loaded last (make sure the path is correct). – Khozzy Nov 08 '13 at 09:09
  • I have understood that shared libraries go in domain1/lib folder and domain1/lib/ext is only for core platform classes. I'm wrong? – Aegis Nov 08 '13 at 14:45
  • what's the distinction between core platform and shared libraries? I would naively expect core classes to already be include with glassfish..? – Thufir Oct 03 '14 at 06:35

4 Answers4

3

Is there any special settings or best practices for using shared-libraries? Is there a way to use shared-libraries but load settings per application? or we have to change the settings to make them all the same?

These are actually interesting questions... I don't use GlassFish but, according to the documentation :

Application-Specific Class Loading

[...] You can specify module- or application-specific library classes [...] Use the asadmin deploy command with the --libraries option and specify comma-separated paths [...]

Circumventing Class Loader Isolation

Since each application or individually deployed module class loader universe is isolated, an application or module cannot load classes from another application or module. This prevents two similarly named classes in different applications or modules from interfering with each other.

To circumvent this limitation for libraries, utility classes, or individually deployed modules accessed by more than one application, you can include the relevant path to the required classes in one of these ways:

  • Using the Common Class Loader
  • Sharing Libraries Across a Cluster
  • Packaging the Client JAR for One Application in Another Application

Using the Common Class Loader

To use the Common class loader, copy the JAR files into the domain-dir/lib or as-install/lib directory or copy the .class files (and other needed files, such as .properties files) into the domain-dir/lib/classes directory, then restart the server.

Using the Common class loader makes an application or module accessible to all applications or modules deployed on servers that share the same configuration. However, this accessibility does not extend to application clients. For more information, see Using Libraries with Application Clients. [...]

Then I would try:

Solution 1

  • put all the libraries except Struts2 jars under domain1/lib ,
  • put only Struts2 jars under domain1/lib/applibs,

then run 

$ asadmin deploy --libraries struts2-core-2.3.15.2.jar FooApp1.war
$ asadmin deploy --libraries struts2-core-2.3.15.2.jar FooApp2.war

To isolate Struts2 libraries classloading while keeping the rest under Common Classloader's control.

Solution 2

  • put all the libraries except Struts2 jars under domain1/lib ,
  • put only Struts2 jars under domain1/lib/applibs, in different copies with different names, eg appending the _appname at the jar names

then run 

$ asadmin deploy --libraries struts2-core-2.3.15.2_FooApp1.jar FooApp1.war
$ asadmin deploy --libraries struts2-core-2.3.15.2_FooApp2.jar FooApp2.war

To prevent sharing of the libraries by istantiating (mock) different versions of them.

Hope that helps, let me know if some of the above works.

Andrea Ligios
  • 49,480
  • 26
  • 114
  • 243
  • hi, is not working because the 3 framework uses several libraries in common and if I place other framework into the common class loader and isolate struts it shows me InvocationTargetException, this also happen if i put share libraries in both locations – Aegis Nov 14 '13 at 12:41
  • changing the common jars file name using by struts2 plus solution 2 do the trick. thx – Aegis Nov 16 '13 at 21:30
2

You can try to create what is known as a skinny WAR. Pack all your WARs inside an EAR and move all the common JARs from WEB-INF/lib to the lib/ folder in the EAR (don't forget to set <library-directory> in the application.xml).

Philippe Marschall
  • 4,452
  • 1
  • 34
  • 52
  • 1
    with this approach can i update a single war? o i need to redeploy the full ear when i have a update? – Aegis Nov 12 '13 at 18:47
  • 1
    Regarding Skinny WARs and Struts2, you should read this because it doesn't work out-of-the-box (but the solution found requires 1 minute of setup): http://stackoverflow.com/questions/19380836/skinny-war-libraries-in-ear-struts-tags-not-found-error – Andrea Ligios Nov 13 '13 at 23:32
0

I'd bet that placing the libs under lib/ or lib/ext won't resolve your performance issues. You did not write anything about the applications or server settings, like size of application, available Heap and PermGen space, but nonetheless I would recommend to stay with separate libs per app.

If you place the libs in server dirs, they will be shared among all apps. You will loose the option to upgrade only one of your applications to a new framework or to get rid away of any of them. Your deployment will be bound to a specific server architecture.

And you wrote it did not solve your problems, it even may raise new ones.

I would recommend to invest some hours into tuning the server. If it runs with defaults, allocate more PermGen and HeapSpace.

If this does not help, you should analyze in deep what's going wrong. Shared libs might be a solution, but you don't know the problem, yet. IBM offer some cool and free tools to analyze heap dumps, this could be a good starting point.

Michael
  • 291
  • 1
  • 3
  • 13
  • Glassfish is configured to use 1024mb for heapspace and 512m for permgen, the most of the memory consumption when i use libraries per application is in the struts actions and spring aop classes (using netbeans profiler) i'm missing something? – Aegis Nov 12 '13 at 19:01
0

I came here in search of guidance about installing libraries that are shared among multiple applications or projects. I am deeply disappointed to read that the accepted practice favors installing a copy of every shared library into each project. So, if you have ten Web application, all of which use, e. g., httpcomponents-client, mysql-connector-java, etc., then your installation contains ten copies of each.

This behavior reminds me, painfully, of the way of thinking that motivated me to abandon the mainframe in favor of the PC; the thinking seemed to be "I don't care how many resources my application consumes. In fact, I'd like to be able to brag about what a resource hog it is." Excuse me, please, while I hurl.

  • The interface exposed by a library is an immutable contract that is not subject to change at the developer's whim.

  • There is this concept called backwards compatibility. If you break it, you create a new interface.

I know of at least two types of interfaces that adhere to the letter and spirit of these rules.

  1. By far the oldest is the IBM System/370 system libraries. You might have Foo and Foo2, where the latter extends and/or breaks the contract made by the Foo interface in some way that made it incompatible.

  2. From its beginnings in the Bell Labs Unix project, the standard C runtime library has adhered to the above rules.

  3. Though it is much newer, the Microsoft COM interface specification enforces the same rule.

To their credit, Microsoft generally adheres to those rules in the Win32 API, too, although there are a handful of exceptions in that API. To a degree, they went backwards with the .NET Framework, which seems slavishly to follow in the footsteps of the Java environment that it so eagerly seeks to replace.

I've been using libraries since 1978, and my understanding was and is that the goal of putting code into a library was to make it reusable. While maintaining copies of the library code in each application eliminates the need to implement it again for each new project, it severely complicates upgrading, since you now have ten (or more) copies of the library, each of which must be updated.

If libraries adhere to the rule that an interface is an immutable contract, why shouldn't they live in a shared library directory, as do the Unix system libraries that live in its /lib directory, from which everything that runs on the host shares a single copy of the standard C runtime library, Zlib, and so forth.

Color me seriously disappointed.

David A. Gray
  • 1,039
  • 12
  • 19