This pull request aims to fix the following issues in relation to closing gates/spaces or if one loses connection when using KEEP connections:
OLD BEHAVIOR: When SpaceRepository.shutdown() had been called, the SpaceRepository would in some cases still try to execute new tasks (listen for messages from a client or try to send a response) which throw RejectedExecutionException's.
NEW BEHAVIOR: Tasks are no longer enqueued after SpaceRepository.shutdown() has been called.
OLD BEHAVIOR: After a RemoteSpace was closed (or connection was lost in some way), all threads that earlier had called get, query, put, ect. on a RemoteSpace would become stuck (they could be interrupted), because they never got an answer (no InterruptedException would be triggered).
NEW BEHAVIOR: When a RemoteSpace is closed, all waiting threads are now interrupted - they throw an InterruptedException.
OLD BEHAVIOR: Calling get, query, put, ect. on a RemoteSpace AFTER it is closed would make the calling thread stuck (it could be interrupted).
NEW BEHAVIOR: An InterruptedException is thrown.
OLD BEHAVIOR: When RemoteSpace.close() was called, the calling thread would become stuck, unless the thread responsible for receiving messages (KeepClientGate.inboxHandlingMethod()) got a message. The reason is that BufferedReader.readLine() takes a lock that is also needed for BufferedReader.close().
NEW BEHAVIOR: The underlying socket is now closed first, which effectively also closes the BufferReader, so a RemoteSpace now can be closed without getting stuck.
OLD BEHAVIOR: If a RemoteSpace was connected to a SpaceRepository, then calling SpaceRepository.shutdown() would make the thread responsible for receiving messages (KeepClientGate.inboxHandlingMethod()) enter an infinite loop (due to the message was null) - effectively wasting one CPU core on nothing.
NEW BEHAVIOR: The thread now closes the gate automatically in this case, since a message being null means EOF (socket closed).
Very likely fixes issue #12.
I added a file TestCloseKeepConnection.java with six tests to test some of the things above. Each test runs one thread as server and one thread as client, concurrently (they both create even more threads). The tests work most of the time, but also fails too much to be called stable. One problem is that sometimes, some of the tests fail because there are more threads running after the test is finished than there where when it started. Another problem is that the tests sometimes get stuck (runs for ever), because the threads that are joined never terminate. I did not set a timeout, because that would not help making them stable. The second problem only seems to appear when running the tests via Maven in Eclipse, while the first problem is independent of how they are ran. Therefore, these tests are NOT ran when running all tests, because there might still be some concurrency issue.
Changes in:
SpaceRepository.java covers point 1.
KeepClientGate.java covers point 2, 3, 4 and 5.
Rendezvous.java covers point 2.
TestRemoteSpace.java one test was commented out (it never failed when I ran it).
This pull request aims to fix the following issues in relation to closing gates/spaces or if one loses connection when using
KEEPconnections:SpaceRepository.shutdown()had been called, theSpaceRepositorywould in some cases still try to execute new tasks (listen for messages from a client or try to send a response) which throwRejectedExecutionException's. NEW BEHAVIOR: Tasks are no longer enqueued afterSpaceRepository.shutdown()has been called.RemoteSpacewas closed (or connection was lost in some way), all threads that earlier had calledget,query,put, ect. on aRemoteSpacewould become stuck (they could be interrupted), because they never got an answer (noInterruptedExceptionwould be triggered). NEW BEHAVIOR: When aRemoteSpaceis closed, all waiting threads are now interrupted - they throw anInterruptedException.get,query,put, ect. on aRemoteSpaceAFTER it is closed would make the calling thread stuck (it could be interrupted). NEW BEHAVIOR: AnInterruptedExceptionis thrown.RemoteSpace.close()was called, the calling thread would become stuck, unless the thread responsible for receiving messages (KeepClientGate.inboxHandlingMethod()) got a message. The reason is thatBufferedReader.readLine()takes a lock that is also needed forBufferedReader.close(). NEW BEHAVIOR: The underlying socket is now closed first, which effectively also closes theBufferReader, so aRemoteSpacenow can be closed without getting stuck.RemoteSpacewas connected to aSpaceRepository, then callingSpaceRepository.shutdown()would make the thread responsible for receiving messages (KeepClientGate.inboxHandlingMethod()) enter an infinite loop (due to the message wasnull) - effectively wasting one CPU core on nothing. NEW BEHAVIOR: The thread now closes the gate automatically in this case, since a message beingnullmeansEOF(socket closed).Very likely fixes issue #12.
I added a file
TestCloseKeepConnection.javawith six tests to test some of the things above. Each test runs one thread as server and one thread as client, concurrently (they both create even more threads). The tests work most of the time, but also fails too much to be called stable. One problem is that sometimes, some of the tests fail because there are more threads running after the test is finished than there where when it started. Another problem is that the tests sometimes get stuck (runs for ever), because the threads that are joined never terminate. I did not set a timeout, because that would not help making them stable. The second problem only seems to appear when running the tests via Maven in Eclipse, while the first problem is independent of how they are ran. Therefore, these tests are NOT ran when running all tests, because there might still be some concurrency issue.Changes in:
SpaceRepository.javacovers point 1.KeepClientGate.javacovers point 2, 3, 4 and 5.Rendezvous.javacovers point 2.TestRemoteSpace.javaone test was commented out (it never failed when I ran it).TestjSonMessageSerialization.javaremoved debug print.TestCloseKeepConnection.javanew tests that are NOT included when running the tests, since they are unstable.