Automatic translation

Archives

February 2012
The My Me J V S D
"January
A 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29

Contributors

What's up Mulesoft?

Yesterday we hosted our friends Mulesoft for a little update on their offer.

I mean our friends for 4 years because teams Ippon Technologies have always had excellent results in the implementation of techno Mule with deployment time performance record and the appointment (whether in open offer source or supply company).

So what's new at Mulesoft :

  • The offer is completed to the middleware layer with the promise to make available software projects simple and efficient. Mule does not yield to the lure of BPM, BAM and co (their recommendations remain Intallio and jBPM )
  • BSE is still the flagship and large deployments are well under way (the European Parliament, the taxes in Ireland, back-office control of Nespresso, the platform partners ClubMed, ...)
  • Performance is always a priority for MuleESB available with a module for High-Availabity fail-over and load-balancing and integration with the new MuleMQ (see below).
  • BSE is supplemented by the following blocks:

MuleSoft-stack-2010.jpg

. . . → Read more: What's up Mulesoft?

jBPM 4.1 now available

ImageBrowser image

Output version 4.0 in July last, jBPM us back in version 4.1 in early September. A new release very close to the previous, due to the holding of the great mass of JBoss World , which ran from 1 to 4 September 2009 in Chicago.

To recap, the jBPM version 4.0 brought a lot of news, with a complete reorganization of the project initiated by Tom Baeyens (jBPM project lead) and in collaboration with Miguel Valdes Faura (Project project lead Bonita to OW2 ) . This joint has set up the module PVM (Process Virtual Machine), generic workflow engine used as a common basis in different languages ​​such as process definition jPDL , BPEL or the pageflow in Seam .

Together with the PVM module, version 4.0 has made other major changes:

. . . → Read more: jBPM 4.1 now available

Ippon Technologies SpringSource partner

SpringSource logo

Ippon Technologies has formalized its partnership this summer with SpringSource , the company developing the many bricks of the Spring framework and the application server SpringSource Application Platform .

Beyond a certain recognition of its expertise on Spring, Ippon Technologies will invest in the growing expertise of its teams:

- Spring Security (Acegi)

- Spring Web Flow

- Spring Web Services

- Spring Batch

- SpringSource Application Mangement Suite

The goal is to offer a service from start to finish on the platform design and production monitoring to supplement it with a professional support provided by SpringSource.

Our platform open source JEE reference is now complete with Mule + Spring + Liferay and we will certainly return to this blog with the feedback field.

. . . → Read More: SpringSource partner Ippon Technologies

"OutOfMemoryError: PermGen space" késaco?

Everyone who has encountered this problem for the first time have certainly been tearing their hair. Why the Java process he complains of not having memory so it does not use half of that allocated to it?

The first part of the answer is pretty simple ... if you have already seen! Sun JVM defines the size of the allocated memory into two separate lots.

  1. The conventional memory ("heap") typically configured with the options-Xms128m and-Xmx256m, respectively for the initial size and maxim

  2. The memory of the "permanent generation", including statements containing Class objects (but not instances!) And Method. The size of this space is defined by the-XX: PermSize = 96m and-XX: MaxPermSize = 128m respectively to the initial size and maximum size

It is quite possible that the default setting (64MB maximum size) is insufficient and that an "OutOfMemoryError: PermGen space" appears after a few minutes of using the application, following the compilation of a volume too important to JSP. In this case, increase the space "permanent generation" to 128Mb should solve the problem. Beware though, as all options starting with XX, it is implementation-specific parameters of the JVM, namely that of Sun. Thus the BEA JVM instance does not separate the definition of these two spaces in its JVM options.

So, with these options we are rid of this memory error. Not necessarily ...

Indeed, it is possible that this error reappears after several eg re-deployment of a web application under Tomcat. In this case, setting the memory is not involved, but it is actually a memory leak. Specifically, the application classes that have been discharged are not recycled by the JVM. Indeed, as a reference to a class remains loaded by the classloader of the web application, this class loader and all the classes it has defined can not be recycled.

A multitude of causes can lead to this problem, the most classic:

  • loading a JDBC driver in the web application classloader: the driver (and thus the classloader and all classes) is referenced by the server at DriverManager, you can use to unload the driver ServletContextListener

  • a library loaded at the server level (Hibernate type) reference in a cache of application classes (eg classes Proxy model classes)

  • the web application fixed data in a ThreadLocal object, linked to a server thread (the thread belongs to a pool of container and is never recycled)

For more information on this subject and in particular a list of tools to identify the source of the problem, I recommend this article .

. . . → Read more: "OutOfMemoryError: PermGen space" késaco?