In my case (Ubuntu Server 14.04), when launching a second server instance
(from terminal of course) it throws me an error:
[2016-Oct-31 14:31:17.746221] 8337 - [info] "WServer/wthttp:
initializing built-in wthttpd"
[2016-Oct-31 14:31:17.747020] 8337 - [error] "wthttp: Error occurred
when binding to ::1:11000
bind: Address already in use"
Error (asio): bind: Address already in use
So, I conclude that it's the boost::asio library who throws an exception
with that message. `Wt` just displays it and the server launching is
stopped.
If your server runs and waits the port is free, or it's able to bind more
than one process to a same port, but in any case it's not halted, it must
be an OS-specific behaviour (otherwise, `boost::asio` should throw an
exception).
On 31 October 2016 at 14:23, K. Frank <kfrank2...@gmail.com> wrote:
> Hello List!
>
> I have two questions about WServer error handling:
>
> (This is wt-3.3.3 compiled with mingw-w64 on windows 7.)
>
> First, I see no errors when trying to start a wthttpd server on an
> already bound port. What behavior should I expect?
>
> Details: I've built a "minimal" wthttpd server -- it just servers
> html files, so no WApplication. I run two copies of it at the
> same time, both launched with "--http-port=80". The first
> copy works, services http connections, and serves the html
> pages. The second copy reports no errors, and doesn't receive
> any http requests -- presumably because all of the port-80 traffic
> goes to the first copy.
>
> My understanding is that the first copy binds to port 80, and
> everything works. I would expect that the second copy fails
> to bind to port 80, which would seem to be to be an error
> condition. But the second copy reports no errors.
>
> Here is the relevant code:
>
> int main (int argc, char *argv[]) {
> try {
> WServer server;
> server.setServerConfiguration (argc, argv);
> if (server.start()) WServer::waitForShutdown();
> else cout << "error on server.start()" << endl;
> }
> catch (const WException& e) {
> cout << "WException caught, e.whatA() = " << e.what() << endl;
> }
> return 0;
> }
>
> Here's how I launch both copies:
>
> minimal_wt3 --http-address=0.0.0.0 --http-port=80
> --deploy-path=/dummy --docroot=.
>
> A little more detail: If I kill the first copy of the wthttpd server (and
> just leave the second running, without restarting it or anything), the
> second copy now responds to incoming connections, serves the
> html pages, etc. Is this expected?
>
> Here;s the output from the second copy:
>
> Option no-compression is implied because wthttp was built without
> zlib support.
> [2016-Oct-31 08:21:09.352845] 4236 - [info] "config: reading Wt
> config file: c:/witty/wt_config.xml (location = '')"
> Option no-compression is implied because wthttp was built without
> zlib support.
> [2016-Oct-31 08:21:09.372845] 4236 - [info] "WServer/wthttp:
> initializing built-in wthttpd"
> [2016-Oct-31 08:21:09.372845] 4236 - [info] "wthttp: started
> server: http://0.0.0.0:80";
> 127.0.0.1 - - [2016-Oct-31 08:22:34.961484] "GET /nonexistant.html
> HTTP/1.1" 404 85
>
> Note, between the last two lines -- that is, before the line:
>
> 127.0.0.1 - - [2016-Oct-31 08:22:34.961484] "GET /nonexistant.html
> HTTP/1.1" 404 85
>
> I killed the first server. I then browsed to the "nonexistant.html" url,
> and the second server correctly responds with a 404 (because that
> html page doesn't exist).
>
>
> My second questions is about the WServer documentation and
> error handling.
>
> The documentation for WServer::start():
>
> WTCONNECTOR_API bool Wt::WServer::start()
>
> Starts the server in the background.
>
> Returns whether the server could be successfully started.
>
> Exceptions
> Exception: indicates a problem starting the server.
>
> This seems to be saying that when WServer::start() encounters
> an error (regardless of whether my above example counts as
> an error), the error condition is reported by returning false and
> by throwing an exception. Of course, you can't actually do
> both.
>
> Are there two different classes of WServer::start() errors (maybe
> for historical reasons), some of which are reported with a false
> return value, and others that are reported with a thrown exception?
>
> Anyway, what are the recommended best practices for handling
> WServer::start() error conditions?
>
>
> Thanks.
>
>
> K. Frank
>
> ------------------------------------------------------------
> ------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
