I've been thinking about your comments. and I think I have something that is
better, but different.
While existing maintenance is probably done best as you described, I'm still
looking for an easier way to iteratively develop "pages" (for lack of a better
term). My idea is currently that upon saving a C/Cpp file, the binary should
rebuild the object file and unload/insert itself into the server. I don't know
if it is possible to have each object file do that automatically. But with a
fast enough system I should be able to hit "save" and by the time I hit reload
in the browser the new code (object or whole new binary) should be up and
running. However, in my tests with my core i5, when also debugging I sometimes
beat it.
So I think that would be cool. Integrate a file system watcher with make.
________________________________
From: Wim Dumon <w...@emweb.be>
To: witty-interest@lists.sourceforge.net
Sent: Thursday, March 27, 2014 10:28 AM
Subject: Re: [Wt-interest] witty application upgrade?
In fact, this can theoretically be done with a reverse proxy, and
using Wt's session prefix feature. Use a different prefix for old and
new sessions, and forward requests accordingly. I've never done this.
BR,
Wim.
2014-03-27 10:41 GMT+01:00 Koen Deforche <k...@emweb.be>:
> Hey Jason,
>
> 2014-03-26 21:57 GMT+01:00 Jason H <scorp...@yahoo.com>:
>>
>> How would someone do an upgrade? It seems that we have to stop everything
>> and start everything for a witty application?
>> Or, could witty somehow maintain more than one application at a time, and
>> when a newer one comes along, be messaged to use the new one for new
>> connections? And as sessions are [re]started, move to the new while current
>> sessions remain on the old implementation or are signaled to gracefully
>> restart the session. Also how is session data handed off between upgrades?
>
>
> Currently people are shutting down while upgrading; with a static page to
> announce the upgrade (as Norbert suggests).
>
> The above functionality has been an idea we have had since long as something
> that would be very nice to have, but it turns out that in practice everyone
> seems happy without it. To implement the above we would need a reverse proxy
> server that knows enough of Wt's session management to direct new sessions
> to an upgraded server while old server instances continue to run the old
> code until all of their sessions are done. A http reverse proxy is however
> not a trivial implementation.
>
> Moreover, if you really want, you can get the above behaviour using Wt's
> FastCGI dedicated process deployment as then for each new session a new
> process is spawned.
>
> Regards,
> koen
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
------------------------------------------------------------------------------
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
