Hmmm.. I'm not sure these are exactly the same bug. The original user wasn't using Handles the way that I am. In any case, it appears that on the Handle.getEJBObject() (from a remote client) is incrementing the refcount on the QueuedPessimisticEJBLock twice, and releasing it only once.
Anyways, I've appended these emails to that bug as asked. If I can provide any further help in tracking this down, just let me know. I'm rather anxious to get this one solved, as it's causing a memory leak for us... Thanks Russ On Wed, Jan 28, 2004 at 02:56:23PM -0600, Scott M Stark wrote: > This is related to an issue: [ 780746 ] Unable to passivate due > that has not had a good testcase. Provide this info in that bug > report and I'll look into it again. > > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Russell > Chan > Sent: Friday, January 23, 2004 12:37 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-user] Possible bug in Handle.getEJBObject() - Jboss > 3.2.3 > > Hi, > > 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. > > > > > -- > -- > Russell Chan, > Navaho Networks Inc. > 416 542 1590 x108 > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > -- -- Russell Chan, Navaho Networks Inc. 416 542 1590 x108 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
