Client: cpp
With a non-blocking dispatch, serve() rejects and closes a client right
after accepting it, while the test client may still be writing its
request. When the close got there first, the send failed, the test
discarded that client, and if that happened to every rejected client
the check found no drop. too_many_pending_tasks_does_not_end_the_server
failed that way in about a third of the Windows CI jobs.
A fired client whose send fails with a transport error other than a
timeout now counts as dropped, like one that reads end-of-stream or a
reset.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Client: cpp
TThreadedServer::onClientConnected() inserts the new client into its active-client
map and then starts a worker thread for it. When the thread cannot be started --
the process is out of threads, so std::thread's constructor throws -- two things
went wrong on the default (non-detached) configuration:
- Thread::start() had already run setState(starting) but left thread_ null, and
~Thread()/join() dereferenced thread_ unconditionally for a non-detached thread,
so destroying the failed worker crashed.
- The exception is not a TTransportException, so the accept loop's only catch did
not handle it; it unwound out of serve() and the server stopped accepting, with
the client left in the active-client map.
Null-guard ~Thread()/join() so a never-started thread can be destroyed safely, and
catch the failure in onClientConnected(), remove the client from the map, and keep
serving -- the way TThreadPoolServer drops one client on a rejected dispatch and
continues.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Client: cpp
A thread-pool dispatch that the ThreadManager rejected -- a full pending
queue, or a non-blocking add() that could not enqueue -- threw past serve()
and stopped the server. That one client is now closed and serving continues,
as the Java TThreadPoolServer does on a rejected execution.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* make use of C++11 override keyword
* added const specifier to TTransport::getOrigin()
* added more const correctness to the compiler
* make use of auto keyword
* replaced usage of NULL with nullptr
* make use of explicitly-defaulted function definition
* extended changelog
Client: Test (C++)
Patch: John Sirois
This was already the case for most of the suite, which, besides the one
fixed constructor, retrieved the port to dynamically already.
This closes#859