Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Hibernate query timeout issue
PostPosted: Wed May 17, 2017 7:34 am 
Newbie

Joined: Wed May 17, 2017 4:54 am
Posts: 2
Hello everyone!
We have a application with a process which has a lot of things to calculate a date for a case file.
The architecture is Hibernate 3.0.5 working with Spring 2.0.5 in a Weblogic Server 11.
What happen? we experience a timeout but we don't know the reason.
We suspect something related with Hibernate due to the trace. But there are many reasons or kind of trace for the timeout.
We haven't got blocked tables or rows.
Looking the stack packs we see that the top five of querys take at most 4'.

Quote:
<Error> <WebLogicServer> <[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "677" seconds working on the request "Http Request: /gs_intranet/altaSolicitud.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.lang.Class.isInstance(Native Method)
org.hibernate.tuple.PojoInstantiator.isInstance(PojoInstantiator.java:89)
org.hibernate.tuple.AbstractTuplizer.isInstance(AbstractTuplizer.java:240)
org.hibernate.persister.entity.BasicEntityPersister.isInstance(BasicEntityPersister.java:2963)
org.hibernate.loader.Loader.instanceAlreadyLoaded(Loader.java:889)
org.hibernate.loader.Loader.getRow(Loader.java:846)
org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:305)
org.hibernate.loader.Loader.doQuery(Loader.java:412)
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:218)
org.hibernate.loader.Loader.doList(Loader.java:1593)
org.hibernate.loader.Loader.list(Loader.java:1577)
org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:111)
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1322)

ANOTHER
Quote:
<[STUCK] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "675" seconds working on the request "Http Request: /gs_intranet/altaSolicitud.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
org.hibernate.util.IdentityMap.entryList(IdentityMap.java:184)
org.hibernate.util.IdentityMap.entries(IdentityMap.java:63)
org.hibernate.event.def.AbstractFlushingEventListener.prepareCollectionFlushes(AbstractFlushingEventListener.java:152)
org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:63)
org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:39)
org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:711)
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1315)
org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:300)
org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:433)

ANOTHER
Quote:
<[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "659" seconds working on the request "Http Request: /gs_intranet/altaSolicitud.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.lang.Object.clone(Native Method)
java.lang.reflect.Method.getParameterTypes(Method.java:246)
org.hibernate.proxy.BasicLazyInitializer.invoke(BasicLazyInitializer.java:49)
org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:132)
net.gene.trb.gs.model.Municipi$$EnhancerByCGLIB$$8e440483.getHibernateLazyInitializer(<generated>)
org.hibernate.Hibernate.isInitialized(Hibernate.java:305)
org.hibernate.engine.PersistenceContext.reassociateIfUninitializedProxy(PersistenceContext.java:483)
org.hibernate.event.def.ProxyVisitor.processEntity(ProxyVisitor.java:27)
org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:107)
org.hibernate.event.def.WrapVisitor.processValue(WrapVisitor.java:97)
org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java:58)
org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:104)
org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:190)
org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:70)
org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:39)
org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:711)
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1315)
org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:300)
org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:433)

Thanks in advice any help.


Top
 Profile  
 
 Post subject: Re: Timeout may be related with Hibernate 3.0.5
PostPosted: Wed May 17, 2017 8:53 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1275
It's not Hibernate that generates the timeout, it's the SQL query that it executes that takes too long:

Code:
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1315)
org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:300)
org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:433)


So, you need to find the underlying query by enabling JDBC logging, and just tune it to run faster:

- check the execution plan and apply proper indexes
- make sure you select just as much data as you need (pagination, DTO projection)

_________________
If you liked my answer, you are going to love my High-Performance Java Persistence book and my blog as well.


Top
 Profile  
 
 Post subject: Re: Timeout may be related with Hibernate 3.0.5
PostPosted: Thu May 18, 2017 3:20 am 
Newbie

Joined: Wed May 17, 2017 4:54 am
Posts: 2
vlad wrote:
It's not Hibernate that generates the timeout, it's the SQL query that it executes that takes too long:

Code:
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1315)
org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:300)
org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:433)


So, you need to find the underlying query by enabling JDBC logging, and just tune it to run faster:

- check the execution plan and apply proper indexes
- make sure you select just as much data as you need (pagination, DTO projection)


Hello vlad,
I'll take your advice. I think that the Criteria is penalizing me.
What I can't understand is why the timeout ocurres in differents parts of the code, either in a method or in another.

Thank you very much!


Top
 Profile  
 
 Post subject: Re: Hibernate query timeout issue
PostPosted: Thu May 18, 2017 3:27 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1275
Quote:
I'll take your advice. I think that the Criteria is penalizing me.


You can only be sure if you investigate the actual SQL code that Criteria generates for you.

Quote:
What I can't understand is why the timeout ocurres in differents parts of the code, either in a method or in another.


When database resources are saturated, query execution time will increase and some will generate timeouts. There's even a mathematical explanation for this, it's called Little's Law. Although you wish you can isolate the issue to a single Criteria query, I have a feeling this will require you a deep-level analysis:

- OS metrics
- database metrics
- SQL execution plans

It's easier to tackle this issue if you have a DBA on your team. After all, that's what DevOps is all about. If you don't have a DBA, then you should read High-Performance MySQL or something similar, depending on what DB you run in production.

_________________
If you liked my answer, you are going to love my High-Performance Java Persistence book and my blog as well.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.