SEO

Hi,

I'm experiencing some strange problems with a Java application which I
have made.
Suddently it looses connection with the database, and in the server log
i can find:

2005-04-02 00:09:01 ERROR: invalid string enlargement request size
1358954492
2005-04-02 00:09:01 WARNING: AbortTransaction and not in in-progress
state
2005-04-02 00:09:01 FATAL: invalid frontend message type 82

2005-04-02 07:36:24 ERROR: invalid string enlargement request size
1358954492
2005-04-02 07:36:24 WARNING: AbortTransaction and not in in-progress
state
2005-04-02 07:36:24 FATAL: invalid frontend message type 78

2005-04-02 12:03:08 ERROR: invalid string enlargement request size
1358954492
2005-04-02 12:03:08 WARNING: AbortTransaction and not in in-progress
state
2005-04-02 12:03:08 FATAL: invalid frontend message type 78

Sometimes it can run for days without any problems, but now it has died
3 times today.
The server is running SuSE Linux 9.2, the Postgresql version is 7.4.7
I have tried two different version of the jdbc driver pg74.215.jdbc3.jar
and pg80.310.jdbc3.jar
but it's the same result.

Can anyone tell me what's causing this, please ?


BR, Poul



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

=?UTF-8?B?UG91bCBNw7hsbGVyIEhhbnNlbg==?= <freebsd@pbnet.dk> writes:
> I'm experiencing some strange problems with a Java application which I
> have made.
> Suddently it looses connection with the database, and in the server log
> i can find:

> 2005-04-02 00:09:01 ERROR: invalid string enlargement request size
> 1358954492
> 2005-04-02 00:09:01 WARNING: AbortTransaction and not in in-progress
> state
> 2005-04-02 00:09:01 FATAL: invalid frontend message type 82

This indicates the client code didn't follow the protocol properly,
ie, it sent garbage where a message length word ought to be.

This sort of thing has been seen to occur when multiple client-side
threads try to use the same database connection without proper locking
to ensure only one thread uses it at a time. See for example
http://archives.postgresql.org/pgsql...9/msg00104.php

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

>>2005-04-02 00:09:01 ERROR: invalid string enlargement request size
>>1358954492
>>2005-04-02 00:09:01 WARNING: AbortTransaction and not in in-progress
>>state
>>2005-04-02 00:09:01 FATAL: invalid frontend message type 82
>>
>>
>
>This indicates the client code didn't follow the protocol properly,
>ie, it sent garbage where a message length word ought to be.
>
>This sort of thing has been seen to occur when multiple client-side
>threads try to use the same database connection without proper locking
>to ensure only one thread uses it at a time. See for example
>http://archives.postgresql.org/pgsql...9/msg00104.php
>
> regards, tom lane
>
>
This is exactly what I am doing. Must admit I haven't considered that as
an issue.
For performance reasons I suppose one database connection per client are
preferred
rather than using synchronized on the db class ?

Thanks a lot for bringing it to my attention

BR, Poul

On Sat, 2 Apr 2005, [ISO-8859-1] Poul Møller Hansen wrote:

> >This sort of thing has been seen to occur when multiple client-side
> >threads try to use the same database connection without proper locking
> >to ensure only one thread uses it at a time. See for example
> >http://archives.postgresql.org/pgsql...9/msg00104.php
> >
> This is exactly what I am doing. Must admit I haven't considered that as
> an issue. For performance reasons I suppose one database connection per
> client are preferred rather than using synchronized on the db class ?
>

The JDBC driver should be doing any synchronization necessary for multiple
threads. Could you be more clear what you are doing? What driver
version? Any chance you've got a reproducible example?

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

>>>This sort of thing has been seen to occur when multiple client-side
>>>threads try to use the same database connection without proper locking
>>>to ensure only one thread uses it at a time. See for example
>>>http://archives.postgresql.org/pgsql...9/msg00104.php
>>>
>>>
>>>
>>This is exactly what I am doing. Must admit I haven't considered that as
>>an issue. For performance reasons I suppose one database connection per
>>client are preferred rather than using synchronized on the db class ?
>>
>>
>>
>
>The JDBC driver should be doing any synchronization necessary for multiple
>threads. Could you be more clear what you are doing? What driver
>version? Any chance you've got a reproducible example?
>
>Kris Jurka
>
>
I have rewritten the application so every client thread is opening a new
database connection, and yesterday it happened again.
---
2005-04-11 12:27:54 ERROR: invalid string enlargement request size
1358954492
2005-04-11 12:27:54 WARNING: AbortTransaction and not in in-progress
state
2005-04-11 12:27:54 FATAL: invalid frontend message type
78
---
The application is opening a socket listener, and every client
connection opens a new connection to the database.
The clients sends a status message every 2nd minute that are written to
the database.
I'm using Postgresql version 7.4.7 and jdbc driver version
pg74.215.jdbc3.jar.
I have tried the pg80.310.jdbc3.jar but the datatype inet can't be used
with setString ??

Do you have a clue on what's going on ?

Poul



I found this: http://jdbc.postgresql.org/documentation/80/thread.html
As you are saying the jdbc driver should be thread safe, and has been
since the first version.
The

Poul Møller Hansen wrote:

>
>>>I'm using Postgresql version 7.4.7 and jdbc driver version
>>>pg74.215.jdbc3.jar.
>>>
>>>Do you have a clue on what's going on ?
>>>
>>>
>>>
>>
>>No, I don't. Do you have any more information? What is your code doing
>>when it fails? Just issuing a regular query? Are you using any of the
>>less common driver features: Large objects, fastpath api, a COPY patch?
>>If the driver had a protocol problem I would expect it to be rather
>>repeatable. If the driver had a synchronization problem it should have
>>disappeared when you moved to a single thread model. I've attached the
>>test script I've used to try and beat on the driver.
>>
>>Kris Jurka
>>
> Thanks, your application runs without any problems, so it can't
> provoke the error.
> I'm only using plain sql insert and update statements, the only
> special use I can think of, is that I'm
> using triggers in the tables, but I can't imagine they can cause it.
> I have now added extensive logging to the application, but so far the
> problem hasn't appeared.
>
> Poul
>