[JBoss-dev] [ jboss-Bugs-780746 ] Unable to passivate due

[SourceForge.net <no...@so...>]

Bugs item #780746, was opened at 2003-07-31 05:55
Message generated for change (Comment added) made by rmchan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=780746&group_id=22866

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Meyer (mmrmichael)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to passivate due

Initial Comment:

OS : Linux
JDK : 1.4.2
JBoss Version : 3.2.2 RC1 

I got the following error (on console) :

WARN [AbstractInstanceCache] Unable to passivate due to
ctx lock, id = xxx.

The result of this error is the complete use of memory
and I have to restart the server.


Michael Meyer


----------------------------------------------------------------------

Comment By: Russell Chan (rmchan)
Date: 2004-01-28 19:32

Message:
Logged In: YES 
user_id=793049

Hi,

Scott, here's the original email.

For further info, I can email you the little test case that
I use, (needs xdoclet and ant to build), but I happen to use
jython (Java python - www.jython.org) to test it.  (This, of
course, is a remote not-in VM program).

My very simple jython/python test is as follows

-- script start --
ic = InitialContext()
bhome = ic.lookup("ejb/TestSFSB")
b1 = bhome.create(1)
handle = b1.getHandle()
# everything is fine up to here....

b2 = handle.getEJBObject()

#as soon as I ussue the above  command, the 
#unable to passivates start showing up.

--script end--



I can email you a tarred version of the build tree for test
bean, but it's really nothing more than a stateful bean with
the default container settings.

I'd attach something, but this sourceforge interface doesn't
appear to let me do that.


Some more info that I also posted to the list:

--Email start--
Some more info... This behaviour happens regardless of being
in a
transaction...
                                                           
                                                                
If I run a jython (python in a java interpreter - useful for
testing!)
connecting to the jboss server, I get the "Unable to
passivate" message as soon as I call handle.getEJBObject()
from the remote client, and the passivation thread runs.
                                                           
                                                                
The jboss management console just shows the 
statefulSessionInstanceCache for the stateful bean growing
larger and larger as more instances of the stateful bean are
created.
                                                           
                                                                
The pool management works fine, however.
--Email end--


>
> I've been wrestling with this problem for a little while.
>
> Environment: JBoss 3.2.3, Sun JDK 1.4.2_01 on linux (debian)
>
> I have a stateful bean which appears to work fine for the
most part.
> I can generally do some operations on it, within a
transaction, and then
> remove the bean.  I've set the passivation time very low
(20 secs) as
> well as the expiry times on the bean as below:
>
>                <remover-period>10</remover-period>
>                <overager-period>10</overager-period>
>                <max-bean-life>60</max-bean-life>
>                <max-bean-age>20</max-bean-age>
>
>
> I've found one case however, where this can cause a
problem.  If I get a
> handle from the stateful bean, in order to use it (
possibly to put in
> an HTTPSession, or someother) that works fine.
>
> Restoring the bean (and possibly activating it) from the
container also
> works fine.  HOWEVER, I have found that if the remote stub
does that,
> OUTSIDE of a transaction context, there is a ref lock left
on the
> stateful session bean, and from there it won't passivate
properly - is
> this proper behaviour??  (BTW, I haven't yet tried this
within a
> UserTransaction).
>
>
> Lots of warning like this:
>
> 15:20:32,559 WARN  [AbstractInstanceCache] Unable to
passivate due to
> ctx lock, id=dpsp9lca-7
> 15:20:52,597 WARN  [AbstractInstanceCache] Unable to
passivate due to
> ctx lock, id=dpsp9lca-7
> 15:21:12,639 WARN  [AbstractInstanceCache] Unable to
passivate due to
> ctx lock, id=dpsp9lca-7
>
> There's some more detail in the  snippet of log attached.



Here's the log...

> 2004-01-23 15:20:06,567 DEBUG
[org.jboss.ejb.plugins.LogInterceptor] InvokeHome:
getEJBObject(dpsp9lca-7)
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] Current transaction
in MI is null
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] TX_REQUIRED for
getEJBObject
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] Thread came in with
tx null
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] Starting new tx
TransactionImpl:XidImpl [FormatId=257, GlobalId=blade//41,
BranchQual=]
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
HOMEMETHOD coming in
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
public abstract javax.ejb.EJBObject
javax.ejb.Handle.getEJBObject() throws java.rmi.RemoteException
> 2004-01-23 15:20:06,567 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
HOMEMETHOD coming in hashcode1665852439
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
HOMEMETHOD coming in classloader12546448
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
CONTAINS true
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
HOMEMETHOD m public javax.ejb.EJBObject
org.jboss.ejb.StatefulSessionContainer.getEJBObject(org.jboss.invocation.Invocation)
throws java.rmi.RemoteException
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
public abstract test.TestSFSB
test.TestSFSBHome.create(java.lang.Integer) throws
javax.ejb.CreateException,java.rmi.RemoteException
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
-1419501933
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
4521906
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
equals false false
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
public abstract test.TestSFSBLocal
test.TestSFSBLocalHome.create(java.lang.Integer) throws
javax.ejb.CreateException
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
625404838
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
4521906
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor]
equals false false
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.BeanLockManager] Created lock:
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@ba007e,
bean=TestSFSB, id=dpsp9lca-7, refs=0, tx=null, synched=null,
timeout=5000, queue=[]
> 2004-01-23 15:20:06,568 TRACE
[org.jboss.ejb.BeanLockManager] Added ref to lock:
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@ba007e,
bean=TestSFSB, id=dpsp9lca-7, refs=1, tx=null, synched=null,
timeout=5000, queue=[]
> 2004-01-23 15:20:06,569 TRACE
[org.jboss.ejb.plugins.TxInterceptorCMT] TxInterceptorCMT:
In finally
> 2004-01-23 15:20:06,569 TRACE
[org.jboss.ejb.plugins.LogInterceptor] End method=getEJBObject
> 2004-01-23 15:20:32,559 TRACE
[org.jboss.ejb.BeanLockManager] Added ref to lock:
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@ba007e,
bean=TestSFSB, id=dpsp9lca-7, refs=2, tx=null, synched=null,
timeout=5000, queue=[]
> 2004-01-23 15:20:32,559 WARN 
[org.jboss.ejb.plugins.AbstractInstanceCache] Unable to
passivate due to ctx lock, id=dpsp9lca-7
> 2004-01-23 15:20:32,559 TRACE
[org.jboss.ejb.BeanLockManager] Remove ref
lock:org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@ba007e,
bean=TestSFSB, id=dpsp9lca-7, refs=1, tx=null, synched=null,
timeout=5000, queue=[]
> 2004-01-23 15:20:52,597 TRACE
[org.jboss.ejb.BeanLockManager] Added ref to lock:
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@ba007e,
bean=TestSFSB, id=dpsp9lca-7, refs=2, tx=null, synched=null,
timeout=5000, queue=[]
> 2004-01-23 15:20:52,597 WARN 
[org.jboss.ejb.plugins.AbstractInstanceCache] Unable to
passivate due to ctx lock, id=dpsp9lca-7
> 2004-01-23 15:20:52,597 TRACE
[org.jboss.ejb.BeanLockManager] Remove ref
lock:org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@ba007e,
bean=TestSFSB, id=dpsp9lca-7, refs=1, tx=null, synched=null,
timeout=5000, queue=[]
 


----------------------------------------------------------------------

Comment By: Stephen Coy (scoy)
Date: 2003-08-05 04:18

Message:
Logged In: YES 
user_id=463096

I am seeing these in a 3.2.2RC3 build after an EJBException  was 
thrown from a SLSB through a CMP 2.0 entity bean - causing a 
transaction rollback.

Transaction locks are not being released following an exception 
somewhere. Further attempts to access the entity result in a hang 
at:

"Thread-5" daemon prio=5 tid=0x03fbf620 nid=0x5373c10 
runnable [f098e000..f0992b70]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x670faf88> (a 
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock$TxLock)
        at 
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.waitForTx(Qu
euedPessimisticEJBLock.java:301)
        - locked <0x670faf88> (a 
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock$TxLock)
        at 
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(Q
ueuedPessimisticEJBLock.java:209)
        at 
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(Que
uedPessimisticEJBLock.java:157)
        at 
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterc
eptor.java:85)
        at 
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreati
onInterceptor.java:53)
        at 
org.jboss.ejb.plugins.AbstractInterceptor.invoke(AbstractIntercepto
r.java:94)
...

This particular entity is configured to use "Commit Option A" for 
what it is worth.

After a while I see the "Unable to passivate..." warnings from 
other related (thru CMR) entities that were implicated in the 
original transaction.



----------------------------------------------------------------------

Comment By: Scott M Stark (starksm)
Date: 2003-08-01 22:50

Message:
Logged In: YES 
user_id=175228

Yes, but the testcases causing these are largely exceptional
cases and do not neccessarily result in leaks. 

----------------------------------------------------------------------

Comment By: Stefan Reich (sreich)
Date: 2003-08-01 18:20

Message:
Logged In: YES 
user_id=429729

When you run the test suite you will find several similar warnings 
in the log files.

----------------------------------------------------------------------

Comment By: Scott M Stark (starksm)
Date: 2003-08-01 13:11

Message:
Logged In: YES 
user_id=175228

That does not help. Describe the use cases of the stateful
session bean that are leading to its passiviation with a tx
lock and include the full stacktraces of the failure.

----------------------------------------------------------------------

Comment By: Michael Meyer (mmrmichael)
Date: 2003-08-01 03:33

Message:
Logged In: YES 
user_id=605914

We are running MySql 4.1 MAX as backend and inside the 
jetty container we are running cocoon (latest version 2.1)

----------------------------------------------------------------------

Comment By: Scott M Stark (starksm)
Date: 2003-07-31 10:39

Message:
Logged In: YES 
user_id=175228

Provide an testcase or at least some context for this. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=780746&group_id=22866