Colin. Christian Riege found the problem. > -----Original Message----- > From: Colin Daly [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 9:16 PM > To: Bill Burke; [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] out of memory > > > > Hi Bill, > > thank you for the quick response. > to answer your question, i'm not > doing the import within one transaction. > the client repeatedly calls the createTestAddress > method on the stateless session bean. > > i reduced the entity cache size from 1000 to 10 > and confirmed that the problem remained. > i've noticed that if i remove the address entity > after creation by adding > addressEJB.remove(); > to the end of createTestAddress, the problem > disappears. This is consistent with what you > said about the locks remaining while the entity > remained cached. > My question then is, if I don't call remove on > the entity bean, how do the beans ever get > removed from the cache. > > /** > * @ejb:interface-method > */ > public void createTestAddress() throws RemoteException > { > > try { > AddressModel address = new AddressModel(new > AddressEJBData(null, > "line1", "line2", false, "suburb", "state", "postcode", "country")); > AddressEJBLocal addressEJB = > createAddress(address); > } catch (Exception e) { > throw new RemoteException("error creating test > address", e); > } > } > > private AddressEJBLocal createAddress(AddressModel > theAddressModel) > throws NamingException, CreateException, SQLException > { > > AddressEJBLocal address = > AddressEJBUtil.getLocalHome().create( > theAddressModel.getLine1(), > theAddressModel.getLine2(), > theAddressModel.getPOBox(), theAddressModel.getSuburb(), > theAddressModel.getState(), theAddressModel.getPostcode(), > theAddressModel.getCountry()); > return address; > } > > > Colin. > > > On Wed, 9 Jan 2002 10:52, you wrote: > > The locks will stay in memory as long as the EntityBean is > cached. How > > many Entity Beans are you querying and loading up? Make > sure you're not > > doing this in one transaction. Also, Remember. Stateless > bean methods are > > Required by default. If you do your "sucking" your > Entities within a > > Stateless bean call, you may be overloading it. Can you > send me the test > > case creates this problem? > > > > ----- Original Message ----- > > From: Colin Daly <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, January 09, 2002 12:41 AM > > Subject: [JBoss-dev] out of memory > > > > > Hi all, > > > > > > we are running JBoss-2.4.4_Tomcat-4.0.1-beta/jboss > > > with version 1.0 of the persistence manager from MVCSoft. > > > after experiencing OutOfMemory problems with a batch > > > program which sucks data out of a legacy database and > > > into postgresql through the EJB layer, i ran up Optimizeit > > > and discovered that the source of the "leak" is instances > > > of the following class are never getting garbage collected. > > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > > > > > > I wrote a simple test client which just repeatedly called a > > > stateless session bean method called createAddress which > > > creates a simple cmp (no cmr) entity bean. The same > > > problem occurred. Please refer to the attached file (data.txt) > > > for the allocation backtrace of > > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > > > in this simple test. > > > > > > I've tried debugging this but to be perfectly honest I'm > > > a little out of my depth here. It appears the reference > > > counts for the locks never reaches zero and therefore > > > the removeLockRef in the BeanLockManager never > > > actually removes the lock from the map. > > > > > > If anyone can help me on this, I would really appreciate > > > it. I'm not quite sure what to do next. Any suggestions > > > would be great. > > > > > > regards, > > > Colin Daly.
_______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
