JPPF Forums

JPPF Help => Troubleshooting => Topic started by: speedophot on November 27, 2013, 12:06:18 AM

Title: JPPF Task with Spring/Hibernate - Classloading Issue?
Post by: speedophot on November 27, 2013, 12:06:18 AM
Hello,

we have a Task that loads up a Spring application context and some Hibernate configuration. When the task is run as a standalone Java application (calling run() from a main method) everything works fine. However, when it is executed on a JPPFNode it has problems loading Hibernate’s persistence.xml, which appears to be loaded twice from different locations.

The persistence.xml is located in a META-INF folder and loaded from the classpath. When the Hibernate data source is initialized by Spring, we get an IllegalStateException with the message „Conflicting persistence unit definitions for name <our persistence configuration name>“. The message further states that the files in conflict are located in C:\Users\speedophot\AppData\Local\Temp\.jppf\<some-UUID> and C:\Users\speedophot\AppData\Local\Temp\.jppf\<some-UUID>_10

Indeed, both directories contain identical persistence.xml files. These are copies of the one we actually want to load. We made sure that the persistence.xml only appears once on the classpath.

I am probably missing something here. The folders with the persistence.xml files look like cache directories for the JPPF classloader, but I do not know the purpose of the enumerated versions of these directories. We always get the conflict between a copy of the persistence.xml in the folder without a enumeration suffix and another folder with the same UUID and some enumeration suffix (see example above). I suspect that the persistence.xml, which is actually the right one, is loaded twice by spring from different files. Hibernate considers the two copies as different and conflicting persistence-configurations.

Could this be related to JPPF’s classloading mechanism and, if yes, is there a way to prevent this problem? Yet, the only solution seems to be not to load the persistence.xml from the classpath which is tricky and does not feel like the right way to do it.

Thanks,
Speedophot

PS: We use JPPF 3.3.6 and Spring 3.0
Title: Re: JPPF Task with Spring/Hibernate - Classloading Issue?
Post by: lolo on November 27, 2013, 08:02:39 AM
Hello Speedophot,

I was able to reproduce the same issue with very simple code, without Hibernate. This is a bug in the JPPF class loader, for which I registered a bug report: JPPF-203 Class loader resource cache generates duplicate resources (http://www.jppf.org/tracker/tbg/jppf/issues/JPPF-203)

My plan is to fix this bug asap and publish a JPPF 3.3.7 maintenance release by Monday, december 2nd.

For clarification, the "_n" suffixes on some of the temp folder names are intended to handle the case when a resource is actually present multiple times in the classpath, for instance in multiple jars. A call to ClassLoader.getResources() then returns multiple URLs. Since the JPPF class loader caches these resources on disk to avoid unnecessary network round trips, it has to put each found resource in a separate folder.

Sincerely,
-Laurent
Title: Re: JPPF Task with Spring/Hibernate - Classloading Issue?
Post by: speedophot on November 27, 2013, 01:37:07 PM
Hello Laurent,

thank you for your fast response! After playing around for some time and reading the docs I found a workaround. When the executing node is configured to cache resources in the memory and not on disk, the persistence.xml is read only once and the Task works well.

Code: [Select]
# either “file” (the default) or “memory”
jppf.resource.cache.storage = memory

Regards,
Speedophot
Title: Re: JPPF Task with Spring/Hibernate - Classloading Issue?
Post by: lolo on November 28, 2013, 07:39:36 AM
Excellent! I totally didn't think of this.

The other good news is that I was able to fix the bug earlier than expected and it is now part of JPPF 3.3.7, which was just released.

Sincerely,
-Laurent
Title: Re: JPPF Task with Spring/Hibernate - Classloading Issue?
Post by: speedophot on December 11, 2013, 11:05:18 AM
Hello Laurent,

thank you for this quick response. We upgraded to 3.3.7 today and everything works fine.

Regrads,
Speedophot