dpathakj / junixsocket

Automatically exported from code.google.com/p/junixsocket
0 stars 0 forks source link

Request: option to not unlink the socket on close #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I have a use-case where the automatic unlink of the socket on close is 
undesirable.  I would request a flag or mode that disables the unlinking.

My use case is atomically taking over from an existing server by binding a new 
socket, then renaming that socket to the existing socket.  This is very useful 
for server restarts without dropping any connections.  But it is defeated if 
junixsocket tries to unlink its socket, because it in fact unlinks the new 
socket!

Original issue reported on code.google.com by tol...@gmail.com on 5 Oct 2010 at 12:06

GoogleCodeExporter commented 9 years ago
Could you please try whether removing the following lines in 
AFUNIXServerSocket#close() would do what you want?

if (boundEndpoint != null) {
            NativeUnixSocket.unlink(boundEndpoint.getSocketFile());
}

Cheers,
Christian

Original comment by ckkohl79 on 5 Oct 2010 at 6:22

GoogleCodeExporter commented 9 years ago
I'm sure this would work.  However, I realized I don't need it.  I can just 
always open the socket under a temporary name (whether there is already a 
running instance or not) and rename it.  junixsocket will try to delete the 
temporary name and fail.  So you can forget this weird request.

This approach also solves the other issue (6) I commented on.  When I want to 
gracefully shut down, I rename the socket to a new name, so it can no longer 
receive "real" connections.  (Or in the case of take-over, I link the socket to 
a new name, then rename a new socket over it.)  Then I connect to it (under the 
new name) and send a shutdown message in my application protocol.  Assuming the 
OS doesn't reorder connections, I can be sure that by the time I accepted this 
message, all real connections had already been accepted.

In other words, by using filesystem operations, I can achieve the "stop 
listening, but continue to accept backlogged connections" semantic I was 
looking for.  Cool.

Original comment by tol...@gmail.com on 6 Oct 2010 at 7:54

GoogleCodeExporter commented 9 years ago
Agreed to solve this outside of junixsocket.
Closing.

Original comment by ckkohl79 on 20 Feb 2013 at 12:01