A "while_serving" decorator? about hypercorn

[pgjones]

Not sure what the use case is here, why would you want the server to die completely? (Wouldn't you want it to close idle connections but listen for new ones).

[jonozzz]

I need to programmatically spin up a sever and a client to test an external load balancer. Having a server that runs forever is not really an option.

[pgjones]

Could you do something like this?

def shutdown():
    raise Shutdown()  # Or maybe sys.exit?

loop = asyncio.get_event_loop()
loop.call_later(1, shutdown)
loop.run_until_complete(serve(app, config))

I'm not sure this is a common enough use case to be part of Hypercorn.

[jonozzz]

One issue with that might be that "serve" would want to call run_forever at some point which is not possible, since the loop is already running.

I don't think it'd be too complicated to add, I see it as an addition to the "before_serving" and "after_serving" decorators.

[pgjones]

In this case serve is a coroutine, 1ecfcc3 so the run_until_complete shouldn't be an issue.

I see it as an addition to the "before_serving" and "after_serving" decorators.

So when would it be called? Some options I can think of are, after the first request, after every request, periodically (what period).

[jonozzz]

Is this serve() in the latest hypercorn version only compatible with quart 0.7.x? I can't make it work with quart 0.6 version on python 3.6.

[pgjones]

It should work with 0.6 on Python 3.6, what is the error you are getting? (I've not released it yet though).

[jonozzz]

Getting something like this

  File "http2_server.py", line 203, in run
    loop.run_until_complete(serve(app, config))
  File "/usr/lib/python3.6/asyncio/base_events.py", line 473, in run_until_complete
    return future.result()
  File "xyz/tmp/hypercorn/hypercorn/asyncio/__init__.py", line 31, in serve
    await worker_serve(app, config)
  File "xyz/tmp/hypercorn/hypercorn/asyncio/run.py", line 133, in worker_serve
    await lifespan.wait_for_startup()
  File "xyz/tmp/hypercorn/hypercorn/asyncio/lifespan.py", line 47, in wait_for_startup
    await asyncio.wait_for(self.startup.wait(), timeout=self.config.startup_timeout)
  File "/usr/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

Runnning on:

Python 3.6.5
Quart                     0.6.11     
Hypercorn                 0.4.6      (from master)

[jonozzz]

Here's an update... Enabled some error logging and got:
ASGI Framework Lifespan error, continuing without Lifespan support

Quart 0.6 doesn't seem to have the "lifespan" scope type.

[pgjones]

I've just tested this and it works ok for me (the ASGI Framework Lifespan error, continuing without Lifespan support is a warning that is safe to ignore with Quart 0.6). I think you likely have a before_serving function that doesn't complete e.g. the first snippet in this thread. Could you paste your before_serving function(s)?

[jonozzz]

I removed any decorators I had:

    config = Config()
    config.error_log_target = '-'
    config.certfile = certfile
    config.keyfile = keyfile
    config.bind = ["127.0.0.1:8002"]

    loop = asyncio.get_event_loop()
    loop.run_until_complete(serve(app, config))

How did you test it and how do you know it's working? The timeout exception comes after 1-2 minutes and until then any requests coming in are being refused.

[pgjones]

I see, it was a race condition - I've fixed it in 16b0ae8 could you see if it works for you?

[jonozzz]

Works now!
Back to my initial ask, I poked around the code a bit and noticed that you have a shutdown_event argument that I could use, but it doesn't bubble up to serve(). Any reason why it doesn't?
https://github.com/pgjones/hypercorn/blob/master/hypercorn/asyncio/run.py#L128

Also, would it make sense to have a similar startup_event or something like that, that's set when the server is ready to take new connections?

[pgjones]

I think your use case might be too specific for Hypercorn to support directly, I think the before/after serving functionality should cover almost all use. I'm actually not sure how it doesn't cover your case (I think it should).

[jonozzz]

But would it make sense to expose shutdown_event kwarg to serve coro?

[pgjones]

I don't think so as I'd like to keep the public API as simple as possible. You could use the worker_serve coro though (basically serve with the shutdown_event).

[pgjones]

Closing for now