Re: Experiences with pl/Java - Mailing list pgsql-general

I don't know much about PostgreSQL with plJava, but I can give a few
tips about memory stability when using Java (see inline):

Em 19/11/2012 14:55, Achilleas Mantzios escreveu:
> Hello Peter, glad to meet you again after http://2012.pgconf.eu !
>
> On Δευ 19 �οε 2012 16:26:56 you wrote:
>> On 19 November 2012 08:02, Thomas Hill <Thomas.K.Hill@t-online.de> wrote:
>>> was wondering if there is anyone wanted to share some experiences gained and
>>> some knowledge on pl/Java. Have looked into it for a couple of days now and
>>> am getting the impression it is not something ready to use in production
>>> environment. Also have trouble sending to the developer mailing list (the
>>> last email on the mail archive of that list is almost three weeks old) which
>>> raises questions on how active this project is.
>> I'd caution you against using pl/java in production. I came up against
>> a problem with it that I could not find a satisfactory solution for.
>>
>> Essentially, each Postgres backend (connection process) must start its
>> own JVM, and does so using the JNI. If native memory runs out (I
>> realise that this may not actually be due to malloc() returning NULL,
>> but the effect is about the same), this failure is handled rather
>> poorly. It results in an OutOfMemoryError due to "native memory
>> exhaustion".
> This is the situation in J2EE app servers as well, once OutOfMemoryError is thrown
> there is not much the admin can do besides killing/restarting the app server.

If you uses JDK 6, would worth make a test using JRockit - it's memory
management is far more stable than default Oracle/Sun JVM.
I've servers that run for months without restart, even reloading classes
to accomodate code changes.
The biggest problem with JVM is class reloading, since nursery is not
garbage collected (or, at least, is not effective as it should be).
JRockit uses a different approach, so it's not affected by this problem.
But eventually even JRockit will run out of memory if you don't use the
right approach.
In the past, one choice was using static classes whenever possible. This
is not true (neither recommended) anymore, and in most of the cases
having thousands of cicles creation-use-release makes GC more effective
(and your VM more stable).

>
>> This results in a segfault of the Postgres backend,
>> originating from within libjvm.so. There is a workaround - which is to
>> set the maximum JVM heap size to a sufficiently low value -
> Wouldn't that just make the problem manifest itself earlier?
>
>> but in
>> general the need to do so left me with a very low opinion of pl/java
>> as a project.
>>
>>
> However, in most cases this error denotes a system (jvm itself) memory leak,
> an insufficient garbage collector operation or a poorly designed application.
> In the java 7, i heard good stories about the new G1 garbage collector.

I've been using JDK 7 with G1 GC for hosting NetBeans and Tomcat, and
once you don't have lots of class reload, you get a stable environment.
JDK 7 still suffer of nursery (or whatever the new name they put in)
issues, and classes are not properly disposed. I don't even think this
is a Java issue - most Object Oriented Virtual Machines that relay on
garbage collection suffer of the same issue (references are kept and
then objects are never released, so classes cannot be disposed).

Regards,

Edson Richter


>
> We have never tried pl/java, despite being a postgresql/java house, and this is definitely
> something we are looking forward to explore, but i agree with Thomas that the traffic on the list
> is low which points to what Peter is suggesting about being scared to use this in production environments.
> That would be very cool if it was much more active and stable.
>
> -
> Achilleas Mantzios
> IT DEV
> IT DEPT
> Dynacom Tankers Mgmt
>
>