| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Fixed temporary dir removing.
Fixed printing path to log.
Module checks moved to the separate file.
|
|
|
|
|
|
|
|
This is required for more flexible Python version check since ASGI works
for Python 3.5+. Version check via 'startswith()' function removed as
not consistent.
|
|
Also fixed problem with "/" in application name.
|
|
The patch required to process non-101 response.
|
|
No functional changes. Only code readability improved.
|
|
|
|
|
|
|
|
|
|
Messed up return values in nxt_upstream_find() caused error in applying any
configuration with a valid "pass" value in router configuration pointing to
upstream. That wasn't the case in "listeners" objects, where the return value
wasn't checked.
Also, it caused segfault in cases where the "pass" option was configured with
variables and resulting value was pointing to a non-existent upstream.
Added missing return checks as well to catch possible memory allocation errors.
The bug was introduced in d32bc428f46b.
This closes #472 issue on GitHub.
|
|
|
|
Also added few tests for $uri and minor style fixes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each application initializes a shared port with 2 file descriptors, so the test
fails because the router reaches the open files limit.
|
|
This is a temporary solution after the 'shared port' patch. The application
process becomes idle immediately after creation. Even if it starts processing
a request (without acknowledging it yet), it is stopped by the router because
an 'out-of-idle-time' event occurs.
|
|
|
|
|
|
|
|
This is another attempt to fix the following error message:
BlockingIOError: [Errno 11] write could not complete without blocking
|
|
Matching 'start' and 'end' position now adjusted to avoid false matching.
This is related to #434 issue on Github.
Thanks to 洪志道 (Hong Zhi Dao).
|
|
|
|
opcache_get_status() returns array, so square brackets
should be used to access "opcache_enabled" value.
|
|
|
|
|
|
The process abstraction has changed to:
setup(task, process)
start(task, process_data)
prefork(task, process, mp)
The prefork() occurs in the main process right before fork.
The file src/nxt_main_process.c is completely free of process
specific logic.
The creation of a process now supports a PROCESS_CREATED state. The
The setup() function of each process can set its state to either
created or ready. If created, a MSG_PROCESS_CREATED is sent to main
process, where external setup can be done (required for rootfs under
container).
The core processes (discovery, controller and router) doesn't need
external setup, then they all proceeds to their start() function
straight away.
In the case of applications, the load of the module happens at the
process setup() time and The module's init() function has changed
to be the start() of the process.
The module API has changed to:
setup(task, process, conf)
start(task, data)
As a direct benefit of the PROCESS_CREATED message, the clone(2) of
processes using pid namespaces now doesn't need to create a pipe
to make the child block until parent setup uid/gid mappings nor it
needs to receive the child pid.
|
|
Thanks to hongzhidao.
|
|
|
|
|
|
|
|
|
|
|
|
This is useful to escape "/" in path fragments. For example, in order
to reference the application named "foo/bar":
{
"pass": "applications/foo%2Fbar"
}
|
|
|
|
|
|
|
|
|
|
|
|
One of the ways to detect Unit's startup and subsequent readiness to accept
commands relies on waiting for the control socket file to be created.
Earlier, it was unreliable due to a race condition between the client's
connect() and the daemon's listen() calls after the socket's bind() call.
Now, unix domain listening sockets are created with a nxt_listen_socket_create()
call as follows:
s = socket();
unlink("path/to/socket.tmp")
bind(s, "path/to/socket.tmp");
listen(s);
rename("path/to/socket.tmp", "path/to/socket");
This eliminates a time-lapse when the socket file is already created but nobody
is listening on it yet, which therefore prevents the condition described above.
Also, it allows reliably detecting whether the socket is being used or simply
wasn't cleaned after the daemon stopped abruptly. A successful connection to
the socket file means the daemon has been started; otherwise, the file can be
overwritten.
|
|
|
|
|
|
|
