Skip site navigation (1) Skip section navigation (2)

Re: invalid message format and I/O error while comunicating with backend

From: Sergi Vera <svera(at)emovilia(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: invalid message format and I/O error while comunicating with backend
Date: 2008-05-05 06:56:17
Message-ID: 481EAF91.8020203@emovilia.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Yes, your are right



It is a problem related with multiple threads working on the same
Prepared Statement.



I have modified the code to run with one single thread and it runs
very smoothly.

Previously there were more than one thread working onthe same
prepared statements (they were created at server startup) Even if
the code already included some synchronization code, it seems I was
loosing control of the threads.



I will modify the code, and make sure every thread has his own
Prepared Statements.



I thought that sharing the same prepared statements was more
efficient.



Thanks





Kris Jurka escribió:
This appears to
be a thread safety related problem. I believe your code has
one thread setting the parameter values and another thread
executing the prepared statement at the same time. The
executor does two passes through the parameter list, once to
calculate a total message length and another time to send the
values. If the contents change between the length calculation
and the message sending we'll have the wrong length and the whole
client-server communication gets messed up. The attached test
case demonstrates this failure mode.



I'm unsure how hard we should try to fix this, there are a couple
of approaches:



1) Do nothing. It's really a client problem and they
shouldn't be setting and executing at the same time.



2) Just copy the parameters at execution time so we get a
consistent view of them. This may not be exactly what the
user wants though if the order things actually execute is:
execute, set, copy instead of execute, copy, set.



3) Go through all the PreparedStatement functions making most of
them synchronized so that you cannot set while an execute is
running.



Kris Jurka



Sergi Vera wrote:

Hi!



I've been a little busy thoose days and was unable to work on this,
but I've made the tcpdump session that you requested and

here are the results





Kris Jurka escribió:

Sergi Vera wrote:

Thanks Kris for the help



Adding loglevel=2 dind't add any more info on logs, and it will be
not easy to make a self contained program, but I have attached the
result of



The loglevel=2 logging will go to the driver's System.out not into
the server error log.



tcpdump -vvv -i lo -w pgsqlerror2.dat





This only captures the start of each packet so it doesn't have the
whole thing. Could you recapture with:



tcpdump -n -w pgsqlerror3.dat -s 1514 -i any tcp port 5432



This ups the capture size (-s 1514) and also filters out the
unrelated UDP traffic you've got going on.



Browsing through the first failing pgsql data chunk,
one can see that:



http://img139.imageshack.us/my.php?image=pantallazolm8.png




The last data has column lenght -1 which seems strange even if I
don'k know anything of this particular protocol





-1 length indicates a NULL value, so that's expected.




















--



Sergio Vera

Rosellón, 34, 5 Planta

08029 Barcelona

tel. 902101870

www.emovilia.com




IMPRIME ESTE EMAIL Y SUS ARCHIVOS SI
REALMENTE LOS NECESITAS.

GRACIAS POR RESPETAR EL MEDIO AMBIENTE.

NOTA: La información
contenida en este email, y sus documentos adjuntos, es confidencial
y para uso exclusivo de la persona o personas a las que va
dirigido. No está permitido el acceso a este mensaje a otra persona
distinta a los indicados. Si no es uno de los destinatarios o ha
recibido este mensaje por error, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la
información contenida o cualquiera otra acción tomada en relación
con el mismo, está prohibida y puede ser ilegal.





ADVICE: The information
in this email as in the attachments is confidential and private for
exclusive use of the target user group. Access to this message is
disallowed to any other than the addressee. If you are not the
addressee or you have been included by mistake, any duplication,
reproduction, distribution as any other action relative to this
email is strictly forbidden and might be illegal.


In response to

pgsql-jdbc by date

Next:From: Daniel MigowskiDate: 2008-05-05 07:10:53
Subject: Re: ERROR: insufficient data left in message
Previous:From: robert engelsDate: 2008-05-01 23:49:59
Subject: Re: BLOB is read into memory instead of streaming (bug?)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group