Bug #9391 for ResourcePool: UsedPool hash keys are stringified

Tue Jan 04 08:02:20 2005 Guest - Ticket created

Subject:

UsedPool hash keys are stringified

In the UsedPool structure of the ResourcePool object, objects are stored as hash keys. Given two objects that stringify to the same thing this could be problematic. Please use Tie::RefHash, and replace $self->{UsedPool} = {}; with tie %{ $self->{UsedPool} }, 'Tie::RefHash'; to get more correct behavior. The current implementation also implies that a reference to the object is not kept. This implies that the object is unrecoverably destroyed, leaving it's associated ::Resource object still alive in the value of the hash, if whoever took the resource doesn't free it, but simply loses it. This behavior is partially rectified, by at least making the leak preserve a consistent data structure. You might instead use Tie::RefHash::Weak, and then the ::Resource object might get DESTROYed eventually (or immediately, if I ever get around to learning XS).

Wed Jan 05 15:13:16 2005 mws [...] cpan.org - Correspondence added

I have fixed the RefHash issue as described above (1.0104 just sent to CPAN). Regarding the other issue, I am not sure If i got your right. However, I consider it a bug of the one who uses ResourcePool if the resources are not returned to the pool. I have actually never planned a automatic recovery of such "user bugs". However I did consider building a debug utility to make it more easy to find such bugs. A way to mutally prevent the user from this "leak risk" is by using the Command framework.

Wed Jan 05 15:13:17 2005 mws [...] cpan.org - Status changed from 'new' to 'resolved'

Thu Jan 06 16:22:43 2005 Guest - Correspondence added

From:

nothingmuch [...] woobling.org

[MWS - Wed Jan 5 15:13:16 2005]: Show quoted text

> Regarding the other issue, I am not sure If i got your right. However, I > consider it a bug of the one who uses ResourcePool if the resources are > not returned to the pool.

What I meant was that in it's current state the behavior was dichotomic: since the object that is the key is refcounted to zero, it's destroyed, but the stringified key is still there. Since the object doesn't exist anymore, the value is no longer accessed, and remains. This is resolved by using any Tie::RefHash. With Tie::RefHash the key object isn't destroyed at all, even if the user throws it away. With Tie::RefHash::Weak the value is destroyed sometime after the key object is destroyed (though in it's current state not immediately). In both cases this is a "user bug", so I guess this doesn't really matter which one you use. It's a matter of taste, I guess. Objects that are supposed to be cached, but are destroyed all of a sudden (::Weak) is not a nice behavior sometimes, but leaving unused parts of the cache opened (leaking?) is not nice behavior either. Since it's the user's fault I'd just leave it as it is now, with Tie::RefHash. Thanks! Show quoted text

> I have actually never planned a automatic recovery of such "user bugs". > However I did consider building a debug utility to make it more easy to > find such bugs.

Is that still under consideration?

Thu Jan 06 16:22:46 2005 The RT System itself - Status changed from 'resolved' to 'open'

Thu Jan 06 16:27:34 2005 Guest - Correspondence added

From:

nothingmuch [...] woobling.org

Oh, btw: V1.0104 - 2003-05-07 Today was 2004-01-06 ;-)

Fri Jan 07 02:13:17 2005 mws [...] cpan.org - Correspondence added

ok, i now understand the "second" issue, but think it was not an issue because at least the ::Resource usually holds a real reference to the plain resource. as explaind before i don't think its a good idea to build something in which siently "fixes" user bugs. regarding debuging help for leaks. i thought i could implement a debug flag, when set i take a Backtrace in the get() method and store it somewhere. when the resource is free() or fail()ed i throw away the stack trace. further a new method would be required (or on DESTROY and similar) to print all the stack traces for the resources currently used. so it would be easy to call this new method whenever you believe there should be no resources used and receive the stacktrace where you obtained the resource without giving it back. it's actually just a question of time to do it.

Fri Jan 07 02:13:17 2005 mws [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Jan 07 02:15:17 2005 mws [...] cpan.org - Fixed in 1.0104 added