Issue #606 resolved

Problem timing out the persitent connection when SSL is enabled

Anonymous created an issue

When using SSL on cherrypy 3.0 (from the trunk) persistent connections remain... persistent, they don't timeout, so auto-reload can't kick in and control+c doesn't shut down the service.

I tried with a simple server: {{{ import cherrypy

cherrypy.config.update({ 'global': { 'server.ssl_certificate': 'ssl.crt', 'server.ssl_private_key': 'ssl.key', } })

class root: def index(self): return 'ok' index.exposed = True cherrypy.quickstart(root(), '/') }}}

I can modify the script and auto-reload kicks in immediately, but If I request the a page (the index in this case), the server doesn't close the connection and it doesn't timeout, so cherrypy can't stop, without SSL it times out immediately when a stop is requested. This is the source of my recent constant kill -9s.

I can't seem to find how to fix it.

Reported by Sheco

Comments (11)

  1. Robert Brewer

    Well, I did some work on test_states.py to test it with SSL. After fixing up the test code, it seems that autoreload and KeyboardInterrupt work just fine with SSL. Perhaps you could upgrade to trunk and see if test_states passes on your platform?

    python cherrypy/test/test_states.py -ssl
    
  2. Anonymous

    The test_states.py -ssl passes.

    But the server is still unable to stop() after serving a request, the request thread blocks and it doesn't timeout/close.

  3. Robert Brewer

    I'm afraid I still don't understand the order of operations you're trying that fails. The order in test_states.test_4_Autoreload is:

    1. Start the app 2. Make a page request 3. Modify the app script 4. Wait for autoreload to finish 5. Make the same page request again 6. Request a page that calls engine.stop and server.stop 7. Assert that the app's process terminates

    This works with or without the -ssl switch. How does your situation differ? Are you requesting a page while autoreload is still doing its thing?

  4. Anonymous

    That's what I do, run cherrypy, request a page, interrupt cherrypy. It doesn't stop, but I just found out it does stop, it just takes it a long time to do so.

    A log says more than a thousand words:

    [30/Nov/2006:14:58:37] HTTP Serving HTTPS on https://localhost:8080/
    some.ip.of.mine - - [30/Nov/2006:14:58:53] "GET / HTTP/1.1" 200 2 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0"
    some.ip.of.mine - - [30/Nov/2006:14:58:53] "GET /favicon.ico HTTP/1.1" 200 1406 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0"
    [30/Nov/2006:14:58:56] ENGINE <Ctrl-C> hit: shutting down app engine
    [30/Nov/2006:15:04:06] HTTP HTTP Server shut down
    [30/Nov/2006:15:04:06] ENGINE CherryPy shut down
    
    

    Ok now without a request:

    [30/Nov/2006:15:06:02] HTTP Serving HTTPS on https://localhost:8080/
    [30/Nov/2006:15:06:06] ENGINE <Ctrl-C> hit: shutting down app engine
    [30/Nov/2006:15:06:06] HTTP HTTP Server shut down
    [30/Nov/2006:15:06:06] ENGINE CherryPy shut down
    

    Again with a request... it was slightly faster...

    [30/Nov/2006:15:06:28] HTTP Serving HTTPS on https://localhost:8080/
    some.ip.of.mine - - [30/Nov/2006:15:06:32] "GET / HTTP/1.1" 200 2 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0"
    [30/Nov/2006:15:06:36] ENGINE <Ctrl-C> hit: shutting down app engine
    [30/Nov/2006:15:07:51] HTTP HTTP Server shut down
    [30/Nov/2006:15:07:51] ENGINE CherryPy shut down
    

    One last one...

    [30/Nov/2006:15:08:40] HTTP Serving HTTPS on https://localhost:8080/
    some.ip.of.mine - - [30/Nov/2006:15:08:44] "GET / HTTP/1.1" 200 2 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0"
    [30/Nov/2006:15:08:47] ENGINE <Ctrl-C> hit: shutting down app engine
    [30/Nov/2006:15:09:19] HTTP HTTP Server shut down
    [30/Nov/2006:15:09:19] ENGINE CherryPy shut down
    

    Time it took to close the server, in these tests:

    1:5 mins
    2:0 secs
    3:1 min and a half
    4:around 30 seconds
  5. Anonymous

    I said the tests in test_states passed, but now the autoreload test is not working, I don't know why they passed the other day I tried, here's the output (by the way, are the logger warnings normal?)

    test_4_Autoreload (__main__.ServerStateTests) ... No handlers could be found for logger "cherrypy.access.-1210978516"
    No handlers could be found for logger "cherrypy.error"
    FAIL
    
    ======================================================================
    FAIL: test_4_Autoreload (__main__.ServerStateTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/sduran/mirc.com.mx/cherrypy/test/cherrypy/test/cherrypy/test/webtest.py", line 262, in __call__
        testMethod()
      File "test_states.py", line 267, in test_4_Autoreload
        self.assertNotEqual(self.body, pid)
    AssertionError: '8483' == '8483'
    
    FAILED (failures=1)
    
  6. Robert Brewer
    AssertionError: '8483' == '8483'
    

    Hm. Unfortunately, that ''could'' just be coincidence; perhaps your platform is assigning the same pid to the new process as the terminated one.

    The logging warnings are normal.

  7. Anonymous

    The problem only happens when accessing the service from a remote machine , accessing it via localhost doesn't have any problems.

    I don't test my applications locally, I run a virtual machine which I access from the host computer, I also have some applications running in a hosting server.

    Hope this helps.

  8. Anonymous

    Doing some tests with the test_states_demo.py

    I've been using this command:

    python test_states_demo.py "" 8080
    

    This table shows an average of seconds it took to close the server (with Ctrl+C).

    With local, I used lynx http://localhost:8080 With remote, I used firefox http://192.168.1.2:8080 from another computer.

    sourcehttphttps
    local01
    remote560
  9. Robert Brewer

    I think this is officially fixed in [1477]. This is a different solution than the one worked out on IRC; but that was more of a band-aid that managed the problem rather than fixing it.

  10. Log in to comment