It seems changing SOCKET_TIMEOUT does not help too... It is not the first issue I found on running it on MAC OSX.
Well I will try to run it out on a linux server and see what happens... I appreciate very much all your help! Thanks On Tuesday, October 28, 2014 7:44:38 PM UTC-2, Derek wrote: > > And after more investigation, it could be your build of python... there's > a lot of reading, but it comes down to a broken 'poll' on osx, and suggests > compiling a python interpreter that doesn't use it. > > https://bitbucket.org/cherrypy/cherrypy/issue/598 > > > > On Tuesday, October 28, 2014 1:03:18 PM UTC-7, Derek wrote: >> >> In any case, you may want to consider using servers other than Rocket. >> Web2py comes with "anyserver.py" which you can use to run Web2Py under >> Cherrypy, or many other different servers. Give 'CherryPy' a try and see if >> that alleviates your problems. >> >> On Tuesday, October 28, 2014 12:54:26 PM UTC-7, Derek wrote: >>> >>> I've looked at other bugs similar to this one, and one reports that on >>> 32-bit Python, 2gb seems to be the largest amount of data you can send in >>> one sendall. >>> >>> On Tuesday, October 28, 2014 10:35:10 AM UTC-7, André Kablu wrote: >>>> >>>> Thanks Derek, >>>> >>>> But seems this bug in the url you`d posted is related to ftplib and in >>>> my case there are no connections to ftp`s or any other network socket. >>>> >>>> It is only a web2py running local... and seems there are some >>>> limitations on the response size before it is sent to browser, some rocket >>>> limitation or as you said some python lib limitation in OS X. >>>> >>>> :( >>>> >>>> >>>> >>>> On Monday, October 27, 2014 9:33:12 PM UTC-2, Derek wrote: >>>>> >>>>> I stole this answer from stackoverflow... >>>>> >>>>> >>>>> Your server process has received a SIGPIPE writing to a socket. This >>>>> usually happens when you write to a socket fully closed on the other >>>>> (client) side. This might be happening when a client program doesn't wait >>>>> till all the data from the server is received and simply closes a socket >>>>> (using close function). >>>>> >>>>> In a C program you would normally try setting to ignore SIGPIPE signal >>>>> or setting a dummy signal handler for it. In this case a simple error >>>>> will >>>>> be returned when writing to a closed socket. In your case a python seems >>>>> to >>>>> throw an exception that can be handled as a premature disconnect of the >>>>> client. >>>>> In any case, here's the issue as it relates to OSX and Python... >>>>> >>>>> http://bugs.python.org/issue8493 >>>>> >>>>> >>>>> On Monday, October 27, 2014 12:38:02 PM UTC-7, André Kablu wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Anyone can tell me if there are any limitations on response buffer >>>>>> size? >>>>>> >>>>>> I created a proccess that generates 6000 lines, when I try to output >>>>>> them to browser1 i got the error from Rocket: >>>>>> >>>>>> File "/web2py/gluon/rocket.py", line 152, in _sendall_darwin >>>>>> sent = self.socket.send(buf[offset:]) >>>>>> >>>>>> error: [Errno 32] Broken pipe >>>>>> >>>>>> If I try to print 1000 by 1000 it goes smooth.... >>>>>> >>>>>> So I think there may be some limitations on this >>>>>> >>>>>> I am using a MAC OS X w/ 12GB mem >>>>>> >>>>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
