[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ojb-user
Subject:    Re: Finding Broker/Connection leak
From:       Armin Waibel <arminw () apache ! org>
Date:       2006-08-02 10:57:37
Message-ID: 44D08521.4000409 () apache ! org
[Download RAW message or body]

Tino Schöllhorn wrote:
> Dear Armin,
> 
> thanks for your reply. I will try to integrate the finalize()-code in 
> our PB.
> 
> Is there somewhere a document of the history of changes of OJB 1.0.1 to 
> the current released version? I'm asking because we are thinking of 
> moving to the current version and I want to estimate the impact to our 
> system.
> 

Normally all changes are documented in the release-notes.
http://db.apache.org/ojb/release-notes.txt

There is only one fault in 1.0.4 release notes section. I forget to 
document a change in sequence/identity handling (if you force 
computation of unique values).
http://www.mail-archive.com/ojb-user%40db.apache.org/msg15405.html

To get an impression of the changes made for the upcoming version (OJB 
1.0.5, SVN OJB_1_0_RELEASE branch) have a look here
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/release-notes.txt?revision=421042&view=markup


regards
Armin


> With regards
> Tino
> 
> Armin Waibel wrote:
> > Hi Tino,
> > 
> > Tino Schöllhorn wrote:
> > > Hi,
> > > 
> > > I have a situation where we are running out of PersistenceBrokers 
> > > (using 1.0.1). We have a web application which so far runs fine - but 
> > > somehow some requests are causing the application not to close its PB.
> > > 
> > > We can see this when we are monitoring the used connections of mysql 
> > > which are slowly growing - even if we are using ConnectionPooling. 
> > > These  connection are on the state SLEEP for quite a long time and 
> > > seem never to be closed.
> > > 
> > > At some point the application runs out of PB (we are using size 100 
> > > of the PB-Pool).
> > > 
> > > So it seems (quite obviously) that some PBs are not cleanly handled.
> > > 
> > > Do you have any advice for us finding those leaks?
> > > 
> > 
> > In current versions there is no PB leak detection. Such a feature will
> > be part of the next version (or try latest from SVN OJB_1_0_RELEASE 
> > branch).
> > It would be possible to modify your 1.0.1 version to support broker 
> > leak detection. Have a look in latest PBImpl (OJB_1_0_RELEASE branch) 
> > and port the detection part in method PBimpl#setClosed and 
> > PBImpl#finalize to your class.
> > http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/core/PersistenceBrokerImpl.java?revision=398752&view=markup \
> >  
> > 
> > 
> > > Does it do any good when we "tune" mysql that it discards connections 
> > > which are quite old (via property "max_timeout")? Is OJB discaring 
> > > those PBs whose connections have died ?
> > 
> > If you correctly use the PB instances (lookup PB instance when needed, 
> > close it after use) the connection pool should handle connections in a 
> > correct way.
> > But if you don't close PB instances after a query, the connection will 
> > still be associated with the PB instance, please see
> > 
> > http://www.mail-archive.com/ojb-user%40db.apache.org/msg15389.html
> > 
> > regards,
> > Armin
> > 
> > > 
> > > I am glad for any suggestions.
> > > 
> > > Tino
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > > For additional commands, e-mail: ojb-user-help@db.apache.org
> > > 
> > > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic