CPU spinning, stuck on getResultList()

Description

I've got a web application which is well tested (JMeter etc), and suddenly today, 2 of JBoss threads were stuck on a getResultList(), using 100% of the CPU.

Here is the stack for each of the threads :

I've seen some similar problems here JGRP-525 and here JBMESSAGING-1676 and they are talking about concurrency ...

Environment

Hibernate Annotations 3.4.0.GA, Hibernate 3.3.1.GA, Hibernate Commons Annotations 3.1.0.GA, Hibernate EntityManager 3.4.0.GA, Seam 2.2.1.Final, JBoss 5.1.0.GA, Windows Server 2008 64bits, Microsoft SQL Server 10.00.4000, JDBC driver: Microsoft SQL Server 2005 JDBC Driver, version: 1.2.2828.100

Activity

Show:
Pawel Omelko
February 29, 2012, 9:26 AM

Yes, the second request was sent with the same jsessionid, but AFAIK it doesn't means that they are using the same hibernate session. OpenSessionInViewInterceptor is opening session per request not per http session. Am I right or I missed something?

Guenther Demetz
March 2, 2012, 11:06 PM

Im not familiar with Spring but the JavaDoc of OpenSessionInViewInterceptor make me doubt
whether it is really opening a new session per request:

---------------------------------------------------------------------------------- This class is a concrete expression of the "Open Session in View" pattern, which is a pattern that allows for the lazy loading of associations in web views despite the original transactions already being completed.
----------------------------------------------------------------------------------
If this pattern allows lazy loading of associations then it must re-use hibernate sessions instead to open a new session with each request. In such configuration the second request used the same session as the first request used.
Are you using OpenSessionInViewInterceptor.singleSession set to true or to false?

Shawn Gardner
September 17, 2013, 2:43 PM

This issue is a bit old, but we never found a discussion of possible causes so thought we would relay our experiences.

We had a very similar issue where two concurrent threads would enter an infinite loop of HashMap.put, caused by multi-thread access of a single StatefulPersistenceContext. After much debugging, we stepped back to realize we were caching a Hibernate object in a vanilla ehCache (via @Cacheable) used across requests. Since the actual cached value was not Hibernate-managed, we missed the fact that it contained a Hibernate entity deep in its object graph for quite a while. Since each request had an underlying Hibernate session, there was not a "no hibernate session bound to current thread" exception.

All credit goes to my colleague Jon Riegel.

Brett Meyer
April 8, 2014, 3:47 AM

In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.

If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.

Thank you!

Brett Meyer
July 9, 2014, 1:10 AM

Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!

Rejected

Assignee

Unassigned

Reporter

Anthony Ogier

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major