New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shutting down after listenHTTP #1074

Closed
rikkimax opened this Issue Apr 19, 2015 · 8 comments

Comments

Projects
None yet
2 participants
@rikkimax

rikkimax commented Apr 19, 2015

listenTCP and listenUDP allow for e.g. shutting down once started.
However listenHTTP does not return these connections, instead it just discards them.

Use case:
Linux daemon + reloading of config. To allow for changing of ports/ip's.

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Apr 19, 2015

Contributor

Yes, in the HTTP server the contexts are stored in g_contexts and have nothing to allow removing one.

The listenTCP return type TCPListener has a stop method but it's unused so far. I think we would need an HTTPContexts object to manage the listeners but I can't think of any use cases for changing the ip/port during runtime.

Contributor

etcimon commented Apr 19, 2015

Yes, in the HTTP server the contexts are stored in g_contexts and have nothing to allow removing one.

The listenTCP return type TCPListener has a stop method but it's unused so far. I think we would need an HTTPContexts object to manage the listeners but I can't think of any use cases for changing the ip/port during runtime.

@rikkimax

This comment has been minimized.

Show comment
Hide comment
@rikkimax

rikkimax Apr 19, 2015

I wasn't meaning changing the ip/port on an already listening interface.
I was meaning the use case of e.g. a web server like Apache httpd.

So stop them all and create new based upon config.

rikkimax commented Apr 19, 2015

I wasn't meaning changing the ip/port on an already listening interface.
I was meaning the use case of e.g. a web server like Apache httpd.

So stop them all and create new based upon config.

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Apr 19, 2015

Contributor

I wasn't meaning changing the ip/port on an already listening interface.
I was meaning the use case of e.g. a web server like Apache httpd.

So stop them all and create new based upon config.

Yes I've wanted to have that for a while now, I know what you mean. The only issue I see is the necessity to have r/w locks or maybe an atomic fence on every request because g_contexts now became a mutable shared array that can change at any time.

Contributor

etcimon commented Apr 19, 2015

I wasn't meaning changing the ip/port on an already listening interface.
I was meaning the use case of e.g. a web server like Apache httpd.

So stop them all and create new based upon config.

Yes I've wanted to have that for a while now, I know what you mean. The only issue I see is the necessity to have r/w locks or maybe an atomic fence on every request because g_contexts now became a mutable shared array that can change at any time.

@rikkimax

This comment has been minimized.

Show comment
Hide comment
@rikkimax

rikkimax Apr 19, 2015

Would it be possible to refactor the API out, so that the control of the connection is by the end user?
e.g. they create the connection, on receive of data forward it to vibe.http.server function (possibly with some context involved) and with a hook get called with the request?

rikkimax commented Apr 19, 2015

Would it be possible to refactor the API out, so that the control of the connection is by the end user?
e.g. they create the connection, on receive of data forward it to vibe.http.server function (possibly with some context involved) and with a hook get called with the request?

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Apr 19, 2015

Contributor

Would it be possible to refactor the API out, so that the control of the connection is by the end user?
e.g. they create the connection, on receive of data forward it to vibe.http.server function (possibly with some context involved) and with a hook get called with the request?

Yes I've also imagined something like that. It would only require to pass the connectTCP and listenTCP as delegates to requestHTTP and listenHTTP respectively. This way the HTTP listener actually sends its void delegate(TCPConnection) handler over so that it can be used internally with your own streams.

I think the HTTPServerSettings would be a nice place to have this delegate, I was motivated mostly by a unit testing interface but your use case seems genuine too, not sure what Sönke would say about it

Contributor

etcimon commented Apr 19, 2015

Would it be possible to refactor the API out, so that the control of the connection is by the end user?
e.g. they create the connection, on receive of data forward it to vibe.http.server function (possibly with some context involved) and with a hook get called with the request?

Yes I've also imagined something like that. It would only require to pass the connectTCP and listenTCP as delegates to requestHTTP and listenHTTP respectively. This way the HTTP listener actually sends its void delegate(TCPConnection) handler over so that it can be used internally with your own streams.

I think the HTTPServerSettings would be a nice place to have this delegate, I was motivated mostly by a unit testing interface but your use case seems genuine too, not sure what Sönke would say about it

@rikkimax

This comment has been minimized.

Show comment
Hide comment
@rikkimax

rikkimax Apr 19, 2015

Yeah, that works. All I need is some way to stop them. It's a blocker for daemon support.
There is no way I could release the web server, even if I get e.g. PHP support if the damn demonisation doesn't work.
Something that should be so simple... Yeah, wouldn't look good.

rikkimax commented Apr 19, 2015

Yeah, that works. All I need is some way to stop them. It's a blocker for daemon support.
There is no way I could release the web server, even if I get e.g. PHP support if the damn demonisation doesn't work.
Something that should be so simple... Yeah, wouldn't look good.

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Apr 19, 2015

Contributor

Yeah, that works. All I need is some way to stop them. It's a blocker for daemon support.

If you handle the listenTCP through a delegate you acquire the means to stop the listeners. The declaration is:

TCPListener listenTCP(ushort port, void delegate(TCPConnection conn) conn_callback, string address, TCPListenOptions options);

The TCPListener is defined as follows:

interface TCPListener {
    /// Stops listening and closes the socket.
    void stopListening();
} 

So this should allow some more control over the TCP layer I guess

Contributor

etcimon commented Apr 19, 2015

Yeah, that works. All I need is some way to stop them. It's a blocker for daemon support.

If you handle the listenTCP through a delegate you acquire the means to stop the listeners. The declaration is:

TCPListener listenTCP(ushort port, void delegate(TCPConnection conn) conn_callback, string address, TCPListenOptions options);

The TCPListener is defined as follows:

interface TCPListener {
    /// Stops listening and closes the socket.
    void stopListening();
} 

So this should allow some more control over the TCP layer I guess

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon May 3, 2015

Contributor

Thanks, I was thinking about quick workarounds to allow me to change the port/restart the server at runtime, before this feature came up =)

Contributor

etcimon commented May 3, 2015

Thanks, I was thinking about quick workarounds to allow me to change the port/restart the server at runtime, before this feature came up =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment