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
listenHTTP
doesn'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.stopListening
throw 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 HTTPServerContext
s with those values and then clean up any HTTPServerListener
s 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.stopListening
throw an exception at that case of just do nothing?I'd say that for simplicity
HTTPListener
should contain thesettings
object and therequest_delegate
. It would then remove allHTTPServerContext
s with those values and then clean up anyHTTPServerListener
s that don't have any associated contexts anymore.To keep this unambiguous,
listenHTTPPlain
would throw an exception if someone tries to use the samesettings
/request_handler
combination 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,
listenHTTPPlain
is private in~master
branch, 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).