agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feedSubject: [Pljava-dev] Portal object leak
Date: Tue, 16 Jan 2007 15:24:56 -0800
Message-ID: <401FA771-4DC4-4B7B-B905-021F7B4CC057@hyperstep.com> (raw)
In-Reply-To: <45AD2E2D.4080507@tada.se>
References: <45A85803.1070500@hyperstep.com>
<4508612D-5A18-4C25-B97A-3FF9DCCAD26B@hyperstep.com>
<45AD2E2D.4080507@tada.se>
No problem at all, thank you for getting back to me.
If you think this is on the Java side, I'll be happy to try to debug
and fix it. But if it's a problem in the native code, my C/C++ skills
are, well let's just call them "nonexistent".
I've been assuming that the problem is in the native code because
heap analysis with jhat shows that the Portal objects are JNI global
references without any referrers. Of course, this could simply mean
that the PL/Java JDBC code is failing to call a native cleanup
method. I guess I'm asking for some basic pointers to what the
problem might be in theory before I jump in.
A few specific questions:
1.) With very little C experience, am I wasting my time trying to fix
the issue? I'm just asking for your best guess.
2.) What the heck is a Portal object anyway? Is it a handle to a
result set / cursor?
3.) I noticed there was an update to SPIStatement.java and
SPIDatabaseMetaData.java about 3.5 months ago with the commit message
"Fixed some issues with Meta-data." The updates look like they might
be relevant. Are these updates included in 1.3.0 and/or in the
version of PL/Java that ships with the PG 8.2 Windows installer? I
guess the real question is, am I debugging a problem that's already
been fixed? Since I'm on Windows here and haven't used MinGW before,
I haven't even tried compiling from HEAD.
4.) Would you be open to accepting payment to fix this yourself or do
you simply not have the time? We (my company) think PL/Java is an
ideal solution for our DB logic and it seems quite robust in all but
this one area, so dedicating some of my time and/or paying for a fix
is definitely on the table.
FYI, I've worked around most of the problem by using local caching to
avoid repeated calls to DatabaseMetaData.getPrimaryKeys() and
getImportedKeys(). This solves about 80% of the leak. The other 20%
(also in the form of Portal objects) is still somewhat of a mystery
to me. It seems to happen on JDBC query executions inside the
triggers but I haven't been able to reproduce it in a clean
environment, so I'll come back to it later.
Sorry for the long email and thank you for your time,
-Ryan
On Jan 16, 2007, at 11:57 AM, Thomas Hallgren wrote:
> Hi Ryan,
> Sorry for late reply. I find myself constantly tied up in other
> activities these days. If you have the time to create a patch for
> this I'd be happy to review it.
>
> Kind Regards,
> Thomas Hallgren
>
>
>
> Ryan Holmes wrote:
>> Found one source of the problem. Filed as http://
>> gborg.postgresql.org/ project/pljava/bugs/bugupdate.php?1624
>> -Ryan
>> On Jan 12, 2007, at 7:54 PM, Ryan Holmes wrote:
>>> I have a PL/Java trigger that leaks a large number of
>>> org.postgresql.pljava.internal.Portal objects. The leak occurs under
>>> PostgreSQL 8.1 with PL/Java 1.3.0 and under 8.2 with the version of
>>> PL/Java that is included with the Windows installer. I get the same
>>> results with multiple versions of Windows (XP and Server 2003)
>>> and with
>>> 1.5 and 1.6 JVMs.
>>>
>>> So far, my attempts to isolate the leak have been fruitless (the
>>> code
>>> path is about 500 lines). I can say that from a pure Java
>>> perspective,
>>> there is no obvious reason for the leak. Furthermore, the only
>>> references to the Portal objects are JNI global references so
>>> there is
>>> no chain of references from our code to these objects.
>>>
>>> Does anyone know what could cause PL/Java to create Portal
>>> objects but
>>> not clean them up? At this point, I'm not even sure what I'm
>>> looking for
>>> and the only option I have left is to rebuild or comment out the
>>> code
>>> "one line at a time" until I can isolate the behavior.
>>>
>>> I don't mind posting the code in question (it's a set of auditing
>>> triggers and supporting methods) but, as I mentioned, there's
>>> quite a
>>> bit of it.
>>>
>>> Thanks,
>>> -Ryan
>>> _______________________________________________
>>> Pljava-dev mailing list
>>> Pljava-dev at gborg.postgresql.org
>>> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>
view thread (6+ messages) latest in thread
Message-ID: <401FA771-4DC4-4B7B-B905-021F7B4CC057@hyperstep.com>
Permalink: ../401FA771-4DC4-4B7B-B905-021F7B4CC057@hyperstep.com/
Also on: postgresql.org/message-id/401FA771-4DC4-4B7B-B905-021F7B4CC057@hyperstep.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pljava-dev@postgresql.org
Subject: Re: [Pljava-dev] Portal object leak
In-Reply-To: <401FA771-4DC4-4B7B-B905-021F7B4CC057@hyperstep.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox