Re: [Log4cpp-devel] Modifying log4cpp to support realtime systems

[S R. <kiw...@ma...>]

On Oct 26, 2009, at 02:10 , Konstantin Litvinenko wrote:

> S Roderick пишет:
>> Actually, no. We derive from log4cpp::Category and extend it to use a
>> buffer of log4cpp::LoggingEvent entries. Attached to this buffer are
>> one or more Appender components, each of which contains an appender
>> internally. The category side is real-time, the appender side is not.
>> This is being integrated within a real-time robotics framework called
>> Orocos (http://orocos.org/). Our Category object contains a reference
>> to the real-time buffer, as well as overriding  
>> Category::callAppenders
>> () to push to the port instead of directly calling the appenders.  
>> This
>> provides the separation between the real-time and non-realtime parts
>> of the system. Orocos deals with creating the ports and associating
>> things correctly.
>>
>> So with the changes I'm proposing, the hiearachy maintainer needs to
>> create derived Category objects, and LoggingEvents must use a real-
>> time allocator (based on TLSF) to be useable within the real-time,
>> Category side of the system. Once everything is in the non-realtime
>> part of the system (ie within appenders and layouts), we no longer
>> care about real-time and can revert to std::string and the default
>> (very non-realtime) memory allocator.
>>
>> I hope this explains the situation better.
> Yes. Thanx.
> If I correctly understand all you wishes you need to collect and send
> all logging events into some sink in real-time manner. So base on  
> this I
> propose next steps:
> 1. Create RT Category class.

This is what we've done, but I doubt that you want an Orocos-specific  
class inside log4cpp?

> 2. Instruct somehow log4cpp to create RTCategory in  
> HierarchyMaintainer .

Yes! This is what I'm trying to figure out the best way to do it. It  
would be nice to come up with a general method to do this for any  
derived Category class, so that other projects can add functionality  
that they might need. This led me to thoughts of a factory class to  
create Category objects, or some way to override the default  
HierarchyMaintainer instance at runtime.

> 3. Collect all events (not LogingEvents) in a rt buffer and send they
> into a sink - serialize and send to socket for example.
> 4. On other side of sink you may have some listener that receive,
> deserialize and invoke log4cpp with preconfigured nonrt
> categories/appenders to do real logging.

We actually just send LoggingEvents through the buffer. What benefit  
do you see with sending events that are not LoggingEvents? Aren't they  
going to contain the same data? As part of this, you would need to  
completely override all the logging functions in RTCategory to take  
rt_string objects instead of std::string. It seems like we would be  
completely replacing the Category and LoggingEvent classes, where as  
with my current implementation we build a slightly different  
LoggingEvent class, and we override just a couple of functions in the  
RTCategory class. One of my primary aims going in to this was to reuse  
as much of log4cpp as possible.

> To do all this work you don't need to modify LoggingEvent, because you
> may use whatever logging event container you need in RTCategory - it  
> is
> fully internal class in this context.

I understand what you are suggesting, I just don't see the benefits.  
Are you primarily hoping for the user to avoid building different  
versions of log4cpp (ie with or without a LoggingEvent class that uses  
rt_string)?

Thanks
Stephen