Commits
- Commit:
d046e4d6b500583cda8d2561e47c790eaedd007f
- From:
- Omar Polo <op@omarpolo.com>
- Date:
copy only `len' bytes, not the whole buffer
We ended up copying too much data from the fastcgi process.
- Commit:
efe7d180292726775fb3ae5e6af593490a264c60
- From:
- Omar Polo <op@omarpolo.com>
- Date:
new I/O handling on top of bufferevents
This is a big change in how gmid handles I/O. Initially we used a
hand-written loop over poll(2), that then was evolved into something
powered by libevent basic API. This meant that there were a lot of
small "asynchronous" function that did one step, eventually scheduling
the re-execution, that called each others in a chain.
The new implementation revolves completely around libevent'
bufferevents. It's more clear, as everything is implemented around the
client_read and client_write functions.
There is still space for improvements, like adding timeouts for one, but
it's solid enough to be committed as is and then further improved.
- Commit:
b618111a681d278d0d72fbdb526542bebf8fce02
- From:
- Omar Polo <op@omarpolo.com>
- Date:
log more details for FastCGI errors
add the reported request id if there's a mismatch and both the gai error
and the errno value if getnameinfo fails.
- Commit:
5f37f9c20d1773ad0b95b16f67a33f75fea326f4
- From:
- Omar Polo <op@omarpolo.com>
- Date:
simplify error check
- Commit:
c016b65ca9ca4e4f84f270feb76b1038cb13f358
- From:
- Omar Polo <op@omarpolo.com>
- Date:
typo
- Commit:
741b69be96397e0ec6db0c84b4ead4f41363ea98
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fastcgi completely asynchronous
This changes the fastcgi implementation from a blocking I/O to an
async implementation on top of libevent' bufferevents.
Should improve the responsiveness of gmid especially when using remote
fastcgi applications.
- Commit:
59c7ee13b474c7929914075b01cd3593b1beaca7
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fmt
- Commit:
090b8a89faa34cdc41c41e32845f1f5b444536e4
- From:
- Omar Polo <op@omarpolo.com>
- Date:
gracefully shut down fastcgi backends
we need to delete the events associated with the backends, otherwise
the server process won't ever quit.
Here, we add a pending counter to every backend and shut down
immediately if they aren't handling any client; otherwise we try to
close them as soon as possible (i.e. when they close the connection to
the last connected client.)
- Commit:
e18b070da8296bb0d5e30c8211aba43cb038d427
- From:
- Omar Polo <op@omarpolo.com>
- Date:
indentation
- Commit:
f740b61b03c9e31f4915ee7d7444d64fc320b41c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
more params from and send a custom list
- Commit:
ce2c9edbc230a052627540e3fd0f8a8b190be850
- From:
- Omar Polo <op@omarpolo.com>
- Date:
define and use GMID_VERSION
- Commit:
d1051bfaa091850cc98f54b07577f2f721890acd
- From:
- Omar Polo <op@omarpolo.com>
- Date:
define some more fcgi param
- Commit:
8ad1c570242cd93f0802931621b49b2510b338e7
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fastcgi: a first implementation
Not production-ready yet, but it's a start.
This adds a third ``backend'' for gmid: until now there it served
local files or CGI scripts, now FastCGI applications too.
FastCGI is meant to be an improvement over CGI: instead of exec'ing a
script for every request, it allows to open a single connection to an
``application'' and send the requests/receive the responses over that
socket using a simple binary protocol.
At the moment gmid supports three different methods of opening a
fastcgi connection:
- local unix sockets, with: fastcgi "/path/to/sock"
- network sockets, with: fastcgi tcp "host" [port]
port defaults to 9000 and can be either a string or a number
- subprocess, with: fastcgi spawn "/path/to/program"
the fastcgi protocol is done over the executed program stdin
of these, the last is only for testing and may be removed in the
future.
P.S.: the fastcgi rule is per-location of course :)