> It seems that this could be an cherrypy wsgiserver issue and Massimo
> Di Pierro suggested to bring the thread up in cherrypy mailing list.
A broken pipe error (EPIPE, 32) occurs in this case because the server
encountered some other error, and tried to send a "500 Internal Server
Error" response. While trying to write *that* data to the socket, the
client's TCP stack sent a RST packet because they had already closed
the socket.
Unfortunately, there's a line of code in the SSL_fileobject for
handling errors which reads:
if is_reader and errnum in socket_errors_to_ignore:
return ""
EPIPE is definitely in the list of socket errors to ignore, but I
can't recall why we would only ignore them on reads and not writes
when using SSL. In this case, we certainly should be ignoring the
error. You might try removing the text "is_reader and" and see what
else breaks because of it.
After applying your advise we have the following output:
Exception in thread CP WSGIServer Thread-10:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
File "/home/todork/web2py/gluon/wsgiserver.py", line 1004, in run
conn.communicate()
File "/home/todork/web2py/gluon/wsgiserver.py", line 949, in
communicate
format_exc())
File "/home/todork/web2py/gluon/wsgiserver.py", line 643, in
simple_response
self.sendall(''.join(buf))
File "/home/todork/web2py/gluon/wsgiserver.py", line 792, in
ssl_method_wrapper
return method(self, *args, **kwargs)
Error: [('SSL routines', 'SSL3_WRITE_PENDING', 'bad write retry')]
I would like to mention that this server is running on embedded
system.
And the strange thing is that in different IP environment the systems
behaves differently. In my office it works perfectly and in home we
have these errors.
Always the browser is FF.
Sincerely,
Todor
On 27 Юни, 21:48, fumanchu <fuman...@aminus.org> wrote:
> > It seems that this could be an cherrypy wsgiserver issue and Massimo
> > Di Pierro suggested to bring the thread up in cherrypy mailing list.
> A broken pipe error (EPIPE, 32) occurs in this case because the server
> encountered some other error, and tried to send a "500 Internal Server
> Error" response. While trying to write *that* data to the socket, the
> client's TCP stack sent a RST packet because they had already closed
> the socket.
> Unfortunately, there's a line of code in the SSL_fileobject for
> handling errors which reads:
> if is_reader and errnum in socket_errors_to_ignore:
> return ""
> EPIPE is definitely in the list of socket errors to ignore, but I
> can't recall why we would only ignore them on reads and not writes
> when using SSL. In this case, we certainly should be ignoring the
> error. You might try removing the text "is_reader and" and see what
> else breaks because of it.
now some time I still obtain *ssl3_write_pending* error but the
wsgiserver do not hangup and it seems that the affected thread are
released after some timeout.
The strange thing is that this patch is released in 2006 and (I am
using OpenSSL 0.9.8k 25 Mar 2009) it is not included in the releases
up to now.
Thanks,
Todor
On 27 Юни, 23:06, todor_k <todo...@ecocoms.com> wrote:
> After applying your advise we have the following output:
> Exception in thread CP WSGIServer Thread-10:
> Traceback (most recent call last):
> File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
> File "/home/todork/web2py/gluon/wsgiserver.py", line 1004, in run
> conn.communicate()
> File "/home/todork/web2py/gluon/wsgiserver.py", line 949, in
> communicate
> format_exc())
> File "/home/todork/web2py/gluon/wsgiserver.py", line 643, in
> simple_response
> self.sendall(''.join(buf))
> File "/home/todork/web2py/gluon/wsgiserver.py", line 792, in
> ssl_method_wrapper
> return method(self, *args, **kwargs)
> Error: [('SSL routines', 'SSL3_WRITE_PENDING', 'bad write retry')]
> I would like to mention that this server is running on embedded
> system.
> And the strange thing is that in different IP environment the systems
> behaves differently. In my office it works perfectly and in home we
> have these errors.
> Always the browser is FF.
> Sincerely,
> Todor
> On 27 Юни, 21:48, fumanchu <fuman...@aminus.org> wrote:
> > On Jun 27, 2:23 am, todor_k <todo...@ecocoms.com> wrote:
> > > in web2py Web Framework group we posted a thread for a "communication
> > > and socket error"
> > > It seems that this could be an cherrypy wsgiserver issue and Massimo
> > > Di Pierro suggested to bring the thread up in cherrypy mailing list.
> > A broken pipe error (EPIPE, 32) occurs in this case because the server
> > encountered some other error, and tried to send a "500 Internal Server
> > Error" response. While trying to write *that* data to the socket, the
> > client's TCP stack sent a RST packet because they had already closed
> > the socket.
> > Unfortunately, there's a line of code in the SSL_fileobject for
> > handling errors which reads:
> > if is_reader and errnum in socket_errors_to_ignore:
> > return ""
> > EPIPE is definitely in the list of socket errors to ignore, but I
> > can't recall why we would only ignore them on reads and not writes
> > when using SSL. In this case, we certainly should be ignoring the
> > error. You might try removing the text "is_reader and" and see what
> > else breaks because of it.
> now some time I still obtain *ssl3_write_pending* error but the
> wsgiserver do not hangup and it seems that the affected thread are
> released after some timeout.
> The strange thing is that this patch is released in 2006 and (I am
> using OpenSSL 0.9.8k 25 Mar 2009) it is not included in the releases
> up to now.
> Thanks,
> Todor
> On 27 Юни, 23:06, todor_k <todo...@ecocoms.com> wrote:
> > Thanks for the help.
> > After applying your advise we have the following output:
> > Exception in thread CP WSGIServer Thread-10:
> > Traceback (most recent call last):
> > File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
> > File "/home/todork/web2py/gluon/wsgiserver.py", line 1004, in run
> > conn.communicate()
> > File "/home/todork/web2py/gluon/wsgiserver.py", line 949, in
> > communicate
> > format_exc())
> > File "/home/todork/web2py/gluon/wsgiserver.py", line 643, in
> > simple_response
> > self.sendall(''.join(buf))
> > File "/home/todork/web2py/gluon/wsgiserver.py", line 792, in
> > ssl_method_wrapper
> > return method(self, *args, **kwargs)
> > Error: [('SSL routines', 'SSL3_WRITE_PENDING', 'bad write retry')]
> > I would like to mention that this server is running on embedded
> > system.
> > And the strange thing is that in different IP environment the systems
> > behaves differently. In my office it works perfectly and in home we
> > have these errors.
> > Always the browser is FF.
> > Sincerely,
> > Todor
> > On 27 Юни, 21:48, fumanchu <fuman...@aminus.org> wrote:
> > > On Jun 27, 2:23 am, todor_k <todo...@ecocoms.com> wrote:
> > > > in web2py Web Framework group we posted a thread for a "communication
> > > > and socket error"
> > > > It seems that this could be an cherrypy wsgiserver issue and Massimo
> > > > Di Pierro suggested to bring the thread up in cherrypy mailing list.
> > > A broken pipe error (EPIPE, 32) occurs in this case because the server
> > > encountered some other error, and tried to send a "500 Internal Server
> > > Error" response. While trying to write *that* data to the socket, the
> > > client's TCP stack sent a RST packet because they had already closed
> > > the socket.
> > > Unfortunately, there's a line of code in the SSL_fileobject for
> > > handling errors which reads:
> > > if is_reader and errnum in socket_errors_to_ignore:
> > > return ""
> > > EPIPE is definitely in the list of socket errors to ignore, but I
> > > can't recall why we would only ignore them on reads and not writes
> > > when using SSL. In this case, we certainly should be ignoring the
> > > error. You might try removing the text "is_reader and" and see what
> > > else breaks because of it.
> > now some time I still obtain *ssl3_write_pending* error but the
> > wsgiserver do not hangup and it seems that the affected thread are
> > released after some timeout.
> > The strange thing is that this patch is released in 2006 and (I am
> > using OpenSSL 0.9.8k 25 Mar 2009) it is not included in the releases
> > up to now.
> > Thanks,
> > Todor
> > On 27 Юни, 23:06, todor_k <todo...@ecocoms.com> wrote:
> > > Thanks for the help.
> > > After applying your advise we have the following output:
> > > Exception in thread CP WSGIServer Thread-10:
> > > Traceback (most recent call last):
> > > File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
> > > File "/home/todork/web2py/gluon/wsgiserver.py", line 1004, in run
> > > conn.communicate()
> > > File "/home/todork/web2py/gluon/wsgiserver.py", line 949, in
> > > communicate
> > > format_exc())
> > > File "/home/todork/web2py/gluon/wsgiserver.py", line 643, in
> > > simple_response
> > > self.sendall(''.join(buf))
> > > File "/home/todork/web2py/gluon/wsgiserver.py", line 792, in
> > > ssl_method_wrapper
> > > return method(self, *args, **kwargs)
> > > Error: [('SSL routines', 'SSL3_WRITE_PENDING', 'bad write retry')]
> > > I would like to mention that this server is running on embedded
> > > system.
> > > And the strange thing is that in different IP environment the systems
> > > behaves differently. In my office it works perfectly and in home we
> > > have these errors.
> > > Always the browser is FF.
> > > Sincerely,
> > > Todor
> > > On 27 Юни, 21:48, fumanchu <fuman...@aminus.org> wrote:
> > > > On Jun 27, 2:23 am, todor_k <todo...@ecocoms.com> wrote:
> > > > > in web2py Web Framework group we posted a thread for a "communication
> > > > > and socket error"
> > > > > It seems that this could be an cherrypy wsgiserver issue and Massimo
> > > > > Di Pierro suggested to bring the thread up in cherrypy mailing list.
> > > > A broken pipe error (EPIPE, 32) occurs in this case because the server
> > > > encountered some other error, and tried to send a "500 Internal Server
> > > > Error" response. While trying to write *that* data to the socket, the
> > > > client's TCP stack sent a RST packet because they had already closed
> > > > the socket.
> > > > Unfortunately, there's a line of code in the SSL_fileobject for
> > > > handling errors which reads:
> > > > if is_reader and errnum in socket_errors_to_ignore:
> > > > return ""
> > > > EPIPE is definitely in the list of socket errors to ignore, but I
> > > > can't recall why we would only ignore them on reads and not writes
> > > > when using SSL. In this case, we certainly should be ignoring the
> > > > error. You might try removing the text "is_reader and" and see what
> > > > else breaks because of it.
|
