Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 959630

Summary:	Performance regression of passivation: 6.1 compared to 6.0.1
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Jitka Kozana <jkudrnac>
Component:	Clustering	Assignee:	Paul Ferraro <paul.ferraro>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.1.0	CC:	dandread, jdoyle, jkudrnac, lthon, mlittle, myarboro, rjanik, rsvoboda
Target Milestone:	---	Keywords:	Regression
Target Release:	EAP 6.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-21 17:04:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1017827

Description Jitka Kozana 2013-05-04 11:00:30 UTC

While investigating causes of BZ 917512, performance regression of passivation was discovered, eg. with passivation turned on, the performance was much worse compared to 6.0.1. Turning the passivation off brought us back to 6.0.1. numbers. 

See job:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-repl-sync-jgroups-modified/

6.0.1. job: 
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-repl-sync/14/

This issue is *not* a release blocker.

Comment 1 Rostislav Svoboda 2013-05-04 14:45:10 UTC

As Jitka mentions not sure if this is a blocker for release (knowing where we are), but I want the triage team reviews this one.

Comment 2 John Doyle 2013-05-05 14:28:28 UTC

I'm inclined to say this is not a blocker based upon the complexity of testing with passivation on.  I do think we need to continue looking into the regression and figure out a test and configuration we can rely on over time.

Comment 4 Paul Ferraro 2013-05-05 15:29:06 UTC

I'm not going to ack this.  This is anticipated behavior, since we now use pessimistic instead of optimistic locking when passivation enabled.  This is necessary to safely passivate sessions to the cache store  without interference from a cache read/write.

Comment 5 Dimitris Andreadis 2013-05-06 07:00:06 UTC

Also, passivation was not working properly in 6.0.1.

Comment 8 Paul Ferraro 2013-08-29 23:04:19 UTC

Passivation issues are scheduled to be addressed in 6.3 via new web session clustering implementation.

Comment 9 Paul Ferraro 2013-11-21 17:04:13 UTC

I'm closing this.  PESSIMISTIC locking will remain the default for EAP 6.x as well as EAP7 - since it is required to ensure that web session can safely passivate.  Users who do not use passivation can feel free to optimize performance by switching to OPTIMISTIC locking if they want.