This commit adds a timeout for both establishing new outgoing and incoming
connections. This timeout applies to everything until the connection is in a
state where either JsonRpcConnection or HttpServerConnection takes over.
With dc3062a9b06fed69cdbb1508ace6eb2f77f87553, exceptions in this code
path were no longer caught properly. This commit restores exception
handling for this function.
until now, if the timeout is exceeded, the connection is immediately terminated.
But since we do not want to disconnect even if the timeout is exceeded, it is
better to send the messages without timeout and have deleted everything that
related to the heartbeat timeout. We also have another mechanism in
JRPC::CheckLiveness that does the disconnect.
Otherwise old configuration received from a secondary master/satellite
could always trigger a config change & reload.
(cherry picked from commit cb20b4829ac10694920db0d9f52ccc39a1ca1ae1)
This is required to
- catch all exceptions and wrap them into Boost exceptions. They
are the only ones allowed with Boost.Coroutine.
- set a dedicated coroutine stack size for Windows.
refs #7431
Throwing local exceptions unnecessarily pollutes the exception
stack with immediate unwinding. Avoid this pattern at all cost within
Boost.Coroutines. MSVC may handle exceptions differently and cause
problems with stack unwinding.
refs #7431
refs #7351
Exceptions in Disconnect() might be thrown (this has been reworked
into error_code locally) which are swallowed inside the Destructor
for being dangerous. On the other hand, swallowing them may
corrupt the stack unwinding operation from the coroutine layer.
The best is to avoid Defer inside lib/remote and call Disconnect()
directly after breaking from other operations.
refs #7351
refs #7431
When run within a coroutine, exceptions on Windows may influence
bad behaviour here. Instead, we'll check for the error code
and extract the message from memory. In contrast to exceptions
which are stored on the stack frame and then return, this costs
a little more memory but simplifies the logic.
This doesn't fix the linked issue, but is related to the analysis.
refs #7431
config::UpdateObject would create a new object, but this may
have been silently ignored with 'ignore_on_error' - downtimes, etc.
Since we cannot simply fetch the error from inside the config compiler,
we'd just check whether there's a config object created at this stage.
This happens synchronously, and once there is, log something.
The previous code always logged the creation, even if the downtime
was ignored, e.g. when the first master sent one for local host objects.
This commit also adds more details: identity, endpoint, zone to extract
the MessageOrigin details into log messages for better troubleshooting
and debugging.
refs #7198
