Dario Lopez-Kästen wrote:
Well, sorry to disapoint everybody, but we have the same signal 11 restarts here.
Oh sure, go spoil my "blame it on the other guy" theory.
We are using DCO2 latest from CVS and have _very_ high Oracle database usage.
We have yesterday changed from our solaris box to a linux box and performance has increased dramatically (the linux box ia a 1.8 GHz P3 :).
That's to be expected with the clock speed differences. Unless you use sun's CC, you get fairly poor SPARC code out of gcc, IMHO.
also the threading problems we previously had seem to have dissapeared.
Yah! I think that had to do with the rather *stupid* act of forgetfulness on my part to re-enable python threading around execute().
Now, what can we do to pin down the problem. Is there anyone else that is a heavy databse user on similar circumstances that can share information?
I may see what I can do to try to write a script to be able to invoke gdb in the event of a crash. Stay tuned.
I am starting to suspect that there is some kind of DA problem here...
Actually, since its a mysterious sig 11, it's a C module someplace... there is probably ONE module which is referring to an object after it has been deallocated.
Also, for the record we usually get a bunch of these quite often:
2001-11-04T09:04:33 ERROR(200) ZServer uncaptured python exception, closing channel <zhttp_channel connected XXX.XXX.XXX.XXX:2181 at fb4edc channel#: 2286 requests:4> (socket.error:(32, 'Broken pipe')
[/usr/local/zope/dist/Zope-2.4.1/ZServer/medusa/asynchat.py|initiate_send|21 4] [/usr/local/zope/dist/Zope-2.4.1/ZServer/medusa/http_server.py|send|414] [/usr/local/zope/sw/Python2.1.1/lib/python2.1/asyncore.py|send|330])
We were seeing the same error (asyncore.py|send|330, etc) on solaris.
Any thoughts
Well, that means "the browser user clicked 'stop'" -- Medusa is just telling you the channel went away on it. Thats normal when the browser chops the tcp connection.