Instead log and send an internal error status back to the client.
This should be OK as long as the exception doesn't happen after
the caller called req.response() already.
Now you can create a pyko application skeleton using kodev:
$ kodev create -p myapp
Not sure if this functionality will remain in kodev, but for now i'm undecided.
This function now takes any remaining arguments passed on the command line
after kore parsed its own.
For C the new prototype looks like this:
void kore_parent_configure(int argc, char **argv);
For python code, kore will pass each argument to the function so you
can do things like:
def kore_parent_configure(arg1, arg2):
Before kodev always picked up the kore headers installed on the system.
This presented some annoying problems as the system headers may not
match the headers used by the kore_source you're actually building
against.
This option allows a user to finetune the number of milliseconds
a worker process will max spend inside the http_process() loop.
By default this is 10ms.
Do not run the idle timer check for client if it still has a request
queued up. Otherwise if the worker process is very busy you might hit
the timeout even though the client sent us a full request which was queued.
The HTTP layer used to make a copy of each incoming header and its
value for a request. Stop doing that and make HTTP headers zero-copy
all across the board.
This change comes with some api function changes, notably the
http_request_header() function which now takes a const char ** rather
than a char ** out pointer.
This commit also constifies several members of http_request, beware.
Additional rework how the worker processes deal with the accept lock.
Before:
if a worker held the accept lock and it accepted a new connection
it would release the lock for others and back off for 500ms before
attempting to grab the lock again.
This approach worked but under high load this starts becoming obvious.
Now:
- workers not holding the accept lock and not having any connections
will wait less long before returning from kore_platform_event_wait().
- workers not holding the accept lock will no longer blindly wait
an arbitrary amount in kore_platform_event_wait() but will look
at how long until the next lock grab is and base their timeout
on that.
- if a worker its next_lock timeout is up and failed to grab the
lock it will try again in half the time again.
- the worker process holding the lock will when releasing the lock
double check if it still has space for newer connections, if it does
it will keep the lock until it is full. This prevents the lock from
bouncing between several non busy worker processes all the time.
Additional fixes:
- Reduce the number of times we check the timeout list, only do it twice
per second rather then every event tick.
- Fix solo worker count for TLS (we actually hold two processes, not one).
- Make sure we don't accidentally miscalculate the idle time causing new
connections under heavy load to instantly drop.
- Swap from gettimeofday() to clock_gettime() now that MacOS caught up.
Limits the number of queued asynchronous queries kore will allow
before starting to return errors for KORE_PGSQL_ASYNC setups.
By default set to 1000.
Avoids uncontrolled growth of the pgsql_queue_wait pool.
Before http_request_limit just constrained the number of HTTP
requests we'd deal with in a single http_process_requests() call.
But it should really mean how many maximum HTTP requests are allowed
to be alive in the worker process before we start sending 503s back.
While here, drop the lock timeout for a worker to 100ms down from 500ms
and do not allow a worker to grab the accept lock if their HTTP request
queue is full.
This makes things much more pleasant memory wise as the http_request_pool
won't just grow over time.
Before params get would mean querystring and anything else
would just count toward a www-encoded body.
Now you can prefix the params block with "qs" indicating that
those configured parameters are allowed to occur in the query
string regardless of the method used.
This means you can do something like:
params qs:post /uri {
...
}
to specify what the allowed parameters are in the querystring for
a POST request towards /uri.
inspired by and properly fixes#205.
build the frame in a kore_buf on the stack and use net_send_stream()
to push it out rather then making yet another copy in net_send().
saves several cpu cycles before the frame starts going out as
we're not allocating a kore_buf, its contents and then memcpy()ing
that contents to a new netbuf.
doing this allows us to get rid of the validator reload
and handler reload as well as fixing websocket runtime
callbacks which were never being resolved upon module reloads.
This allows modules that have global pointers to upon reload repopulate
those with the addresses of when they were first created.
Meaning it now is easier to write modules that can be reloaded if those
modules kept global state one way or the other.
This should only be used at module init/reload time and is very simple:
if ((ptr = kore_mem_lookup(MY_ID_VALUE)) == NULL) {
ptr = kore_malloc_tagged(length, MY_ID_VALUE);
/* initialize for the first time. */
}
If we were in a reload the kore_mem_lookup() will return the original address
returned by the initial kore_malloc_tagged() call for MY_ID_VALUE.
- make sure conn_count per pgsqldb structure is initialized to 0.
- allow pgsql_conn_max to be 0, meaning just create a new connection
if none was free.
if we fail at rolling back an in-error transaction on a connection
just remove that connection and go back to rescanning rather then
returning an error to the caller, there may be more functional
connections in the pipeline.
- Make pgsql_conn_count count per database rather then globally.
This means you now define the number of clients *per* database registered
rather then the number of clients in total of all databases.
- In case a connection is in failed transaction state Kore will now
automatically rollback the transaction before placing that connection
back in the connection pool.
LibreSSL defines OPENSSL_VERSION_NUMBER as 0x20000000L but does not have
the 1.1.0 API so we have to carefully check for LIBRESSL_VERSION_TEXT as
well before using that new API.
Eventually I will phase out 1.0.2 down the line to get rid of the
nightmare that is the 2 different APIs.
This commit adds full support for building kore with 1.1.0e while
retaining the privsep keymanager support.
based on excellent work done by @hiwk.