Question

Right now I have:

• a multithreaded windows service written in C++ which use common static libraries as well as dynamic DLLs;
• each thread performs different tasks and produces different errors (DB errors, function invocation errors, etc.). Each thread further will act as a logger client (and will send all messages to a logger server);
• a separate thread which has no body yet, but which will act as a logger server for handling all log messages from the logger clients.

I need a good advise of how I should implement following idea into a working solution. The idea is to add a server-client logging architecture to my multithreaded server with following requirements (though some parts I need to implement by myself, please consider just the basic idea of logger client and logger server):

1. there should be a lot of log clients (as I already mentioned, the log client is just an existed working thread), each should register an entity with a unique name or/and ID and following behavior:

   • if the logger server is up and is working now, this log client starts to send log messages,

   • otherwise (the logger server is down), the log client endlessly tries to register itself with the log server using a small timeout.

2. there should be a logger server, with following behavior:

   • log server registers all log clients with their unique name or/an ID and endlessly checks if there appears a new log client to be registered

   • log server handles all messages from different log clients and writes to DB, file, etc.

   • there should be an opportunity to establish connection to the log server from an external application (for example, MySuperThreadViewerProgram to monitor all thread activity/errors/etc). At the connection, the log server should consider an external application as a one more log client. It’s the most important requirement.

Summing up, there are three architecture parts to be implemented:

1. Server-client logger architecture;
2. Message queue facility between log clients and log server. And log server periodically checks if there any available log clients to be registered;
3. Inter-process communication between log server and external application, where the latter acts as a new log client.

Please, note, I consider a logger server as a kind of log message router.

So, the main question is:

Is there any solution (software framework) which has all described above features (which is much preferably) or I should use different libraries for different parts?

If the answer is: “there is no such solution”, can you review the choice I made:

• For #1: using Pantheios logger framework;
• For #2: using any kind of register-subscribe library with server-client architecture and message-queue support (update: ipc library) ;
• For #3: using Boost.Interprocess – using SharedMemory.

---

UPDATE:

The good example of #2 is this ipc library. And may be I was a bit incorrect describing logger client - logger server relations, but what I really mean is similar to approach, fully described and implemented in ipc library: when one entity (thread) subscribes to another to receive its messages (or “publish-subscribe” model).
And I want to use a kind of this technique to implement my logging architecture. But in what way?

---

UPDATE2:

OS is Windows. Yeah, I know, under Linux there is a bunch of useful tools and frameworks (D-Bus, Syslog). May be some of you could provide a helpful link to cross-platform library, which can be useful? Maybe there is a logger framework over D-Bus under Windows?

---

Any comments are highly appreciated.

Thanks a lot!

Answer 1

ØMQ (ZeroMQ) might be a viable alternative to the ipc library you mentioned, as it has a lot of features along the lines of your requirements.

It fully supports the PUB/SUB model, allows you to work between threads, bteween processes and even between machines. It is a client-server architecture, a message queue and works as IPC, too.

Of course, you need a specific way of coding and decoding messages, the protocol buffers are indeed a great idea.