1) True
2) Basically true. You seem to indicate that 1 & 2 should not co-
exist or are somehow at odds with each other. If that's what you're
indicating, I'm not following your logic as to why they should be
mutually exclusive. Can you explain a little more?
3) In Rocket's case, no. While a client could disconnect at anytime,
Rocket will allow the application server to run a request as long as
it likes. If the client connection is still open when it's ready to
send it's response, it will send successfully. Rocket does not kill
threads that run for "too long".
4) Rocket always applies the socket timeout (rocket.py line 854), this
should override Py2.5's default (whatever it may be). Rocket enables
Python's socket timeout protection on every Python platform that
supports it.
Does this clear things up?
On Jul 4, 4:30 am, Iceberg <iceb...@21cn.com> wrote:
> Thanks for all these info, Tim. You said:
> "The timeout ... is a timeout based on inactivity between http
> requests. So the long requests that Iceberg is seeing are perfectly
> normal and acceptable."
>
> According to my reading of the rocket-science code (and I could be
> wrong), here is my understanding and questions:
>
> 1. The timeout is a timeout based on inactivity since one request
> socket's latest select-and-readable event. The time gap could be
> caused by two http requests which somehow reuse the socket (because
> keep-alive?), or caused by one very slow http request from a client
> (possibly a DoS attack).
>
> 2. BUT the timeout check is only performed after the request's
> socket encountered socket.timeout exception. According to line 800 of
> rocket.py:
> if typ == SocketTimeout:
> self.err_log.debug('Socket timed out')
> self.wait_queue.put(self.conn)
> And then the request's control is transferred to the Monitor, the
> timeout check is at line 449 of rocket.py:
> if now - c.start_time >= self.timeout:
> stale.add(c)
>
> 3. What if, a normal request is read from client side within
> seconds, then being calculated for quite some time on the server side,
> will this situation trigger the timeout protection? I guess not,
> because no socket.timeout will be raised during the calculation,
> although the final calculated result will probably not be sent due to
> the socket is already timeout or even closed from the client side. If
> this is true (is it?), then my maintenance scenario is still doable
> because no result is expected, I only need the maintenance job can be
> triggered and can run as long as it takes.
>
> 4. On the other hand, at least on Windows XP, python 2.5.4, by
> default, socket has no socket.timeout, so the above check is not
> performed at all, is it? So the rocket timeout protection is not
> activated anyway.
>
> --
> Iceberg
>
> On Jul4, 9:26am, Timbo <tfarr...@owassobible.org> wrote:
>
>
>
> > Rocket has a longer default wait time before it closes connections in
> > comparison to CherryPy. You might check web2py code, it is not likely
> > using the same default timeout as Rocket proper.
> > See:http://packages.python.org/rocket/usage.html#timeout
>
> > This is a DoS vulnerability on CherryPy but not Rocket because Rocket
> > pushes waiting threads to a monitor queue so that they don't occupy
> > worker threads. The monitor queue can easily handle the socket limit
> > of connections. In this manner, Rocket can handle many thousands of
> > connections without causing new connections to have to wait as
> > CherryPy does. There is a limit on number of active connections, but
> > that limit is the number of worker threads which is
> > configurable:http://packages.python.org/rocket/usage.html#max-threads
>
> > The timeout mentioned in the link above is a timeout based on
> > inactivity between http requests. So the long requests that Iceberg
> > is seeing are perfectly normal and acceptable.
>
> > Browsers such as Chrome and FF will leave a connection open for quite
> > some time or until the tab is closed (even if the user has browsed
> > away from the Rocket-running server domain). Rocket basically wants
> > to keep those connections open since they don't cost significantly to
> > wait in the monitor queue.
>
> > -tim
>
> > On Jul 3, 9:35 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > Let's wait for Tim to respond. The timeout should be enforced.
>
> > > On 3 Lug, 09:07, Iceberg <iceb...@21cn.com> wrote:
>
> > > > Thanks for clarifying. And I take a glance into gluon/widget.py,
> > > > main.py and rocket.py to confirm there is some timeout=10. So from the
> > > > design aspect, I'd better avoid expecting a long-run request to finish
> > > > my app's time-consuming maintenance job.
>
> > > > On the other hand, I confirmed that, with latest trunk, running
> > > > Windows XP, my maintenance request did last for more than 10 seconds,
> > > > magically. Does it indicate the DoS-resistant timeout fuse somehow
> > > > fail? Do you think it is ok or unacceptable?
>
> > > > My maintenance job's log:
> > > > WARNING:root:job.id=33, elapsed=18.8129999638 s
>
> > > > Another evidence in web2py/httpserver.log
> > > > 127.0.0.1, 2010-07-03 21:49:20, GET, /myapp/default/longrun, HTTP/
> > > > 1.1, 200, 21.750000
>
> > > > Regard,
> > > > Iceberg
>
> > > > On Jul3, 8:31pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > > The web server threads MUST have a timeout (the shorter the better)
> > > > > else they are vulnerable to denial of service attacks.
>
> > > > > On 3 Lug, 06:23, Iceberg <iceb...@21cn.com> wrote:
>
> > > > > > Hi Candid and everyone,
>
> > > > > > Candid mentioned "rocket should close the connections if request is
> > > > > > taking longer than 10 seconds (default timeout)" in here [1]. Would
> > > > > > somebody clarify, is that true?
>
> > > > > > My concern is that, one of my old app need some periodical
> > > > > > maintenance
> > > > > > job which could take dozes of seconds to finish. I knew the normal
> > > > > > solution is run another daemon for that, but, for simplicity
> > > > > > reasons,
> > > > > > I still chose to use web2py 's builtin cron feature to
> > > > > > visithttp://localhost:8000/myapp/default/maintenanceeveryhour. This
> > > > > > trick
> > > > > > worked well on my windows XP development laptop. I don't know
> > > > > > whether
> > > > > > situation is changed since then.
>
> > > > > > [1]http://groups.google.com/group/web2py/msg/0416ed025f3e33f8
>
> > > > > > Regards,
> > > > > > Iceberg
