Re: Remove usage of finalizers ?

Am 21.10.2013 um 08:29 schrieb Vitalii Tymchyshyn:

> Long finalized queue means that some of your objects finalizes long. This means that either you don't close some of
yourstatements explicitly or you have different type  

Actually this is a false assumption. The finalizer daemon thread has a low priority and can sometimes
not keep up with the most trivial cases. See e.g. http://www.fasterj.com/articles/finalizer1.shtml

And yes, closing statements and other objects (e.g. LOBs) explicitly makes a lot of sense.


> of objects (even if it's small number) that take long time to finalize. Check stack trace of finalized thread.
> As of driver, removing finalize altogether is not good as statements won't be closing implicitly. Possible options
are:
> 1) Move processing out of finalizer thread with reference queues.
> 2) Warn when something is implicitly closed to indicate usage problem.

That is what I meant: have 2 drivers:

- one for devlopment that does the warning in the finalizer and the closing, but very loud warning
- one for production where the finalize() methods are gone.

Again: there is no guarantee that a finalize() method is ever called from the JVM. So relying on
it may create bogus results

>
> 20 жовт. 2013 23:33, користувач "Heiko W. Rupp" <hwr@pilhuhn.de> написав:
> Hey,
>
> the other day we ran into a situation where our app ran into a OOME situation on heavy
> load. It turned out that we had around 290k objects on the Finalizer queue, that
> were Statements.
>
> There has been a discussion in the past about finalizers (
> see e.g. around  http://www.postgresql.org/message-id/BCD42993-CB7B-453F-95B4-09E84A956AB0@me.com ).
>
> I understand that Connection objects are supposed implement a finalizer (is that actually true?),
> but here the penalty is not that high, as Connections usually are pooled and are thus long living.
>
> Other JDBC objects like Statements are extremely short lived and the creation rate can be
> on a busy application much higher than the finalization rate (which is what we were seeing).
>
> So I wonder if the driver could be rewritten in a way that either
> - uses no finalizers for the short lived objects
> or
> - exist in 2 flavors: a debug version that does excessive logging in the
>  finalizer if the objects were not yet closed (and stays as is wrt the extra work)
>  and a production version where
>  the finalize() methods are removed, so that the objects do not end up
>  in the finalizer queue and can't pile up under high load.
>
> Developers could then use the devel version and the other driver for production.
>
> Relying on the finalize() method to close/free objects on the PG server is a bad
> idea anyway, as there is no guarantee when finalizers run or if they run at all.
>
>   Thanks
>        Heiko
>
>
> --
> Heiko Rupp   hwr@pilhuhn.de
> Blog: http://pilhuhn.blogspot.com   @pilhuhn
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

--
Heiko Rupp   hwr@pilhuhn.de
Blog: http://pilhuhn.blogspot.com   @pilhuhn