From: Darryl M. (JIRA) <no...@at...> - 2006-02-11 00:34:14
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_22100 ] Darryl Miles commented on HHH-1293: ----------------------------------- I'd agree with the outline info, it doesn't appear to happen right away but after a while of use. Versions here: Multi-CPU SMP Intel x86 machine Linux 2.6.12.2 Kernel (libc-2.3.4, NPTL) Sun JVM build 1.5.0_06-b05, mixed mode Hibernate 3.1.2 (with cglib 2.1.3, commons-collections-3.1, ...) Tomcat 5.5.15 I think the mode the JVM runs in the default one, the application runs within tomcat. Application Outline: There are multiple threads in play, each thread has its own Session to work with. These threads are fairly long running, they run for ~15 mins, only do 5 seconds of work in that time. Each thread gets its own Session instance soon after it starts and will keep it until the thread terminates. Transaction state is managed inside the relevant worker method, most of the wall clock time is spent with an open Session but no active transaction context and no uncommitted dirty data. hibernate.transaction.auto_close_session=false I dont get any NoMethodException within 3 to 4 minutes of firing up the application, even through within 30 seconds everything is running and hot and the same code path that throw out exceptions later have been executed at least a few times. If its a hotspot issue, how does hotspot decide to do its work. Does adding a simple Thread.sleep() delay to slow down your reproducable application after the point when the problem occurs. I really dont believe my code gets many iterations before I get the error, but what does happen is a lot of waiting and delays between iterations. http://opensource2.atlassian.com/projects/hibernate/browse/HHH-1293#action_21914 by Chris Hane <== is that a working Single Thread example ? Is it possible to snapshot the VM with $JAVA_HOME/bin/* tools to work out whats -Xint, client, server at any given moment ? I'm just auditing my app code, to make sure it is not possible for one thread to hand another thread a proxied object, and then the source thread shutdown (causing a Session.close()) I dont think this is the case for me. > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35) > at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130) > at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48) > at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |