Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! (fwd)
Please keep the discussion on the list and don't try to address helpdesk requests to individuals. -aj ------------ Forwarded Message ------------ Date: 18. Januar 2007 19:05:28 +0100 From: yacine chaouche <yacinechaouche@gmail.com> To: Andreas Jung <lists@zopyx.com> Subject: Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! 2007/1/18, Andreas Jung <lists@zopyx.com>:
--On 18. Januar 2007 16:40:02 +0100 Patrick Gerken <do3ccqrv@googlemail.com> w>
instead of strace try tcpdump, much more helpful: tcpdump -i <INTERFACE> -s 0 -A HOST <HOST> AND PORT <PORT> should show the reality
"tcpflow" is much nicer and show the HTTP traffic in a decoded way.
-aj
Thank you Andreas for showing me this nice tool which is tcpflow. Thanks to it, I am now sure that the probleme is coming from zope. Would you take a look at this : root@CAY:~/HTTPCONNECTIONS# tcpflow host 10.75.49.100 and port 8081 tcpflow[20104]: listening on eth0 The tcpflow is run on the 10.75.49.51 machine, the one that zope thinks it sends two times the XMLRPC query. 10.75.49.100 is the server that runs zope. Now i click on the button, on both browsers (remember they are on different machines), invoking the method "toutCompter" via xmlhttprequest, and wait for zope to complete the requests : <zope trace to the console> ip: 10.75.49.155 requests counting of lines 1 to 11 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.155 sending results to 10.75.49.51 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.51 </zope trace> Zope says he got 2 requests form 10.75.49.51 and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : root@CAY:~/HTTPCONNECTIONS# ls total 8,0K -rw-r--r-- 1 root root 873 2007-01-18 18:52 010.075.049.051.41131-010.075.049.100.08081 -rw-r--r-- 1 root root 607 2007-01-18 18:53 010.075.049.100.08081-010.075.049.051.41131 Allright, first file (machine to server): root@CAY:~/HTTPCONNECTIONS# cat 010.075.049.051.41131-010.075.049.100.08081 POST /aef/rechercheMultiligne/toutCompter HTTP/1.1 Host: 10.75.49.100:8081 User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: fr,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Content-Type: application/x-www-form-urlencoded Referer: http://10.75.49.100:8081/aef/rechercheMultiligne Content-Length: 224 Cookie: _ZopeId="58653529A2r8NuahgXc" Pragma: no-cache Cache-Control: no-cache requete_1=ape%2012*&requete_2=ape%2012*&requete_3=ape%2012*&requete_4=ape%2 012*&requete_5=ape%2012*&requete_6=ape%2012*&requete_7=ape%2012*&requete_8= ape%2012*&requete_9=ape%2012*&requete_10=ape%2012*&borneInf=0&borneSup= 10&root@CAY:~/HTTPCONNECTIONS# Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : root@CAY:~/HTTPCONNECTIONS# cat 010.075.049.100.08081-010.075.049.051.41131 HTTP/1.1 200 OK Server: Zope/(Zope 2.9.0-, python 2.4.2, linux2) ZServer/1.1 Date: Thu, 18 Jan 2007 17:51:42 GMT Content-Length: 413 Charset: utf-8 Content-Type: text/xml; charset=utf-8 <?xml version="1.0" encoding="utf-8" ?><comptages><comptage numLigne="1">3</comptage><comptage numLigne="2">3</comptage><comptage numLigne="3">3</comptage><comptage numLigne="4">3</comptage><comptage numLigne="5">3</comptage><comptage numLigne="6">3</comptage><comptage numLigne="7">3</comptage><comptage numLigne="8">3</comptage><comptage numLigne="9">3</comptage><comptage numLigne="10">3</comptage></comptages> root@CAY:~/HTTPCONNECTIONS# The results were sent just one time, not two. What is going on here ? Any comment would be really appreciated. Thanks, Y.Chaouche ---------- End Forwarded Message ---------- -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
At Thursday 18/1/2007 16:30, Andreas Jung wrote:
<zope trace to the console> ip: 10.75.49.155 requests counting of lines 1 to 11 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.155 sending results to 10.75.49.51 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.51 </zope trace>
Zope says he got 2 requests form 10.75.49.51 and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : [...] Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : [...] The results were sent just one time, not two.
What is going on here ?
What does the toutCompter method really does? Does it modify some object state? That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged). -- Gabriel Genellina Softlab SRL __________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
The toutCompter methode does a lot of thing and it would take a triple couples of lines to describe what it does all. Anyway, is there a way for me to detect ConflictErrors ? they don't appear on the console so i guess they are catched. Y.Chaouche 2007/1/19, Gabriel Genellina <gagsl-zope@yahoo.com.ar>:
At Thursday 18/1/2007 16:30, Andreas Jung wrote:
<zope trace to the console> ip: 10.75.49.155 requests counting of lines 1 to 11 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.155 sending results to 10.75.49.51 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.51 </zope trace>
Zope says he got 2 requests form 10.75.49.51 and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : [...] Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : [...] The results were sent just one time, not two.
What is going on here ?
What does the toutCompter method really does? Does it modify some object state? That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
-- Gabriel Genellina Softlab SRL
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
I mean triple couples of lines of code. 2007/1/19, yacine chaouche <yacinechaouche@gmail.com>:
The toutCompter methode does a lot of thing and it would take a triple couples of lines to describe what it does all. Anyway, is there a way for me to detect ConflictErrors ? they don't appear on the console so i guess they are catched.
Y.Chaouche
2007/1/19, Gabriel Genellina <gagsl-zope@yahoo.com.ar>:
At Thursday 18/1/2007 16:30, Andreas Jung wrote:
<zope trace to the console> ip: 10.75.49.155 requests counting of lines 1 to 11 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.155 sending results to 10.75.49.51 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.51 </zope trace>
Zope says he got 2 requests form 10.75.49.51 and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : [...] Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : [...] The results were sent just one time, not two.
What is going on here ?
What does the toutCompter method really does? Does it modify some object state? That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
-- Gabriel Genellina Softlab SRL
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
It writes and reads objects in the session, maybe the probleme comes from here ? Here's a little sinppet : def toutCompter(self): """ xmlrpc methode, called from a web borwser. """ documentXML = ComptageXML() #this reads and writes objects in the session dicoLignes = self._fabriquerDicoLignes() #do things with dicoLignes for inumLigneCourante in xrange(borneInf,borneSup) : snumLigneCourante = str(inumLigneCourante) ligne = dicoLignes[snumLigneCourante]["requete"] #do things here self._ajouterAuDico(snumLigneCourante,ligne,comptage,arbre) if ligne : self._mettreEnSession(resultats) response = self.REQUEST.RESPONSE response.setHeader("Content-Type","text/xml") response.setHeader("charset","utf-8") chaineXML = documentXML.formatXML() print "sending results to "+addresseIP return chaineXML def _fabriquerDicoLignes(self): formulaire = self.getForm() dicoLignes = self.getSession(self,"dicoLignes") or {} for key in formulaire.keys(): #do things... self.setSession("dicoLignes", dicoLignes) return dicoLignes def _fabriquerListeLignes(self): dicoLignes = RacineAbstraite.getSession(self,"dicoLignes") or {} listeNumeros = dicoLignes.keys() listeNumeros.sort( lambda x,y: cmp(int(x), int(y)) ) return [ dicoLignes[str(inumeroLigne)]["requete"] for inumeroLigne in \ sorted( [int(snumeroLigne) for snumeroLigne in dicoLignes.keys()] ) ] def _ajouterAuDico(self,p_snumeroCle,p_ligne,p_comptage,p_arbre): dicoLignes = RacineAbstraite.getSession(self,'dicoLignes') or {} dicoLignes[p_snumeroCle] = {'requete':p_ligne,'comptage':p_comptage,'arbre':p_arbre} self.setSession('dicoLignes',dicoLignes) def _mettreEnSession(self,p_resultats): """ Mettre en session les résultats d'un comptage. """ # Initialise de la SESSION dicoResultatRecherche = { 'listeCriteres' : [self._fabriquerListeLignes(), self.getForm('numeroLigne')], 'nombreEntreprises' : p_resultats[0][0], 'listeComptage' : p_resultats, 'listeEntreprises' : [], } #On conserve la requete et le resultat en session self.setSession('resultatRecherche', p_dicoResultatRecherche.copy()) When toutCompter is called by browser 1, then he will write and read, say, the dicoLignes object in the session. When toutCompter is called by browser 2 parallely, is it the same dicoLignes object that it tries to access or another one is created ? can there be conflicts somehow ? Y.Chaouche 2007/1/19, yacine chaouche <yacinechaouche@gmail.com>:
I mean triple couples of lines of code.
2007/1/19, yacine chaouche <yacinechaouche@gmail.com>:
The toutCompter methode does a lot of thing and it would take a triple couples of lines to describe what it does all. Anyway, is there a way for me to detect ConflictErrors ? they don't appear on the console so i guess they are catched.
Y.Chaouche
2007/1/19, Gabriel Genellina <gagsl-zope@yahoo.com.ar >:
At Thursday 18/1/2007 16:30, Andreas Jung wrote:
<zope trace to the console> ip: 10.75.49.155 requests counting of lines 1 to 11 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.155 sending results to 10.75.49.51 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.51 </zope trace>
Zope says he got 2 requests form 10.75.49.51 and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : [...] Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : [...] The results were sent just one time, not two.
What is going on here ?
What does the toutCompter method really does? Does it modify some object state? That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
-- Gabriel Genellina Softlab SRL
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Hello all,
From times to times, apparently randomly, I have the following uncaught exception in the console :
2007-01-23 10:41:07 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 10.75.49.51:48177 at 0x44562e6c channel#: 140 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/python2.4.2/lib/python2.4/asynchat.py|initiate_send|219] [/opt/aef/Zope-2.9.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/python2.4.2/lib/python2.4/asyncore.py|send|332]) In addition, i have edited this file :Zope-2.9.0/lib/python/ZPublisher/HTTPRequest.py as follows : <code> def retry(self): print "retry called in HTTPRequest for the",self.retry_count,"time" self.retry_count=self.retry_count+1 self.stdin.seek(0) r=self.__class__(stdin=self.stdin, environ=self._orig_env, response=self.response.retry() ) r.retry_count=self.retry_count return r </code> I only added a single print line to see if this method was called. And indeed, it is ! Does anyone knows when (in what circumstances) this method could be called ??? <console trace> ip: 10.75.49.155 requests counting of lines 11 to 21 ip: 10.75.49.51 requests counting of lines 11 to 21 sending results to 10.75.49.155 sending results to 10.75.49.51 retry called in HTTPRequest for the 0 time ip: 10.75.49.51 requests counting of lines 11 to 21 </console trace> Thanks. Y.Chaouche 2007/1/19, yacine chaouche <yacinechaouche@gmail.com>:
It writes and reads objects in the session, maybe the probleme comes from here ? Here's a little sinppet :
def toutCompter(self): """ xmlrpc methode, called from a web borwser. """ documentXML = ComptageXML() #this reads and writes objects in the session dicoLignes = self._fabriquerDicoLignes() #do things with dicoLignes for inumLigneCourante in xrange(borneInf,borneSup) : snumLigneCourante = str(inumLigneCourante) ligne = dicoLignes[snumLigneCourante]["requete"] #do things here self._ajouterAuDico(snumLigneCourante,ligne,comptage,arbre)
if ligne : self._mettreEnSession(resultats)
response = self.REQUEST.RESPONSE response.setHeader("Content-Type","text/xml") response.setHeader ("charset","utf-8") chaineXML = documentXML.formatXML() print "sending results to "+addresseIP return chaineXML
def _fabriquerDicoLignes(self): formulaire = self.getForm() dicoLignes = self.getSession(self,"dicoLignes") or {} for key in formulaire.keys(): #do things... self.setSession("dicoLignes", dicoLignes) return dicoLignes
def _fabriquerListeLignes(self): dicoLignes = RacineAbstraite.getSession(self,"dicoLignes") or {} listeNumeros = dicoLignes.keys() listeNumeros.sort ( lambda x,y: cmp(int(x), int(y)) ) return [ dicoLignes[str(inumeroLigne)]["requete"] for inumeroLigne in \ sorted( [int(snumeroLigne) for snumeroLigne in dicoLignes.keys()] ) ]
def _ajouterAuDico(self,p_snumeroCle,p_ligne,p_comptage,p_arbre): dicoLignes = RacineAbstraite.getSession(self,'dicoLignes') or {} dicoLignes[p_snumeroCle] = {'requete':p_ligne,'comptage':p_comptage,'arbre':p_arbre} self.setSession('dicoLignes',dicoLignes)
def _mettreEnSession(self,p_resultats): """ Mettre en session les résultats d'un comptage. """
# Initialise de la SESSION dicoResultatRecherche = { 'listeCriteres' : [self._fabriquerListeLignes(), self.getForm('numeroLigne')], 'nombreEntreprises' : p_resultats[0][0], 'listeComptage' : p_resultats, 'listeEntreprises' : [], } #On conserve la requete et le resultat en session self.setSession('resultatRecherche', p_dicoResultatRecherche.copy())
When toutCompter is called by browser 1, then he will write and read, say, the dicoLignes object in the session. When toutCompter is called by browser 2 parallely, is it the same dicoLignes object that it tries to access or another one is created ? can there be conflicts somehow ?
Y.Chaouche
2007/1/19, yacine chaouche <yacinechaouche@gmail.com>:
I mean triple couples of lines of code.
2007/1/19, yacine chaouche < yacinechaouche@gmail.com>:
The toutCompter methode does a lot of thing and it would take a triple couples of lines to describe what it does all. Anyway, is there a way for me to detect ConflictErrors ? they don't appear on the console so i guess they are catched.
Y.Chaouche
2007/1/19, Gabriel Genellina <gagsl-zope@yahoo.com.ar >:
At Thursday 18/1/2007 16:30, Andreas Jung wrote:
<zope trace to the console> ip: 10.75.49.155 requests counting of lines 1 to 11 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.155 sending results to 10.75.49.51 ip: 10.75.49.51 requests counting of lines 1 to 11 sending results to 10.75.49.51 </zope trace>
Zope says he got 2 requests form 10.75.49.51 and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : [...] Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : [...] The results were sent just one time, not two.
What is going on here ?
What does the toutCompter method really does? Does it modify some object state? That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
-- Gabriel Genellina Softlab SRL
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
In general, retry is called when a ZODB Conflict Error has happened. If I remember well, Zope will silently retry 3 times, and then actually return an error page showing the Conflict Error. Pascal De : yacine chaouche <yacinechaouche@gmail.com> Date : Tue, 23 Jan 2007 10:49:40 +0100 À : Gabriel Genellina <gagsl-zope@yahoo.com.ar> Cc : <zope@zope.org> Objet : Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! (fwd) Hello all,
From times to times, apparently randomly, I have the following uncaught exception in the console :
2007-01-23 10:41:07 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 10.75.49.51:48177 <http://10.75.49.51:48177> at 0x44562e6c channel#: 140 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/python2.4.2/lib/python2.4/asynchat.py|initiate_send|219] [/opt/aef/Zope- 2.9.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/python2.4.2/lib/python2.4/asyncore.py|send|332]) In addition, i have edited this file :Zope-2.9.0/lib/python/ZPublisher/HTTPRequest.py as follows : <code> def retry(self): print "retry called in HTTPRequest for the",self.retry_count,"time" self.retry_count=self.retry_count+1 self.stdin.seek(0) r=self.__class__(stdin= self.stdin, environ=self._orig_env, response=self.response.retry() ) r.retry_count=self.retry_count return r </code> I only added a single print line to see if this method was called. And indeed, it is ! Does anyone knows when (in what circumstances) this method could be called ??? <console trace> ip: 10.75.49.155 <http://10.75.49.155> requests counting of lines 11 to 21 ip: 10.75.49.51 <http://10.75.49.51> requests counting of lines 11 to 21 sending results to 10.75.49.155 <http://10.75.49.155> sending results to 10.75.49.51 <http://10.75.49.51> retry called in HTTPRequest for the 0 time ip: 10.75.49.51 <http://10.75.49.51> requests counting of lines 11 to 21 </console trace> Thanks. Y.Chaouche 2007/1/19, yacine chaouche <yacinechaouche@gmail.com>:
It writes and reads objects in the session, maybe the probleme comes from here ? Here's a little sinppet :
def toutCompter(self): """ xmlrpc methode, called from a web borwser. """ documentXML = ComptageXML() #this reads and writes objects in the session dicoLignes = self._fabriquerDicoLignes() #do things with dicoLignes for inumLigneCourante in xrange(borneInf,borneSup) : snumLigneCourante = str(inumLigneCourante) ligne = dicoLignes[snumLigneCourante]["requete"] #do things here self._ajouterAuDico(snumLigneCourante,ligne,comptage,arbre)
if ligne : self._mettreEnSession(resultats)
response = self.REQUEST.RESPONSE response.setHeader("Content-Type","text/xml") response.setHeader ("charset","utf-8") chaineXML = documentXML.formatXML() print "sending results to "+addresseIP return chaineXML
def _fabriquerDicoLignes(self): formulaire = self.getForm() dicoLignes = self.getSession(self,"dicoLignes") or {} for key in formulaire.keys(): #do things... self.setSession("dicoLignes", dicoLignes) return dicoLignes
def _fabriquerListeLignes(self): dicoLignes = RacineAbstraite.getSession(self,"dicoLignes") or {} listeNumeros = dicoLignes.keys() listeNumeros.sort ( lambda x,y: cmp(int(x), int(y)) ) return [ dicoLignes[str(inumeroLigne)]["requete"] for inumeroLigne in \ sorted( [int(snumeroLigne) for snumeroLigne in dicoLignes.keys()] ) ]
def _ajouterAuDico(self,p_snumeroCle,p_ligne,p_comptage,p_arbre): dicoLignes = RacineAbstraite.getSession(self,'dicoLignes') or {} dicoLignes[p_snumeroCle] = {'requete':p_ligne,'comptage':p_comptage,'arbre':p_arbre} self.setSession('dicoLignes',dicoLignes)
def _mettreEnSession(self,p_resultats): """ Mettre en session les résultats d'un comptage. """
# Initialise de la SESSION dicoResultatRecherche = { 'listeCriteres' : [self._fabriquerListeLignes(), self.getForm('numeroLigne')], 'nombreEntreprises' : p_resultats[0][0], 'listeComptage' : p_resultats, 'listeEntreprises' : [], } #On conserve la requete et le resultat en session self.setSession('resultatRecherche', p_dicoResultatRecherche.copy())
When toutCompter is called by browser 1, then he will write and read, say, the dicoLignes object in the session. When toutCompter is called by browser 2 parallely, is it the same dicoLignes object that it tries to access or another one is created ? can there be conflicts somehow ?
Y.Chaouche
2007/1/19, yacine chaouche < yacinechaouche@gmail.com <mailto:yacinechaouche@gmail.com> >:
I mean triple couples of lines of code.
2007/1/19, yacine chaouche < yacinechaouche@gmail.com <mailto:yacinechaouche@gmail.com> >:
The toutCompter methode does a lot of thing and it would take a triple couples of lines to describe what it does all. Anyway, is there a way for me to detect ConflictErrors ? they don't appear on the console so i guess they are catched.
Y.Chaouche
2007/1/19, Gabriel Genellina <gagsl-zope@yahoo.com.ar <mailto:gagsl-zope@yahoo.com.ar> >:
At Thursday 18/1/2007 16:30, Andreas Jung wrote:
<zope trace to the console> ip: 10.75.49.155 <http://10.75.49.155> requests counting of lines 1 to 11 ip: 10.75.49.51 <http://10.75.49.51> requests counting of lines 1 to 11 sending results to 10.75.49.155 <http://10.75.49.155> sending results to 10.75.49.51 <http://10.75.49.51> ip: 10.75.49.51 <http://10.75.49.51> requests counting of lines 1 to 11 sending results to 10.75.49.51 <http://10.75.49.51> </zope trace>
Zope says he got 2 requests form 10.75.49.51 <http://10.75.49.51> and sent it the results 2 times. Ok, let's check the tcpflow then for these supposed connections : [...] Allright, there is only ONE POST request. So zope didnt really got two requests. Now let's see if it sent the data two times as it presumes : [...] The results were sent just one time, not two.
What is going on here ?
What does the toutCompter method really does? Does it modify some object state? That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
-- Gabriel Genellina Softlab SRL
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas <http://www.yahoo.com.ar/respuestas>
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope <http://mail.zope.org/mailman/listinfo/zope> ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce <http://mail.zope.org/mailman/listinfo/zope-announce> http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
From times to times, apparently randomly, I have the following uncaught exception in the console :
2007-01-23 10:41:07 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 10.75.49.51:48177 <http://10.75.49.51:48177> at 0x44562e6c channel#: 140 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/python2.4.2/lib/python2.4/asynchat.py|initiate_send|219] [/opt/aef/Zope- 2.9.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/python2.4.2/lib/python2.4/asyncore.py|send|332]) This means that when Zope was sending a response to the browser, user pressed a 'Stop' button in browser, closed browser tab/window etc. Nothing to worry about.
-- Maciej Wisniowski
Got it ! I edited this file : Zope-2.9.0/lib/python/ZPublisher/Publish.py and added a print line in the publish function, at the beginning of the first except block : <code> def publish(request, module_name, after_list, debug=0,...): ... try: request.processInputs() request_get=request.get response=request.response ... except: print "exception raised in the publish module, in function publish", sys.exc_type,sys.exc_value # DM: provide nicer error message for FTP sm = None if response is not None: sm = getattr(response, "setMessage", None) ... </code> print "exception raised in the publish module, in function publish", sys.exc_type,sys.exc_value </code> And here is the exception that is raised: exception raised in the publish module, in function publish ZODB.POSException.ConflictError database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b192256c66688 2007-01-23 16:34:20.337891, serial currently committed 0x036b19236a4be0ee 2007-01-23 16:35:24.913219) What happend ? Y.Chaouche 2007/1/23, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl>:
From times to times, apparently randomly, I have the following uncaught exception in the console :
2007-01-23 10:41:07 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 10.75.49.51:48177 <http://10.75.49.51:48177> at 0x44562e6c channel#: 140 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/python2.4.2/lib/python2.4/asynchat.py|initiate_send|219] [/opt/aef/Zope- 2.9.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/python2.4.2/lib/python2.4/asyncore.py|send|332]) This means that when Zope was sending a response to the browser, user pressed a 'Stop' button in browser, closed browser tab/window etc. Nothing to worry about.
-- Maciej Wisniowski
And here is the exception that is raised:
exception raised in the publish module, in function publish ZODB.POSException.ConflictError database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b192256c66688 2007-01-23 16:34:20.337891, serial currently committed 0x036b19236a4be0ee 2007-01-23 16:35:24.913219)
What happend ? Sorry for doing that but I'll send you to list archives. There were a lot of threads about conflict errors. I think you'll find them helpful.
-- Maciej Wisniowski
As Gabriel Genellina said earlier in this discussion, the probleme could come from the dicoLignes variable that is stored in the session.I don't get it, the exception says that the Increaser object is responsible of the conflict error : ZODB.POSException.ConflictError database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b192256c66688 2007-01-23 16:34:20.337891, serial currently committed 0x036b19236a4be0ee 2007-01-23 16:35:24.913219) But the Increaser class has a _p_resolveConflict method : <code> class Increaser(Persistent): """ A persistent object representing a typically increasing integer that has conflict resolution which uses the greatest integer out of the three available states. """ ... def _p_resolveConflict(self, old, state1, state2): return max(old, state1, state2) </code> http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution says : "" When a conflict is detected, then the database checks to see if the class of the object being saved defines the method, _p_resolveConflict. If the method is defined, then the method is called on the object. If the method succeeds, then the object change can be committed, otherwise a ConflictErroris raised as usual."" But how can the simple instruction return max(old,state1,state2) not "succeed" ??!! anyway, i decided to rewrite it like this : <code> def _p_resolveConflict(self, old, state1, state2): try: number = max(old,state1,state2) except Exception,msg: import traceback traceback.print_exc(file=sys.stdin) return max(old, state1, state2) </code> And still the same exception is raised ! <traceback on the console> exception raised in the publish module, in function publish Traceback (most recent call last): File "/opt/aef/Zope-2.9.0/lib/python/ZPublisher/Publish.py", line 119, in publish transactions_manager.commit() File "/opt/aef/Zope-2.9.0//lib/python/Zope2/App/startup.py", line 234, in commit transaction.commit() File "/opt/aef/Zope-2.9.0//lib/python/transaction/_manager.py", line 96, in commit return self.get().commit(sub, deprecation_wng=False) File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 380, in commit self._saveCommitishError() # This raises! File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 378, in commit self._commitResources() File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 433, in _commitResources rm.commit(self) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 484, in commit self._commit(transaction) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 526, in _commit self._store_objects(ObjectWriter(obj), transaction) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 554, in _store_objects s = self._storage.store(oid, serial, p, self._version, transaction) File "/opt/aef/Zope-2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 200, in store data=data) ConflictError: database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b1eec70e150ee 2007-01-24 17:16:26.456283, serial currently committed 0x036b1eee46e27955 2007-01-24 17:18:16.613593) </traceback> (i edited publish.py and added a traceback.print_exc(file=stdin) instruction in the beginning of the except block). Y.Chaouche 2007/1/23, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl>:
And here is the exception that is raised:
exception raised in the publish module, in function publish ZODB.POSException.ConflictError database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b192256c66688 2007-01-23 16:34:20.337891, serial currently committed 0x036b19236a4be0ee 2007-01-23 16:35:24.913219)
What happend ? Sorry for doing that but I'll send you to list archives. There were a lot of threads about conflict errors. I think you'll find them helpful.
-- Maciej Wisniowski
But the Increaser class has a _p_resolveConflict method : (...) And still the same exception is raised ! Is _p_resolveConflict method of Inceraser executed at all? I wonder if traceback you see in console is from the code you added: traceback.print_exc(file=stdin)
or it is always shown when there is a conflict error. Another question, do you use ZEO? I know there were some issues with _p_resolveConflict and ZEO (at last in Zope 2.8.x). Result was that with ZEO setup _p_resolveConflict was not called at all. There is solution for this but I don't know if this is your case especially that you are dealing with TemporaryStorage which is typically managed by ZEO Client... You may take a look at lib/python/ZODB/ConflictResolution.py method: tryToResolveConflict. There is a call to _p_resolveConflict. -- Maciej Wisniowski
On 1/24/07, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
Another question, do you use ZEO? I know there were some issues with _p_resolveConflict and ZEO (at last in Zope 2.8.x). Result was that with ZEO setup _p_resolveConflict was not called at all. There is solution for this but I don't know if this is your case especially that you are dealing with TemporaryStorage which is typically managed by ZEO Client...
If ZEO cannot reach your product (import it), it cannot run any conflict resolution. Make sure that the ZEO server setup has access to those Products that do conflict resolution. -- Martijn Pieters
Is _p_resolveConflict method of Inceraser executed at all? I wonder if traceback you see in console is from the code you added: traceback.print_exc(file=stdin)
or it is always shown when there is a conflict error.
<code> def _p_resolveConflict(self, old, state1, state2): print "called the _p_resolveConflict of the Increaser object",self try: number = max(old,state1,state2) except Exception,msg: import traceback traceback.print_exc(file=sys.stdin) return max(old, state1, state2) </code> Yes, The method was not called. However, the traceback was indeed printed by the print_exc, since there were no tracebacks before I added this line. In fact, as Gabriel Genellina said :
That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
as well as Pascal Peregrina:
In general, retry is called when a ZODB Conflict Error has happened. If I remember well, Zope will silently retry 3 times, and then actually return an error page showing the Conflict Error.
as the documentation says http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx : "If an unhandled exception is raised during the publishing process, Zope aborts the transaction. As detailed in Chapter 4. Zope handles ConflictErrors by re-trying the request up to three times. This is done with the zpublisher_exception_hook." Thus, I don't think that the traceback is always shown when there's a conflict error. So I decided to look into the file suggested by Maciej Wisniowski :
You may take a look at lib/python/ZODB/ConflictResolution.py method: tryToResolveConflict. There is a call to _p_resolveConflict.
and edited it like this : <code> def tryToResolveConflict(self, oid, committedSerial, oldSerial, newpickle, committedData=''): # class_tuple, old, committed, newstate = ('',''), 0, 0, 0 print "in ConflictResolution.py, called the tryToResolveConflict method with arguments :" print "self",self,"oid",oid.__repr__(),"committedSerial",committedSerial.__repr__(),"oldSerial",oldSerial.__repr__(),"newpickle",newpickle.__repr__(),"committedData",committedData.__repr__() try: prfactory = PersistentReferenceFactory() file = StringIO(newpickle) unpickler = Unpickler(file) unpickler.find_global = find_global unpickler.persistent_load = prfactory.persistent_load meta = unpickler.load() if isinstance(meta, tuple): klass = meta[0] newargs = meta[1] or () if isinstance(klass, tuple): klass = find_global(*klass) else: klass = meta newargs = () if klass in _unresolvable: print "klass",klass.__repr__,"is unresolvable" return None newstate = unpickler.load() inst = klass.__new__(klass, *newargs) try: resolve = inst._p_resolveConflict except AttributeError: print inst.__repr__,"has no _p_resolveConflict method" _unresolvable[klass] = 1 return None old = state(self, oid, oldSerial, prfactory) committed = state(self, oid, committedSerial, prfactory, committedData) resolved = resolve(old, committed, newstate) file = StringIO() pickler = Pickler(file,1) pickler.persistent_id = persistent_id pickler.dump(meta) pickler.dump(resolved) print "everything's ok" return file.getvalue(1) except (ConflictError, BadClassName): print "ConflictError during conflict resolution in tryToResolveConflict, ConflictResolution.py" import traceback import sys traceback.print_exc(file = sys.stdout) return None except: print "Exception raised in in tryToResolveConflict, ConflictResolution.py" import traceback import sys traceback.print_exc(file=sys.stdout) # If anything else went wrong, catch it here and avoid passing an # arbitrary exception back to the client. The error here will mask # the original ConflictError. A client can recover from a # ConflictError, but not necessarily from other errors. But log # the error so that any problems can be fixed. logger.error("Unexpected error", exc_info=True) return None </code> Now let's see what's going on in the console : <console> in ConflictResolution.py, called the tryToResolveConflict method with arguments : self <tempstorage.TemporaryStorage.TemporaryStorage instance at 0x43fb6aac> oid '\x00\x00\x00\x00\x00\x00\x00\t' committedSerial '\x03k#\x93\x1d\xff\xf5\x11' oldSerial '\x03k#\x91^t\xf1D' newpickle '( cProducts.Transience.Transience\nIncreaser\nq\x01)tq\x02.J\x88\xa6\xb8E.' committedData '' ConflictError during conflict resolution in tryToResolveConflict, ConflictResolution.py Traceback (most recent call last): File "/opt/aef/Zope-2.9.0/lib/python/ZODB/ConflictResolution.py", line 126, in tryToResolveConflict old = state(self, oid, oldSerial, prfactory) File "/opt/aef/Zope-2.9.0/lib/python/ZODB/ConflictResolution.py", line 53, in state p = p or self.loadSerial(oid, serial) File "/opt/aef/Zope-2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 148, in loadSerial raise POSException.ConflictError(oid=oid) ConflictError: database conflict error (oid 0x09) <comment> the exception is raised up to the publish function, since it has not been catched, and I added up a code to print traceback in the publish function so here it is </comment> exception raised in the publish module, in function publish Traceback (most recent call last): File "/opt/aef/Zope-2.9.0/lib/python/ZPublisher/Publish.py", line 119, in publish transactions_manager.commit() File "/opt/aef/Zope-2.9.0//lib/python/Zope2/App/startup.py", line 234, in commit transaction.commit() File "/opt/aef/Zope-2.9.0//lib/python/transaction/_manager.py", line 96, in commit return self.get().commit(sub, deprecation_wng=False) File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 380, in commit self._saveCommitishError() # This raises! File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 378, in commit self._commitResources() File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 433, in _commitResources rm.commit(self) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 484, in commit self._commit(transaction) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 526, in _commit self._store_objects(ObjectWriter(obj), transaction) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 554, in _store_objects s = self._storage.store(oid, serial, p, self._version, transaction) File "/opt/aef/Zope-2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 200, in store data=data) ConflictError: database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b23915e74f144 2007-01-25 13:05:22.138314, serial currently committed 0x036b23931dfff511 2007-01-25 13:07:07.031211) </console> The exception is raised, as the traceback says, in File "/opt/aef/Zope-2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 148, in loadSerial raise POSException.ConflictError(oid=oid) Is it normal that the oid, as an argument to tryToResloveConflict, was "\x00\x00\x00\x00\x00\x00\x00\t" then became 0x09 when the exception was raised ? here's the loadSerial code : <code> def loadSerial(self, oid, serial, marker=[]): """ this is only useful to make conflict resolution work. It does not actually implement all the semantics that a revisioning storage needs! """ self._lock_acquire() try: data = self._conflict_cache.get((oid, serial), marker) if data is marker: # XXX Need 2 serialnos to pass them to ConflictError-- # the old and the new raise POSException.ConflictError(oid=oid) else: return data[0] # data here is actually (data, t) finally: self._lock_release() </code> 2007/1/25, Martijn Pieters <mj@zopatista.com>:
On 1/24/07, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
Another question, do you use ZEO? I know there were some issues with _p_resolveConflict and ZEO (at last in Zope 2.8.x). Result was that with ZEO setup _p_resolveConflict was not called at all. There is solution for this but I don't know if this is your case especially that you are dealing with TemporaryStorage which is typically managed by ZEO Client...
If ZEO cannot reach your product (import it), it cannot run any conflict resolution. Make sure that the ZEO server setup has access to those Products that do conflict resolution.
-- Martijn Pieters
Concerning zeo, I do not use it in the developpement plateforme, but there's one in the test and production platformes, so maybe I will face the problem during the test phase. I do not understand : session objects should be unique for each browser, so why are there conflict errors on them ?????
If ZEO cannot reach your product (import it), it cannot run any conflict resolution. Make sure that the ZEO server setup has access to those Products that do conflict resolution.
The product that does conflict resolution is the Transient object (I think it is the session object) , which is Zope2.9.0/lib/python/Products/Transcience. I think that zeo should see it. 2007/1/25, yacine chaouche <yacinechaouche@gmail.com>:
Is _p_resolveConflict method of Inceraser executed at all? I wonder if traceback you see in console is from the code you added: traceback.print_exc(file=stdin)
or it is always shown when there is a conflict error.
<code> def _p_resolveConflict(self, old, state1, state2): print "called the _p_resolveConflict of the Increaser object",self try: number = max(old,state1,state2) except Exception,msg: import traceback traceback.print_exc(file=sys.stdin) return max(old, state1, state2)
</code>
Yes, The method was not called. However, the traceback was indeed printed by the print_exc, since there were no tracebacks before I added this line. In fact, as Gabriel Genellina said :
That might provoke a ConflictError, forcing a transaction abort and the request to be re-tried (up to three times, silently, then it goes logged).
as well as Pascal Peregrina:
In general, retry is called when a ZODB Conflict Error has happened. If I remember well, Zope will silently retry 3 times, and then actually return an error page showing the Conflict Error.
as the documentation says http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx :
"If an unhandled exception is raised during the publishing process, Zope aborts the transaction. As detailed in Chapter 4. Zope handles ConflictErrors by re-trying the request up to three times. This is done with the zpublisher_exception_hook."
Thus, I don't think that the traceback is always shown when there's a conflict error.
So I decided to look into the file suggested by Maciej Wisniowski :
You may take a look at lib/python/ZODB/ConflictResolution.py method: tryToResolveConflict. There is a call to _p_resolveConflict.
and edited it like this :
<code> def tryToResolveConflict(self, oid, committedSerial, oldSerial, newpickle, committedData=''): # class_tuple, old, committed, newstate = ('',''), 0, 0, 0 print "in ConflictResolution.py, called the tryToResolveConflict method with arguments :" print "self",self,"oid",oid.__repr__(),"committedSerial",committedSerial.__repr__(),"oldSerial",oldSerial.__repr__(),"newpickle",newpickle.__repr__(),"committedData",committedData.__repr__()
try: prfactory = PersistentReferenceFactory() file = StringIO(newpickle) unpickler = Unpickler(file) unpickler.find_global = find_global unpickler.persistent_load = prfactory.persistent_load meta = unpickler.load() if isinstance(meta, tuple): klass = meta[0] newargs = meta[1] or () if isinstance(klass, tuple): klass = find_global(*klass) else: klass = meta newargs = ()
if klass in _unresolvable: print "klass",klass.__repr__,"is unresolvable" return None
newstate = unpickler.load() inst = klass.__new__(klass, *newargs)
try: resolve = inst._p_resolveConflict except AttributeError: print inst.__repr__,"has no _p_resolveConflict method" _unresolvable[klass] = 1 return None
old = state(self, oid, oldSerial, prfactory) committed = state(self, oid, committedSerial, prfactory, committedData)
resolved = resolve(old, committed, newstate)
file = StringIO() pickler = Pickler(file,1) pickler.persistent_id = persistent_id pickler.dump(meta) pickler.dump(resolved) print "everything's ok" return file.getvalue(1) except (ConflictError, BadClassName): print "ConflictError during conflict resolution in tryToResolveConflict, ConflictResolution.py" import traceback import sys traceback.print_exc(file = sys.stdout) return None except: print "Exception raised in in tryToResolveConflict, ConflictResolution.py" import traceback import sys traceback.print_exc(file=sys.stdout) # If anything else went wrong, catch it here and avoid passing an # arbitrary exception back to the client. The error here will mask # the original ConflictError. A client can recover from a # ConflictError, but not necessarily from other errors. But log # the error so that any problems can be fixed. logger.error("Unexpected error", exc_info=True) return None
</code>
Now let's see what's going on in the console :
<console> in ConflictResolution.py, called the tryToResolveConflict method with arguments : self <tempstorage.TemporaryStorage.TemporaryStorage instance at 0x43fb6aac> oid '\x00\x00\x00\x00\x00\x00\x00\t' committedSerial '\x03k#\x93\x1d\xff\xf5\x11' oldSerial '\x03k#\x91^t\xf1D' newpickle '( cProducts.Transience.Transience\nIncreaser\nq\x01 )tq\x02.J\x88\xa6\xb8E.' committedData '' ConflictError during conflict resolution in tryToResolveConflict, ConflictResolution.py Traceback (most recent call last): File "/opt/aef/Zope-2.9.0/lib/python/ZODB/ConflictResolution.py", line 126, in tryToResolveConflict old = state(self, oid, oldSerial, prfactory) File "/opt/aef/Zope-2.9.0/lib/python/ZODB/ConflictResolution.py", line 53, in state p = p or self.loadSerial(oid, serial) File "/opt/aef/Zope- 2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 148, in loadSerial raise POSException.ConflictError(oid=oid) ConflictError: database conflict error (oid 0x09)
<comment> the exception is raised up to the publish function, since it has not been catched, and I added up a code to print traceback in the publish function so here it is </comment>
exception raised in the publish module, in function publish Traceback (most recent call last): File "/opt/aef/Zope-2.9.0/lib/python/ZPublisher/Publish.py", line 119, in publish transactions_manager.commit() File "/opt/aef/Zope-2.9.0//lib/python/Zope2/App/startup.py", line 234, in commit transaction.commit() File "/opt/aef/Zope-2.9.0//lib/python/transaction/_manager.py", line 96, in commit return self.get().commit(sub, deprecation_wng=False) File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 380, in commit self._saveCommitishError() # This raises! File "/opt/aef/Zope- 2.9.0//lib/python/transaction/_transaction.py", line 378, in commit self._commitResources() File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 433, in _commitResources rm.commit(self) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 484, in commit self._commit(transaction) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 526, in _commit self._store_objects(ObjectWriter(obj), transaction) File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 554, in _store_objects s = self._storage.store(oid, serial, p, self._version, transaction) File "/opt/aef/Zope-2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 200, in store data=data) ConflictError: database conflict error (oid 0x09, class Products.Transience.Transience.Increaser , serial this txn started with 0x036b23915e74f144 2007-01-25 13:05:22.138314, serial currently committed 0x036b23931dfff511 2007-01-25 13:07:07.031211) </console>
The exception is raised, as the traceback says, in File "/opt/aef/Zope- 2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 148, in loadSerial raise POSException.ConflictError(oid=oid)
Is it normal that the oid, as an argument to tryToResloveConflict, was "\x00\x00\x00\x00\x00\x00\x00\t" then became 0x09 when the exception was raised ?
here's the loadSerial code :
<code> def loadSerial(self, oid, serial, marker=[]): """ this is only useful to make conflict resolution work. It does not actually implement all the semantics that a revisioning storage needs! """ self._lock_acquire() try: data = self._conflict_cache.get((oid, serial), marker) if data is marker: # XXX Need 2 serialnos to pass them to ConflictError-- # the old and the new raise POSException.ConflictError(oid=oid) else: return data[0] # data here is actually (data, t) finally: self._lock_release()
</code>
2007/1/25, Martijn Pieters <mj@zopatista.com>:
On 1/24/07, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
Another question, do you use ZEO? I know there were some issues with _p_resolveConflict and ZEO (at last in Zope 2.8.x). Result was that with ZEO setup _p_resolveConflict was not called at all. There is solution for this but I don't know if this is your case especially that you are dealing with TemporaryStorage which is typically managed by ZEO Client...
If ZEO cannot reach your product (import it), it cannot run any conflict resolution. Make sure that the ZEO server setup has access to those Products that do conflict resolution.
-- Martijn Pieters
yacine chaouche wrote at 2007-1-24 18:23 +0100:
As Gabriel Genellina said earlier in this discussion, the probleme could come from the dicoLignes variable that is stored in the session.I don't get it, the exception says that the Increaser object is responsible of the conflict error :
ZODB.POSException.ConflictError database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b192256c66688 2007-01-23 16:34:20.337891, serial currently committed 0x036b19236a4be0ee 2007-01-23 16:35:24.913219)
But the Increaser class has a _p_resolveConflict method :
In order to resolve a conflict, the storage must have sufficient history to deliver the old state. A "TemporaryStorage" has only a very limited history -- way to often not enough for conflict resolution. -- Dieter
participants (7)
-
Andreas Jung -
Dieter Maurer -
Gabriel Genellina -
Maciej Wisniowski -
Martijn Pieters -
Pascal Peregrina -
yacine chaouche