Обсуждение: Loosing connection with the database
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
=?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
This is exactly what I am doing. Must admit I haven't considered that as an issue.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 82This 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
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-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.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.phpThis 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
---
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
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
Вложения
Poul Møller Hansen wrote:
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
Thanks, your application runs without any problems, so it can't provoke the error.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
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