Menu
▾
▴
log4perl-devel
|
From: <msc...@ao...> - 2002-12-17 06:10:33
|
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. -- -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: <msc...@ao...> - 2002-12-19 16:13:20
|
In a message dated 12/17/2002 2:16:01 PM Eastern Standard Time, "Wiggins d'Anconia" <wi...@da...> writes: >We have exhibited the mixed log >message line problem before with syslog (rarely), Actually, just wanted to mention that you can certainly work around the problem by defining different log files for your children -- that's easy to do in the Log4perl config if they all belong to different categories. And, as I said, you can always fix the overlapping permanently by working with a synchronized Log::Dispatch::XXX module (which you'd have to write, but that's fairly straight-forward, just check the Log::Dispatch documentation). >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 Funny you should ask. When we started Log::Log4perl, version 1.0 was aimed for as a complete port of Log4j. I'd say we're about 80% done for the core (on the other hand, there's still a lot of standard appenders to be written), but the remaining core parts are more or less exotic features, which hardly anyone uses, in fact no one I know of. So, it turned out that most people (in fact all people I know of) are perfectly happy with what we have right now. It's stable, we don't have any critical bugs and should we be informed about any, we would fix them immediately (within a couple of days usually). If anyone wants a feature that's currently not available (like custom filters or the like), we'll go ahead and implement it right away. If not, we're gonna work on it as time allows. So, I'm not exactly sure if we're ever going to reach 1.0 -- and it's probably not needed at all. Or, maybe we will redefine what "1.0" means, who knows. But if you're concerned about maturity or stability, I can ascertain you that we're not going to change the API anymore (unless for a very good reason) and that we're always going to make sure that the extensive regression test suite (330 test cases) will pass flawlessly. And, yes, I'm using Log::Log4perl 0.27 on a production system. -- -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: Kevin G. <ke...@go...> - 2002-12-17 18:30:01
|
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. > -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: Wiggins d'A. <wi...@da...> - 2002-12-17 23:46:17
|
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. >> > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X