[GLASSFISH-5127] stateful session beans not getting passivated Created: 10/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: rajbirb Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File Client.jar     Zip Archive Client_src.zip     Java Archive File statefulPassivation.jar     Zip Archive statefulPassivation_src.zip    
Issuezilla Id: 5,127

 Description   

Stateful session beans are not getting passivated. The bean's cache size is set
to be 1(one) in sun-ejb-jar.xml. The bean is looked up twice from a java client
and some business method invoked on it. Monitoring the application server
through console, it can be seen that the 'NumBeansInCache' keeps on increasing
on each re-run of the client. Also 'NumPassivationSuccess' is always 0(zero).

Also tried configuring the EJB container to set the 'Maximum Pool Size' and
'Maximum Pool Size' equal to 1. But the result is same.

Steps to recreate:
1. Deploy statefulPassivation.jar on the server
2. Enable monitoring for EJB Container
3. Run java -jar Client.jar with system property set for
'java.naming.factory.initial'

Check value of 'NumBeansInCache' in application server monitor and also no SOPs
given in prePassivate and postActivate callbacks appearing in logs.



 Comments   
Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1546)
test ejb application

Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1547)
sources for test ejb application

Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1548)
client for the test application

Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1549)
client sources

Comment by Mahesh Kannan [ 05/Jan/09 ]

For performance reasons the container passivates beans only if the number of
beans to be passivated is more than 8. The number 8 has was decided purely based
on performance benchmarks that were done with earlier releases.

In this case, there is only one bean that needs to be passivated and hence the
container didn't call ejbPassivate.

Also, the tunnings (max-cache-size etc.) are mainly used to controll the beans
under heavy loads.

This is not a bug at all. I am moving this as an enhancement and also reducing
the priority.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Mon Sep 26 06:50:49 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.