Re: [log4perl-devel] Forks

[Wiggins d'A. <wi...@da...>]

Thanks for the confidence booster.  We have exhibited the mixed log 
message line problem before with syslog (rarely), and while we would 
prefer to avoid it (obviously) that is not a reason not to use Log4perl 
(since syslog is doing it to anyways), and the benefits far outway that 
to us.

I am on the list and I am sure I will have more questions as we get 
further along in development, and will definitely keep you posted.

I am familar with OSS, etc. and not to ask for timelines, etc. as I know 
they are VERY soft, but I was wondering if there is an estimated 
timeline for a version 1.0 and what the general thoughts are on what a 
version 1.0 might look like. Or if there is a development tree/timeline, 
etc. somewhere that I should have already found :-)??  Just curious as 
our next app should launch at the end of march 2003 and I was wondering 
what the status of Log4perl hopes to be by then.....

Thanks again fro the info,

http://danconia.org

Kevin Goess wrote:
> Yeah, I agree with all that.  I would think if you don't try to reload 
> the config while the process is running, you should be mostly ok. 
> Reloading might be ok, too, we're just not saying for sure yet.  Let us 
> know how it goes for you.
> 
> 
> msc...@ao... wrote:
> 
>> In a message dated 12/16/2002 2:09:49 PM Eastern Standard Time, 
>> "Wiggins d'Anconia" <wi...@da...> writes:
>>
>>
>>> First off Log4perl rules.
>>
>>
>>
>> Thanks, we're certainly happy you like it! :)
>>
>>
>>> Our app will become a daemon, then fork once to watch a series of 
>>> directories, and then fork again to process files that fall into 
>>> those directories
>>
>>
>>
>> Log::Log4perl has been designed with multi-processing/threading in 
>> mind. In the multi-threading area we do have some issues regarding 
>> config_and_watch(), especially if you change the config file in weird 
>> ways while the program is running. In the multi-processing area I'm 
>> not aware of any problems (but please file a bug if you find any :).
>>
>> Regarding concurrency in general, please make sure to know about the 
>> following: If you have one Log4perl config file which the daemon reads 
>> and passes the Log4perl configuration on to its children, you might 
>> end up with several processes sharing a single appender instance in 
>> different process spaces. Calls to this appender are *not* 
>> synchronized. Which means that if you have a, say, out-of-the-box 
>> Log::Dispatch::File appender pointing to an open file, and all 
>> processes try to log a message concurrently, you might have mingled 
>> log lines. This is extremely rare, though, I've never seen it 
>> happening even under high concurrent load. If you can't live with 
>> that, you can still write your own appender which synchronizes calls 
>> at the OS level (with semaphores or the like), but it will be slower. 
>> Let me know how it works out for you, we're certainly gonna help 
>> should you have any questions.
>>
> 
>