Обсуждение: Loosing connection with the database

Поиск
Список
Период
Сортировка

Loosing connection with the database

От
Poul Møller Hansen
Дата:
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



Re: Loosing connection with the database

От
Tom Lane
Дата:
=?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-hackers/2004-09/msg00104.php

            regards, tom lane

Re: Loosing connection with the database

От
Poul Møller Hansen
Дата:

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-hackers/2004-09/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

Re: Loosing connection with the database

От
Kris Jurka
Дата:

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-hackers/2004-09/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

Re: Loosing connection with the database

От
Poul Møller Hansen
Дата:

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-hackers/2004-09/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

Re: Loosing connection with the database

От
Kris Jurka
Дата:

On Tue, 12 Apr 2005, [UTF-8] Poul Møller Hansen wrote:

> 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.
>
> 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
Вложения

Re: Loosing connection with the database

От
Poul Møller Hansen
Дата:
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