Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
If shared queue is empty, allocated read buffer should be explicitly
released.
Found by Coverity (CID 363943).
The issue was introduced in f5ba5973a0a3.
|
|
|
|
|
|
|
|
Removing unnecessary context operations from shared queue processing loop.
Initializing temporary queues only when required.
|
|
|
|
The issue occurred under highly concurrent request load in Go applications.
Such applications are multi-threaded but use a single libunit context; any
thread-safe code in the libunit context is only required for Go applications.
As a result of improper request state reset, the recycled request structure was
recovered in the released state, so further operations with this request
resulted in 'response already sent' warnings. However, the actual response was
never delivered to the router and the client.
|
|
The issue only occurred in Go applications because "port_send" is overloaded
only in Go. To reproduce it, send multiple concurrent requests to the
application after it has initialised. The warning message "[unit] [go] port
NNN:dd not found" is the first visible aspect of the issue; the second and more
valuable one is a closed connection, an error response, or a hanging response to
some requests.
When the application starts, it is unaware of the router's worker thread ports,
so it requests the ports from the router after receiving requests from the
corresponding router worker threads. When multiple requests are processed
simultaneously, the router port may be required by several requests, so request
processing starts only after the application receives the required port
information. The port should be added to the Go port repository after its
'ready' flag is updated. Otherwise, Unit may start processing some requests and
use the port before it is in the repository.
The issue was introduced in changeset 78836321a126.
|
|
Debug logging depends on macros defined in nxt_auto_config.h.
|
|
Previously, all requests that contained in header field names characters other
than alphanumeric, or "-", or "_" were rejected with a 400 "Bad Request" error
response.
Now, the parser allows the same set of characters as specified in RFC 7230,
including: "!", "#", "$", "%", "&", "'", "*", "+", ".", "^", "`", "|", and "~".
Header field names that contain only these characters are considered valid.
Also, there's a new option introduced: "discard_unsafe_fields". It accepts
boolean value and it is set to "true" by default.
When this option is "true", all header field names that contain characters
in valid range, but other than alphanumeric or "-" are skipped during parsing.
When the option is "false", these header fields aren't skipped.
Requests with non-valid characters in header field names according to
RFC 7230 are rejected regardless of "discard_unsafe_fields" setting.
This closes #422 issue on GitHub.
|
|
Now users can disable the default procfs mount point
in the rootfs.
{
"isolation": {
"automount": {
"procfs": false
}
}
}
|
|
Now users can disable the default tmpfs mount point
in the rootfs.
{
"isolation": {
"automount": {
"tmpfs": false
}
}
}
|
|
This closes #219 issue on GitHub.
|
|
The php_request_shutdown() function calls sapi_deactivate() that tries to read
request body into a dummy buffer. In our case it's just waste of CPU cycles.
This change is also required for the following implementation of the
fastcgi_finish_request() function, where the request context can be
cleared by the time of finalization.
|
|
Application shared queue only capable to pass one shared memory buffer.
The rest buffers in chain needs to be send directly to application in response
to REQ_HEADERS_AC message.
The issue can be reproduced for configurations where 'body_buffer_size' is
greater than memory segment size (10 Mb). Requests with body size greater
than 10 Mb are just `stuck` e.g. not passed to application awaiting for more
data from router.
The bug was introduced in 1d84b9e4b459 (v1.19.0).
|
|
Introducing manual protocol selection for 'universal' apps and frameworks.
|
|
The issue (deprecated API warning) introduced by ClassGraph upgrade
in ccd5c695b739 commit.
|
|
Application terminates in case of thread creation failure.
|
|
This closes #486 issue on GitHub.
|
|
This closes #482 issue on GitHub.
|
|
This shall save a couple of CPU cycles in request processing.
|
|
This closes #458 issue on GitHub.
|
|
|
|
This closes #459 issue on GitHub.
|
|
|
|
Compilers complained about unused variables after 37e2a3ea1bf1.
|
|
This closes #487 issue on GitHub.
|
|
The "iov" array was filled incorrectly when custom mounting options were set.
|
|
|
|
When mount points reside within other mount points, this
patch sorts them by path length and then unmounts then
in an order reverse to their mounting. This results in
independent paths being unmounted first.
This fixes an issue in buildbots where dependent paths failed
to unmount, leading to the build script removing system-wide
language libraries.
|
|
|
|
The socket is required for intercontextual communication in multithreaded apps.
|
|
|
|
The PORT_ACK message is the router's response to the application's NEW_PORT
message. After receiving PORT_ACK, the application is safe to process requests
using this port.
This message avoids a racing condition when the application starts processing a
request from the shared queue and sends REQ_HEADERS_ACK. The REQ_HEADERS_ACK
message contains the application port ID as reply_port, which the router uses
to send request data. When the application creates a new port, it
immediately sends it to the main router thread. Because the request is
processed outside the main thread, a racing condition can occur between the
receipt of the new port in the main thread and the receipt of REQ_HEADERS_ACK
in the worker router thread where the same port is specified as reply_port.
|
|
|
|
|
|
|
|
|
|
Every internal server error response should have a clear description in log.
|
|
This fixes the router's crash on buildbot; the reason was an unexpected 'last'
response from the application to the router arriving before the response
headers. The last buffer is not a memory buffer, so the result of accessing
memory fields is unpredictable.
The unexpected 'last' message was caused by an error in libunit; fixed in
fee8fd855a00.
|
|
Until the mmap is received by the router, only the creator thread may use this
mmap, so the "mmap not found" state in the router is avoided.
|
|
|
|
Previous value was too small, which reduced efficiency of the pool causing
a lot of additional allocations even for simple request and response.
|
|
Thanks to @geyslan.
This closes #455 issue on GitHub.
|
|
This closes #479 issue on GitHub.
|
|
|
|
|
|
|
|
PyUnicode_GET_SIZE() in deprecated since 3.3 and will be removed in 3.12.
In version 3.9 it was explicitly marked by deprecation warning causing
compilation error with Unit.
PyUnicode_GET_LENGTH() must be used instead.
|