RE: Scarab commit: svn commit: r10567 -trunk/src/java/org/tigris/scarab: actions tools xmlrpc

Mick Semb Wever wrote:

Ronny Voelker wrote:
> could you please elaborate how this changes would fix a leaking count?
> At the moment I don't see, how moving the assignment into the 
> try-block removes a leakage.
> I just want to understand :).

>It's not the catch but the final that's important.
>And it's not the actual instances of IssueSearch that's the problem but the numActive count inside IssueSearchFactory.
>Every time the factory returns an IssueSearch numActive is incremented.
>The caller is responsible once finished with the IssueSearch to call IssueSearchFactory.notifyDone() so it can decrement numActive.
>
>Therefore the initial call to IssueSearchFactory must be within the try block to ensure that, even if it crashes and throws an exception,
>notifyDone() is called to finish with.

This may now reduce the counter too much, because when the IssueSearchFactory.getInstance fails, it is not clear, if the failure happened before decrementing the counter or after. So this solution isn't save either.

>Since the default maximum for numActive is 4 it will only take four such occurrences before the application is /dead/ and can no longer execute queries. This is >what i was observing with trunk at http://sesat.no/scarab 

Yes, that's a serious concern. 
IMO the solution is, to change IssueSearchFactory.getInstance, that it is sure that the counter was not incremented, when the method throws an exception and move the call of the method out of the catch-block again.

Btw. I'm not sure if the counter is needed anymore.
In b21 IssueSearch allocated a db-connection for it's whole live-time and had to release it manually before it was garbage-collected.
That contained a high risk, that at some point all db-connection were allocated when some IssueSearchs were not disposed properly.
In the trunk this risk does no more exist, because the db-connection isn't allocated for more than the actual db-query, just as it is for all other db-requests.

Ronny