Hi, i am using hot restarting without process termination. Is there any way to remove handlers for listenTCP, listenHTTP?
PS. The listenHTTP doesn't rewrite previous call and vibe still uses old delegate/function.
Hi, i am using hot restarting without process termination. Is there any way to remove handlers for listenTCP, listenHTTP?
PS. The listenHTTP doesn't rewrite previous call and vibe still uses old delegate/function.
On Wed, 19 Mar 2014 10:43:05 GMT, Anton Gushcha wrote:
Hi, i am using hot restarting without process termination. Is there any way to remove handlers for
listenTCP,listenHTTP?PS. The
listenHTTPdoesn't rewrite previous call and vibe still uses old delegate/function.
For listenTCP, there is TCPListener.stopListening, but for listenHTTP, nothing exists right now. I'll create a ticket to add an equivalent HTTPListener.
Calls to listenHTTP are meant to be additive to support multiple virtual hosts on the same interface, which is why it currently doesn't complain when it's repeatedly called - but there should probably be a check to disallow multiple calls with the same host name once the HTTPListener is implemented.
On Wed, 19 Mar 2014 10:58:04 GMT, Sönke Ludwig wrote:
I am going to start work on pull request for this issue. As i see the main pitfall is requirement to track for virtual hosts, that uses the same interface. Should HTTPListener.stopListening throw an exception at that case of just do nothing?
On Wed, 19 Mar 2014 11:06:37 GMT, Anton Gushcha wrote:
On Wed, 19 Mar 2014 10:58:04 GMT, Sönke Ludwig wrote:
I am going to start work on pull request for this issue. As i see the main pitfall is requirement to track for virtual hosts, that uses the same interface. Should
HTTPListener.stopListeningthrow an exception at that case of just do nothing?
I'd say that for simplicity HTTPListener should contain the settings object and the request_delegate. It would then remove all HTTPServerContexts with those values and then clean up any HTTPServerListeners that don't have any associated contexts anymore.
To keep this unambiguous, listenHTTPPlain would throw an exception if someone tries to use the same settings/request_handler combination to listen twice.
On Wed, 19 Mar 2014 11:13:05 GMT, Sönke Ludwig wrote:
On Wed, 19 Mar 2014 11:06:37 GMT, Anton Gushcha wrote:
On Wed, 19 Mar 2014 10:58:04 GMT, Sönke Ludwig wrote:
I am going to start work on pull request for this issue. As i see the main pitfall is requirement to track for virtual hosts, that uses the same interface. Should
HTTPListener.stopListeningthrow an exception at that case of just do nothing?I'd say that for simplicity
HTTPListenershould contain thesettingsobject and therequest_delegate. It would then remove allHTTPServerContexts with those values and then clean up anyHTTPServerListeners that don't have any associated contexts anymore.To keep this unambiguous,
listenHTTPPlainwould throw an exception if someone tries to use the samesettings/request_handlercombination to listen twice.
Ok, it is clear for me (excepting "that don't have any associated contexts anymore", but i still need to read all corresponding code attentively). By the way, listenHTTPPlain is private in ~master branch, but docs is still refers to as valid user API.
By the way,
listenHTTPPlainis private in~masterbranch, but docs is still refers to as valid user API.
Looks like only one of the overloads was marked private back then. I've made them all private now (docs will be updated with the 0.7.19 release).