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

Поиск
Список
Период
Сортировка
От Sergi Vera
Тема Re: invalid message format and I/O error while comunicating with backend
Дата
Msg-id 481EAF91.8020203@emovilia.com
обсуждение исходный текст
Ответ на Re: invalid message format and I/O error while comunicating with backend  (Kris Jurka <books@ejurka.com>)
Список pgsql-jdbc
Yes, your are right<br /><br /> It is a problem related with multiple threads working on the same Prepared
Statement.<br/><br /> I have modified the code to run with one single thread and it runs very smoothly. <br />
Previouslythere were more than one thread working onthe same prepared statements (they were created at server startup)
Evenif the code already included some synchronization code, it seems I was loosing control of the threads.<br /><br />
Iwill modify the code, and make sure every thread has his own Prepared Statements.<br /><br /> I thought that sharing
thesame prepared statements was more efficient.<br /><br /> Thanks<br /><br /><br /> Kris Jurka escribió: <blockquote
cite="mid:481901F4.1070302@ejurka.com"type="cite">This appears to be a thread safety related problem.  I believe your
codehas one thread setting the parameter values and another thread executing the prepared statement at the same time. 
Theexecutor does two passes through the parameter list, once to calculate a total message length and another time to
sendthe values.  If the contents change between the length calculation and the message sending we'll have the wrong
lengthand the whole client-server communication gets messed up.  The attached test case demonstrates this failure mode.
<br/><br /> I'm unsure how hard we should try to fix this, there are a couple of approaches: <br /><br /> 1) Do
nothing. It's really a client problem and they shouldn't be setting and executing at the same time. <br /><br /> 2)
Justcopy the parameters at execution time so we get a consistent view of them.  This may not be exactly what the user
wantsthough if the order things actually execute is:  execute, set, copy instead of execute, copy, set. <br /><br /> 3)
Gothrough all the PreparedStatement functions making most of them synchronized so that you cannot set while an execute
isrunning. <br /><br /> Kris Jurka <br /><br /> Sergi Vera wrote: <br /><blockquote type="cite">Hi! <br /><br /> I've
beena little busy thoose days and was unable to work on this, but I've made the tcpdump session that you requested and
<br/> here are the results <br /><br /><br /> Kris Jurka escribió: <br /><blockquote type="cite">Sergi Vera wrote: <br
/><blockquotetype="cite">Thanks Kris for the help <br /><br /> Adding loglevel=2 dind't add any more info on logs, and
itwill be not easy to make a self contained program, but I have attached the result of <br /></blockquote><br /> The
loglevel=2logging will go to the driver's System.out not into the server error log. <br /><br /><blockquote
type="cite">tcpdump-vvv -i lo -w pgsqlerror2.dat <br /><br /></blockquote><br /> This only captures the start of each
packetso it doesn't have the whole thing.  Could you recapture with: <br /><br /> tcpdump -n -w pgsqlerror3.dat -s 1514
-iany tcp port 5432 <br /><br /> This ups the capture size (-s 1514) and also filters out the unrelated UDP traffic
you'vegot going on. <br /><br /><blockquote type="cite">Browsing through the first failing pgsql data chunk, one can
seethat: <br /><br /><a class="moz-txt-link-freetext"
href="http://img139.imageshack.us/my.php?image=pantallazolm8.png">http://img139.imageshack.us/my.php?image=pantallazolm8.png</a><br
/><br/> The last data has column lenght -1 which seems strange even if I don'k know anything of this particular
protocol<br /><br /></blockquote><br /> -1 length indicates a NULL value, so that's expected. <br /><br
/></blockquote><br/><br /></blockquote><br /><pre wrap=""><pre wrap="">
 
<hr size="4" width="90%" />

</pre></pre></blockquote><br /><br /><div class="moz-signature">-- <br /></div><a href="http://www.emovilia.com/"> <img
border="0"src="cid:part1.05050409.09000402@emovilia.com" /></a><p style="margin-bottom: 0cm;">Sergio Vera<br />
Rosellón,34, 5 Planta<br /> 08029 Barcelona<br /> tel. 902101870<br /><a class="moz-txt-link-abbreviated"
href="http://www.emovilia.com">www.emovilia.com</a><br/><br /><p lang="ca-ES" style="margin-bottom: 0cm;"><font
face="Consolas,monospace" size="2" style="font-size: 10pt;">IMPRIME ESTE EMAIL Y SUS ARCHIVOS SI REALMENTE LOS
NECESITAS.<br/> GRACIAS POR RESPETAR EL MEDIO AMBIENTE.</font><p lang="ca-ES" style="margin-bottom: 0cm;"><font
face="Consolas,monospace"><font size="2" style="font-size: 10pt;">NOTA: La información contenida en este email, y sus
documentosadjuntos, es confidencial y para uso exclusivo de la persona o personas a las que va dirigido. No está
permitidoel acceso a este mensaje a otra persona distinta a los indicados. Si no es uno de los destinatarios o ha
recibidoeste mensaje por error, cualquier duplicación, reproducción, distribución, así como cualquier uso de la
informacióncontenida o cualquiera otra acción tomada en relación con el mismo, está prohibida y puede ser
ilegal.</font></font><plang="ca-ES" style="margin-bottom: 0cm;"><p lang="ca-ES" style="margin-bottom: 0cm;"><p
lang="ca-ES"style="margin-bottom: 0cm;"><font face="Consolas, monospace"><font size="2" style="font-size:
10pt;">ADVICE:The information in this email as in the attachments is confidential and private for exclusive use of the
targetuser group. Access to this message is disallowed to any other than the addressee. If you are not the addressee or
youhave been included by mistake, any duplication, reproduction, distribution as any other action relative to this
emailis strictly forbidden and might be illegal.</font></font> 

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: robert engels
Дата:
Сообщение: Re: BLOB is read into memory instead of streaming (bug?)
Следующее
От: Daniel Migowski
Дата:
Сообщение: Re: ERROR: insufficient data left in message