Sharing objects between application instances using WCF

[Eri523]

Almost one week later and no objections? Looks like my code isn't too bad... At any rate, here's another version to which I added extensive logging. I initially did that to be myself able to inspect what the code does closer to realtime, but I decided to also post it here for test and discussion.

Actually, there's only one change to the Server class that's not related to logging: Two new lines in the d'tor that stop the heartbeat timer and detatch the object's handler from the timer's Elapsed event. Obviously, not having them in the original code was a mistake which was unveiled during early tests with the logging version of the code: One time the heartbeat tick handler got called 170 ms after Server::Shutdown() returned, i.e. at a point in time when the server object already has been long time destroyed. And perhaps that would've even got through unrecognized if it hadn't given rise to an assertion failure in the logger module, thereby, as a side effect, reveiling a bug in there as well...

To be able to get timestamps that are half-way consistent between the distinct processes involved, the logger has a feature I called "hi-res synchronization" that gets set up in the TimestampSource c'tor, is activated by explicitly passing a set LogFlags::HiResSync to the logger instance getter when calling it for the first time, and IMO is somewhat hackish...

The log entries aren't written to the log file in a proper chronological sequence by the logger module. Properly sorting the log by timestamp, which of course is important in the scenario here, is done by the external tool logsortts that I have attached as well. It's a simple cosole tool and the respective ZIP only contains the single .cpp file.

The third attached file, SampleLog.zip, contains two logs taken from client/server sessions. Both sessions were quite similar to what the screen shot in the last post was taken from and lasted less than one minute. Yet they both contain 1k+ lines of log, from which clearly can be concluded that the log currently generated by the test scenario can pretty quickly mount up to some 100 kB. I'll certainly have much less logging later in the real-life app, and probably will reduce the amount of logging done in the test setup as well at some point.

While the log in the sample WcfShareTest.log was generated by manually starting the server and then two clients, SimulStart.log was created by quasi-simultaneously starting two client instances from a trivial batch file, without the server already running at that time. This was intended to stress-test the server start-up scenario. The test exposed exactly the desired behaviour: Eventually there was one server instance running with two clients attached. What pretty much puzzles me, though, is how that happened. According to the log both clients enter the "Starting server app..." part of the code within a time span of 17 ms from each other, start to wait for server start-up with a distance of 15 ms and eventually report a successful server start within 4 ms. Yet there's just one server instance running. I don't think there was a second server instance for a short time that then died silently. Not only that the log doesn't report anything like that, the server also has intentionally been written to produce noticable noise when there already is an instance of it running. This is a sub-scenario I was much concerned about and I'm glad it works, but I would also love to know why and how it works...

Note that the enclosed MiniLog module actually is a "light version" of a bigger logger module (about twice as much code lines) I commonly use in my apps. The test scenario code is prepared to optionally use the full-fledged logger module, but that's not included. Also, the two sample logs actually have been created by the big logger and I just removed some info I didn't intend to post publicly, but those produced by MiniLog are practically identical in layout.