Re: Remove usage of finalizers ?

Long finalized queue means that some of your objects finalizes long. This
means that either you don't close some of your statements explicitly or you
have different type 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.
20 жовт. 2013 23:33, користувач "Heiko W. Rupp" <hwr(at)pilhuhn(dot)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(at)pilhuhn(dot)de
> Blog: http://pilhuhn.blogspot.com @pilhuhn
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>