Postgres Pro
Downloads
Home   >   mailing lists

Thread: Unknown Response Type 1

Unknown Response Type 1

From
Gaetano Mendola
Date:
Hi all,
today I seen this message in my logs:


org.postgresql.util.PSQLException: Unknown Response Type 1


I never seen it and I'm wondering about what can generate that
exception.

I'm using Postgres 7.4.2 with JDBC pg74.1jdbc2.jar


Regards
Gaetano Mendola

Re: Unknown Response Type 1

From
Oliver Jowett
Date:
Gaetano Mendola wrote:
> Hi all,
> today I seen this message in my logs:
>
>
> org.postgresql.util.PSQLException: Unknown Response Type 1

This isn't much use without at least a stack trace, and some context
(what was the app doing?) would be good too.

> I never seen it and I'm wondering about what can generate that
> exception.

> I'm using Postgres 7.4.2 with JDBC pg74.1jdbc2.jar

Which build of the driver is this? Can you reproduce the problem using
the current development driver?

-O

Re: Unknown Response Type 1

From
Gaetano Mendola
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Jowett wrote:

| Gaetano Mendola wrote:
|
|> Hi all,
|> today I seen this message in my logs:
|>
|>
|> org.postgresql.util.PSQLException: Unknown Response Type 1
|
|
| This isn't much use without at least a stack trace, and some context
| (what was the app doing?) would be good too.

This is the stack trace:

org.postgresql.util.PSQLException: Unknown Response Type 1
at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:193)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:101)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43)
at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:515)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:50)
at org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:231)
at net.eutelsat.opensky.sdr.command.db.SpSdrCheckPasswd.execute(SpSdrCheckPasswd.java:97)



The application:

PreparedStatement theStatement;
theStatement = theConnection.prepareStatement( "SELECT foo ( ?,? )"  );
theStatement.setString( 1 , aLogin );
theStatement.setString( 2 , aPassword );

ResultSet rs = theStatement.executeQuery();   <---- Line 97


and in the server side:

LOG:  statement: SELECT foo ( 'login','password' )
LOG:  duration: 0.691 ms





|> I never seen it and I'm wondering about what can generate that
|> exception.
|
|
|> I'm using Postgres 7.4.2 with JDBC pg74.1jdbc2.jar
|
|
| Which build of the driver is this? Can you reproduce the problem using
| the current development driver?

I really don't know which build is and I can not reproduce the problem because
I seen it after 12 month that application is running and actualy I'm not seeing
it again.



Regards
Gaetano Mendola









-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBDPwO7UpzwH2SGd4RAn0YAKDvVLQS4TJ3uE/KLgJYzkJnDL2o6wCdG3TY
po/z5rS9A6LGyQECL8998Hc=
=ns1n
-----END PGP SIGNATURE-----

Re: Unknown Response Type 1

From
Oliver Jowett
Date:
Gaetano Mendola wrote:

> This is the stack trace:
>
> org.postgresql.util.PSQLException: Unknown Response Type 1
> at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:193)
> at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:101)
> at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43)
> at
> org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:515)
>
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:50)
>
> at
> org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:231)
>
> at
> net.eutelsat.opensky.sdr.command.db.SpSdrCheckPasswd.execute(SpSdrCheckPasswd.java:97)

(this stacktrace appears to match the REL7_4_1 driver code)

This means that the driver unexpectedly received a ParseComplete message
from the backend. As the driver you're using never issues a Parse
message, I'm not sure how this can ever happen. The most likely cause is
that the driver and the server are somehow getting out of sync as to
where the message boundaries lie.

I haven't seen this before and there's nothing obviously wrong with the
driver's protocol-level code that I can see.. so unless you can
reproduce it, it's a bit of a dead end :(

> The application:
>
> PreparedStatement theStatement;
> theStatement = theConnection.prepareStatement( "SELECT foo ( ?,? )"  );
> theStatement.setString( 1 , aLogin );
> theStatement.setString( 2 , aPassword );
>
> ResultSet rs = theStatement.executeQuery();   <---- Line 97
>
>
> and in the server side:
>
> LOG:  statement: SELECT foo ( 'login','password' )
> LOG:  duration: 0.691 ms

Do you have the previous query on that connection logged?

Was there anything unusual in the server logs at around the same time?

-O

Re: Unknown Response Type 1

From
Oliver Jowett
Date:
Oliver Jowett wrote:

> I haven't seen this before and there's nothing obviously wrong with the
> driver's protocol-level code that I can see.. so unless you can
> reproduce it, it's a bit of a dead end :(

Actually, I just dug through CVS and noticed a post-7.4.1 bugfix.
Without the fix, asynchronous notification messages (via LISTEN/NOTIFY)
would have caused the message stream to get out of sync.

Does your application use LISTEN/NOTIFY at all?

-O

Re: Unknown Response Type 1

From
Gaetano Mendola
Date:
Oliver Jowett wrote:
> Oliver Jowett wrote:
> 
>> I haven't seen this before and there's nothing obviously wrong with 
>> the driver's protocol-level code that I can see.. so unless you can 
>> reproduce it, it's a bit of a dead end :(
> 
> 
> Actually, I just dug through CVS and noticed a post-7.4.1 bugfix. 
> Without the fix, asynchronous notification messages (via LISTEN/NOTIFY) 
> would have caused the message stream to get out of sync.
> 
> Does your application use LISTEN/NOTIFY at all?

Not at all.


Regards
Gaetano Mendola

Re: Unknown Response Type 1

From
Oliver Jowett
Date:
Gaetano Mendola wrote:

> I had some OutOfMemory in the client side but not related with the
> Database interaction.

Are you sure there was no OutOfMemoryError thrown within the JDBC driver
code? (perhaps caused by some other part of the application exhausting
the heap?) The driver isn't very good about keeping connections in a
consistent state when unexpected exceptions are thrown. One possibility
is that OOME was thrown partway through reading or writing a message on
the protocol stream, but the driver did not invalidate that connection.
Subsequent use of the connection will then fail randomly since the
driver is out of sync with the message boundaries the server is expecting.

-O