I am looking for a logging facility for a multiprocess application which also contains multiple threads with in each process.
My current application is only multi-threaded and uses ACE_Message_Queue for sending logging events to the logger thread (The actual Log message is shared between application threads and the logger thread through a global array).
My new application contains multiple processes with multiple threads with in each process. How can I achieve a decent logging functionality in this scenario? Also looking to get rid of ACE in favor of Boost. My new application is supposed to run on Linux,Mac and Windows.
Thank you in advance.
Boost.Log (v2) is very easy to set-up and pretty comprehensive. It is not in the boost library yet but it will be soon. You can use it as a simple logger, or write filters and customize the logging process and output. I am using it for a project and very very happy with it. See this question.
Try to use log4cplus. It is an up-to date logging library allows using from multiple processes.
I'v a blog to show my logging practice about this question: http://peihanw.blogspot.com/2012/08/my-answer-to-stackoverflows-question.html
Related
Looking to implement an an event based system for a project across multiple linux processes. Essentially, I want to be able to log an event and then notify multiple processes about the event (and also log via rsyslog). I have done this in the past with domain sockets and some custom code, but does anyone know of a better way utilizing Boost or a similar library?
Even better would be a subscription based model where only certain processes would receive certain events.
You have lots of options:
ZeroMQ.
It is high-speed, asynchronous library and contains lots of messaging patterns you can use, e.g. PUB-SUB
C++ Actor Framework -- C++11 actor model implementation
Dataflow.Signals and Boost.Asio -- in case you want to stick to BOOST-based solution. An example can be found here
We're developing both std and realtime applications that run on a RT-Linux.
question is, what would be an efficient way of logging application traces from both realtime and non-realtime processes?
By effecient, I mean that the process of logging application traces shouldn't cause RT-perf hit by increasing latency, etc.
Traces should ideally be stored into a single file with timestamp, to make it easier to track interaction between processes.
For real time Logging I'll advise use different aproaches than bare logging to files. Writing to files a lot of information will hurt your performance.
I can advice other more lighter mechanismS:
Use statistics/counters to get filling what your application is doing
Write/encode logs in some binary format to be processed offline. This binary format may be more compact and thus lighter.
Since you are on linux, you can use syslog() :
openlog() opens a connection to the system logger for a program.
this means your program forwards messages to another program, which can be of low priority.
If you want something more fancy, then boost logging.
I am penning down the features that a remote logging
library might need when built from scratch.
I looked up this: http://www.aggsoft.com/serial-data-logger.htm
I wish to know that what differences can be between a
remote logging library and a remote logger software.
Few things that I thought of:
1. The library can be used in C++ programs to log error messages on the fly.
2. The library will require programming knowledge on the end user's part.
3. The software cannot be used "inside" a C++ program, so we won't be able to log the error messages on the fly? Not sure about this one.
I would like to know that besides logging error messages, what are the things for which it makes sense to use the remote logging library? Sharing big files? Anything else than these two things?
Secondly which is better in what way out of a library and a software - in the current case?
As I mentioned in the my comments to your question, I would think that a logging library would provide some sort of an API/SDK, whereas remote software would not. The same would hold true if its sending messages via TCP/UDP or a serial port. The difference between the 2 options would be how much coding you would have to do. That is, how much would you have to reinvent the wheel?
IMHO, nearly all debug environment/tools support redirect the console output the serial port (using print, or other API). It usually not a a task of Application programmer.
There are other methods for "remote logging":
1) syslog, syslog-ng 's remote service
2) save log local, fetch using ftp
What logging facilities do you use whit Qt ?
Do you choose qDebug(), qWarning(), qCritical(), qFatal() methods, or maybe something like Log4cpp (Log4cplus etc.), or maybe some custom-maked code ?
If you are just working in a single thread, qDebug and such work pretty well, or you can modify them somewhat by installing your own handler with qInstallMessageHandler in QT 5.0+, or qInstallMsgHandler in old versions.
Note: Older versions of qDebug() etc., where you used qInstallMsgHandler (now deprecated, e.g. http://doc.qt.io/archives/4.6/qtglobal.html#qDebug) were not thread-safe. If you use threads, they would crash/break badly. Internally it was using QTextStream, which was reentrant, but not thread-safe.
Since Qt 5.2 supports categorized logging: http://qt-project.org/doc/qt-5/qloggingcategory.html . This allows you to split up your logging messages into a (hierarchy of) categories, and fine tune which is logged, and what not.
Existing C++ logging libraries are too heavy for my tastes, so I have created a custom front-end based on ideas from Logging in C++ for the Qt qInstallMsgHandlerq back-end. It's cross-platform and thread-safe. Someday I'll clean up the code and release it to the world :)
An interesting alternative for Qt is QxtLogger.
Log4Qt is a port of famous log4j to the Qt world.
QDebug is the best way to go, as it presents out-of-the-box integration with the rest of the framework, doesn't make you dependent on 3rd party code and covers pretty all of the logging needs.
I'm not using Qt, but for logging I'm using a modified version of Dr'Dobb's Logging in C++. The original code can be found here.
My modifications are specific to the Microsoft Windows platform (fopen doesn't allow file read sharing) and can be found here.
Regarding the answer saying "Unfortunately qDebug() etc. are not thread-safe. If you use threads, they will crash/break badly. Internally it uses QTextStream, which is reentrant, but not thread-safe."
I seriously doubt that, qDebug is designed to be used concurrently. File a bug if that isn't true.
Depends on how you want to use that log data.
If it is used for debugging at runtime, qWarning() would do just fine.
If you need to debug retrospective (usually server side code), plain old text files are the best. It is best to organize these log files by day log is written.
You can have a look at: https://github.com/netresultsit/uniqlogger
LGPL
thread-safe
multiple backends: file, colored console, network, rsyslog
file rotation by size and number of files
support compression of previous files
etc.
I have a plugin for a c++ MFC app. I'm working with the developer of another plugin for the same app, that's trying to get notifications of events in my code. Both plugins are in the form of c++ dlls.
How can I pass messages from my plugin to his plugin? The solution needs to be robust to mismatched versions of our two plugins, as well as the host app. The notifications are during control point movement, so several times a second.
I could set up a callback mechanism, where upon load his plugin calls a function in my plugin with a function pointer. We're not guaranteed any loading order, but we could probably just check periodically.
I know Win32 has a messaging system, but I'm not sure how it works, really. We could add a hook, and I could send messages, but I'm a bit fuzzy on how we'd synchronize what the message id is, or any details other than what I said, really.
Any other ideas on how to do this?
I'm a bit fuzzy on how we'd synchronize what the message id
Use the RegisterWindowMessage API.
Take a look at this article here, it shows the available IPC mechanisms in windows. I might try COM, Mailslots, Pipes or Shared Memory (file mapping) in your case, in addition to windows messages which you already mentioned.