user2137989
user2137989

Reputation: 1

POCO C++: Can you have multiple logging hierarchies?

I am looking for a unique logging solution using the POCO C++ library.

I will try to explain our design and the issue we are facing.

We have a TCPServerConnectionFactory that spawns a new environment (new set of objects) with each new connection. The spawned environment gets a new socket and has a listening thread. If a message comes in to an established connection a pthread will handle the message. Each useful message that comes in will contain an identifier that will identify all actions that happen until this process is completed by closing the connection and destructing the set of objects that were created for this connection.

Many connections may happen simultaneously. Before moving to a pthreaded environment we were able to use Thread::setName along with the %T identifier to clearly see which log messages were coming from which connection. Now that we are multi-threaded we need a new solution.

I have been unable to find a clean way to make each object that gets spawned through the life of a connection aware of our unique identifier. A global would get overwritten by a new transaction. Passing the ID to each new object would be messy.

My next attempt was to use the POCO Logger channel framework to save each connection's logs to a new file named by the unique identifier we would receive in a message. The issue here is that if a new connection comes in during the life of another, it will overwrite the channel properties and start pointing logs to a different file.

Using the Logger framework, is there a way for me to have a new Logger hierarchy per connection? Basically, we need the set of objects spawned by the new connection to all use the same logging properties, and to not affect any other set of objects logging properties.

Any insight as to a proper way to share the identifier among all objects created during the life of a connection would be useful as well.

Thanks!

Upvotes: 0

Views: 868

Answers (1)

gifnoc-gkp
gifnoc-gkp

Reputation: 1516

If you want to store tiny amounts of information then use a singleton instance of your logger along with a mutex and a semaphore to avoid deadlock / livelock issues.
But if you're expecting lots of connections, blocking on the mutex would slow things down therefore you should consider using 1 logger instance per connection.

In case you're going singleton consider using std::mutex since it has built-in deadlock protection.

Upvotes: 0

Related Questions