/brz/remove-bazaar : changes

» Changes from revision 6133.4.60

To get this branch, use:

bzr branch
http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

From Revision 6133.4.60 to 6133.4.41

expand all

Rev	Summary	Authors	Date
6133.4.60	serve_bzr wasn't properly cleaning up the new _on_sighup dic... serve_bzr wasn't properly cleaning up the new _on_sighup dict, etc. So add a bzrlib.smart.signals.restore_sighup_handler() and add it as a cleanup that needs to be run in BzrServerFactory.tear_down(). Change install_sighup_handler so that it still does something on Windows, since we can use it to test that BzrServerFactory interacts with it appropriately. Next we need to test that 'bzr serve --inet' will respond to SIGHUP correctly.	John Arbash Meinel	14 years ago
6133.4.59	No longer register stop_gracefully for each request, it is h... No longer register stop_gracefully for each request, it is handled by the service at the top level. However, we need to do something for the inet server, but we want tests for that.	John Arbash Meinel	14 years ago
6133.4.58	Fix the race condition. Fix the race condition. Create an actual request that is pending, that we don't consume until after we've asked to shutdown the server thread.	John Arbash Meinel	14 years ago
6133.4.57	If someone does manage to connect while we are shutting down... If someone does manage to connect while we are shutting down, close the connection. Also, check if the server already knows its stopped, rather than waiting on the connection. (It can take a second or so for the OS to say that it really cannot connect to a closed socket.) There is one more failure now. Specifically: test_graceful_shutdown_waits_for_clients_to_stop. Because server._stop_gracefully() now tells client handlers to _stop_gracefully, and we don't actually have an active rpc in progress, the client can stop before we test that the server is waiting for it to stop.	John Arbash Meinel	14 years ago
6133.4.56	Change the ordering a bit. Change the ordering a bit. Wait for a 3rd connection to respond, which means we know we've: a) created the connection, and polled for the old one being dead b) fully added the third connection. Another fix is to allow the shutdown code to handle when the server already noticed that it needs to shut down, without another connection attempt.	John Arbash Meinel	14 years ago
6133.4.55	Now we've implemented the basic structure. Now we've implemented the basic structure. I tested it manually, and it works as we wanted, the server waits for the current request to stop, but keeps running until it does so. Once the current request has finished, it closes the connection to the client. There are now a couple of race conditions in the test suite. I caught a couple of them, like the connection thread was being started before we added it to the list of active connections. The next race that I know of, is the test suite expects that a request&response finish is enough for us to have run _poll_active_connections. However, there is no actual interlocking there. So we actually need to do a new connection, which may give us 1-or-2 active connections, but then we can check if the old handler is still around.	John Arbash Meinel	14 years ago
6133.4.54	Teach the SmartTCPServer to wait gracefully for the client t... Teach the SmartTCPServer to wait gracefully for the client threads to exit.	John Arbash Meinel	14 years ago
6133.4.53	Refactor the code a bit. Now we can ensure that the active l... Refactor the code a bit. Now we can ensure that the active loop also reaps dead threads.	John Arbash Meinel	14 years ago
6133.4.52	Implement basic testing that the smart server tracks client ... Implement basic testing that the smart server tracks client connections, and cleans out the queue on shutdown. Now we need a test that it prunes out inactive connections at runtime, so that the list of active connections doesn't grow without bound. Then we need to figure out how graceful shutdown should work, specifically, how long do we wait for client threads to timeout. My initial thought is that if this is a graceful shutdown, we should probably wait forever, and people who want something faster can give a stronger signal than SIGHUP.	John Arbash Meinel	14 years ago
6133.4.51	Merge _close => _disconnect_client. Merge _close => _disconnect_client.	John Arbash Meinel	14 years ago
6133.4.50	Track the active connections, add a polling function to noti... Track the active connections, add a polling function to notice when they are stopped.	John Arbash Meinel	14 years ago
6133.4.49	merge-up drop-idle merge-up drop-idle	John Arbash Meinel	14 years ago
6133.4.48	Some win32 specific tweaks. Some win32 specific tweaks. Namely, don't use signal.signal(SIGHUP) when it isn't available. Most of the tests run just fine on Windows, except the one test that actually interacts with signal(). Test suite passes on Windows now.	John Arbash Meinel	14 years ago
6133.4.47	Testing that 'bzr serve' actually installs SIGHUP and respon... Testing that 'bzr serve' actually installs SIGHUP and responds to it showed some problems. Namely, using 'register(id(self), self.func', doesn't work correctly. Because 'self.func' creates a temporary object BoundMethod, which ends up only referenced by the WeakValueDictionary. Instead, we have to assign the attribute to a local variable, and then register that variable. We still haven't solved the 'wait for clients' issue yet.	John Arbash Meinel	14 years ago
6133.4.46	Test that signals.install_sighup_handler does what we want. Test that signals.install_sighup_handler does what we want.	John Arbash Meinel	14 years ago
6133.4.45	Change the code a bit. Change the code a bit. Now, by default, there is no global state. It is created as part of bzrlib.smart.signals.install_sighup_handler(). That way, 99% of bzr commands won't care, only 'bzr serve' is affected. Further, the test suite won't have a by-product of tons of register/unregister calls that temporarily cache dicts and create garbage at runtime.	John Arbash Meinel	14 years ago
6133.4.44	Move the code into bzrlib.smart.signals. Move the code into bzrlib.smart.signals. Start doing some isolated testing of how it works. Seems pretty good, so far.	John Arbash Meinel	14 years ago
6133.4.43	Initial implementation of SIGHUP for bzr serve. bug #795025. Initial implementation of SIGHUP for bzr serve. bug #795025. Some bits are a bit rough (the signal handle installer, etc.) But it works. Sending SIGHUP will cause the running server to stop as soon as it finishes the current request.	John Arbash Meinel	14 years ago
6133.4.42	Change the code to just raise ConnectionTimeout. Change the code to just raise ConnectionTimeout. It isn't a big deal one way or another, but in the end, we want a timeout. I think originally I was hoping we would have more context that we could log/etc, but we don't seem to have it.	John Arbash Meinel	14 years ago
6133.4.41	Re-order the loop a bit. Move the exception handling into th... Re-order the loop a bit. Move the exception handling into the loop, so that we can handle EINTR. Break out of the loop on 'xs'. Clean up the code a bit, remove comments in favor of doc strings, and hopefully reasonably easy-to-understand structure.	John Arbash Meinel	14 years ago

Older »