You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2010/02/08 20:30:38 UTC
DO NOT REPLY [Bug 48704] New: Multiple Java Process in Cluster
Logging to the same log file and rotating the same log file
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
Summary: Multiple Java Process in Cluster Logging to the same
log file and rotating the same log file
Product: Log4j
Version: 1.2
Platform: Sun
OS/Version: Solaris
Status: NEW
Keywords: APIBug
Severity: normal
Priority: P2
Component: Appender
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: aware24seven@gmail.com
This may already be a known issue.
When multiple java process log to the same log file and rotate the same log
file the process that gets to rotate the file first gets the change to write to
the new and most current log file and all other java processes continue to log
to the renamed, rotated file.
Scenario relevance : this probably should happen in any clustered environtment
where cluster members log to the same log file.
The issue seems to be happenning because the file writers in the other java
processes are still pointing to the old file that was renamed by the other java
process in a cluster.
So if there is an additional rollOver method, in the current RollOver classes,
that is cluster aware that checks the file writers in the appenders and
refreshes them before writing to a log file and also after rolling them over it
would be a great help to clustered environtments.
Otherwise developers may have to extend the appenders and add this
functionality and may have to update code everytime when Apache does a new
log4j release.
I have attached one such sample zip file with changed src code for reference.
Or if there is some other solution to this problem can someone pls update the
online documentation. Thanks !
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #12 from Curt Arnold <ca...@apache.org> 2010-02-15 13:11:49 UTC ---
Reverted in rev 910151.
The independent authorship of the patch is disputed, see log4j-dev mailing list
on 2010-02-14. Since a release push for log4j 1.2.16 is underway, it seems
prudent to pull the patch for the time being.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #4 from aware24seven@gmail.com 2010-02-11 17:40:45 UTC ---
Thank you all for your response !
I tried the tip to use logback and tested this in a windows env and it seems to
work fine, thanks, when same file is accessed from multiple jvms and from
multiple threads.
General questions though ..since the app is already in prod and we are looking
to take the route with minimal change to fix this until the next release is
scheduled...
* Is log4j goging to be retired soon ? Is there a place in the website where I
can see End Of Life notifications for log 4j api ?
* If we had to override a few public and protected methods from the current
rolling file appenders how safe is it from a change management point of view ?
Ball park, are there any proposals to update RFA's say within the next 6 months
?
Thanks !
(In reply to comment #3)
> Alternatively, you could use logback, log4j's successor, which supports having
> multiple JVMs writing to the same file. See prudent mode [1] for details.
> [1] http://logback.qos.ch/manual/appenders.html#prudent
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #10 from Curt Arnold <ca...@apache.org> 2010-02-13 18:20:07 UTC ---
I've done a quick implementation of prudent mode. However, I think your
success with logback's RFA's could be due to switch from Unix to Windows,
instead of switching to prudent mode on logback.
Reviewing your log you mentioned that you tested logback's RFA in a Windows
environment, but your initial bug report indicates Solaris and the behavior you
describe is how RFA's misbehave on Unix platforms when multiple RFA's are
acting. File renames and deletes are radically different between Windows and
Unix. Basically, in Unix directory entries are changed, but any existing
handle is still valid for operations. On Windows, an attempt to rename an open
file will fail and the rollover does not occur.
Prudent mode would likely improve observed behavior of multiple JVM's writing
to the same file, however I do not believe it would offer any benefit to the
observed behavior on rollovers under Unix-like OS's. I did a quick check of
the logback code and was not able to find anything that indicated that looked
like cross-app locking around file renames if that were possible.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #5 from Ceki Gulcu <ce...@apache.org> 2010-02-11 18:03:54 UTC ---
* SLF4J ships with a migration tool [1] which significatly eases the
pain of migrating to SLF4J from log4j. Once you migrate to SL4J, you
can either continue to use log4j or switch to logback. Since logback
natively implements the SLF4J API, you don't need change the code in
*your* application. BTW, that is the whole point of SLF4J.
* Although log4j has been vegetating for several years, I don't see any
indication that log4j will be officially retired any time soon.
* The logging API of logback is determined by SLF4J which is very
stable. However, although logback internals are relatively stable, that
stability is not guaranteed and radical changes may occur. More
specifically, there are proposals [2] to change the way FileAppender
and co. write their output to log files. When this change is adopted,
it will affect your implementation of RFA. Nevertheless, you should be
able to adapt to the changes with few lines of code on your
side. It should be mechanical change...
[1] http://www.slf4j.org/migrator.html
[2] http://jira.qos.ch/browse/LBCORE-128
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #6 from Curt Arnold <ca...@apache.org> 2010-02-12 13:28:59 UTC ---
I have not reviewed the logback implementation, but there is nothing that
indicates that implementing the "prudent" mode in log4j would not be possible.
Apache log4j and QoS.ch's logback have a shared heritage, but have divergent
licenses, communities and governance. Statements from one fork about the other
should be considered in that light.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #9 from Curt Arnold <ca...@apache.org> 2010-02-13 15:21:25 UTC ---
By my reading, the effectiveness of prudent mode is dependent on the JVM
implementation and OS. Can't make a hard guarantee that things will work as
desired or consistently on different JVM implementations or OS's.
http://java.sun.com/javase/6/webnotes/compatibility.html, item 3, suggests that
it may be more effective on JDK 1.6 than 1.4 or 1.5.
http://books.google.com/books?id=BSz14O3uQwsC&lpg=PA68&ots=ZOO7a9ysfH&dq=java%20FileChannel%20multiple%20JVM&pg=PA68#v=onepage&q=java%20FileChannel%20multiple%20JVM&f=false
(O'Reilly Java NIO, page 68)
"The semantics of concurrent file access by multiple processes is highly
dependent on the underlying operating system and/or filesystem. Concurrent
access to the same file by FileChannel objects running in different JVMs will,
generally, be consistent with concurrent access between non-Java processes."
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #3 from Ceki Gulcu <ce...@apache.org> 2010-02-10 00:51:04 UTC ---
Alternatively, you could use logback, log4j's successor, which supports having
multiple JVMs writing to the same file. See prudent mode [1] for details.
[1] http://logback.qos.ch/manual/appenders.html#prudent
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[Bug 48704] Multiple Java Process in Cluster Logging to the same log
file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
Anil Kumar <ak...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|Sun |Other
OS|Solaris |Windows Server 2003
--- Comment #15 from Anil Kumar <ak...@gmail.com> ---
Hi
I have written a Java Class to log some telephonic based error event in Log4j
logs. I am able to write that logs to the file however other java class which
not a part of my Java Application project are also pushing there logs in my log
fie. Any idea how do I fix this issue?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #13 from aware24seven@gmail.com 2010-02-16 15:45:33 UTC ---
Iam sorry .you are correct I performed my test on windows env the other day
with log back ..today I compiled and ran the same code in Solaris 5.10 env with
jdk150_11 and got the same results.
I used TimeBasedRolling with prudent mode( as there were some constraints with
using size based rolling with prudent mode in logback) and tried to roll same
file from two multithreaded java instances pointing to the same log file and
the rolling and logging worked well as far as I can tell found no issues with
Solaris.
Btw ..thank you for the fix ..I will look forward to it on the next release of
log4j.
(In reply to comment #12)
> Reverted in rev 910151.
> The independent authorship of the patch is disputed, see log4j-dev mailing list
> on 2010-02-14. Since a release push for log4j 1.2.16 is underway, it seems
> prudent to pull the patch for the time being.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #11 from Curt Arnold <ca...@apache.org> 2010-02-13 18:25:33 UTC ---
Committed purient mode option in rev 909868.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #14 from aware24seven@gmail.com 2010-04-22 11:18:38 EDT ---
Hi
iam seeing that log4j version 16 got released sometime in April ..so did this
patch make it in by any chance ?
Thanks !
(In reply to comment #13)
> Iam sorry .you are correct I performed my test on windows env the other day
> with log back ..today I compiled and ran the same code in Solaris 5.10 env with
> jdk150_11 and got the same results.
> I used TimeBasedRolling with prudent mode( as there were some constraints with
> using size based rolling with prudent mode in logback) and tried to roll same
> file from two multithreaded java instances pointing to the same log file and
> the rolling and logging worked well as far as I can tell found no issues with
> Solaris.
> Btw ..thank you for the fix ..I will look forward to it on the next release of
> log4j.
> (In reply to comment #12)
> > Reverted in rev 910151.
> > The independent authorship of the patch is disputed, see log4j-dev mailing list
> > on 2010-02-14. Since a release push for log4j 1.2.16 is underway, it seems
> > prudent to pull the patch for the time being.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #8 from Curt Arnold <ca...@apache.org> 2010-02-13 14:47:27 UTC ---
I've reviewed logback's implementation of "prudent" mode. Essentially, it
precedes each stream write with java.nio calls to lock the stream and position
the stream to the end of the file, then it performs the write and then releases
the lock. As it depends on java.nio, it is not available on JDK's prior to
1.4. It is a reasonable hybrid use of java.io and .nio.
I'll take a shot implementing it and try to make it so it doesn't add a JDK 1.4
run-time dependency unless you use it.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java
Process...)
Posted by Ceki Gülcü <ce...@qos.ch>.
On 13/02/2010 5:59 AM, Curt Arnold wrote:
> I believe the thread that you are thinking about is
> http://marc.info/?l=log4j-dev&m=122841935827332&w=2.
I was indeed thinking of the message you referenced above.
> You were arguing that log4j 1.2 should make a significant API change
> (changing Logger.info(Object) to Logger.info(String) et al) to enable
> convergence to a logging standard (SLF4J). My statement was to the
> effect that the API standardization war was won by java.util.logging
> and isn't going to be deprecated in favor of SLF4J if only log4j would
> change its API to align with SLF4J.
It is possible to have log4j adopt the SLF4J without breaking
compatibility with existing client code. As I outlined in LOG4J2-27 on
5th of December 2008, we could alter the org.apache.log4j.Category
class to keep the same signatures but have the method implemenations
delegate to org.apache.log4j.impl.Logger. The
org.apache.log4j.impl.Logger class would implement the
org.slf4j.Logger interface. As I explained then, clients wishing to
use the existing log4j classes and API could continue to do so. Those
wishing to standardize on the SLF4J API could do so as well.
The API standardization question has certainly not been won by
java.util.logging. I find it troubling that you as the chair of the
Apache Logging PMC should make a statement to the contrary, but maybe
that's just me, the founder of the log4j project.
> I do believe that incremental fixes and enhancements to log4j 1.2 are
> worthwhile for the established community. While I'm not making as
> many commits as I would like, I'm making a whole lot more than someone
> who wants log4j to vegetate and die. Due to the large number of
> implementation details exposed in the classes, it is very difficult to
> make substantial changes to log4j 1.2 without compatibility issues.
It boils down to the vision you have of the log4j project. As I see
it, j.u.l. is beyond redemption. More importantly, the java platform
is in need of consolidation with respect to logging. The current
situation is way too confusing for users. SLF4J is making strides in
this regard and is on its way in establishing itself as a de facto
standard. If log4j adopted SLF4J as its core interface, it would go a
long way in solving the logging consolidation issue. You have
previously stated that log4j endorsing SLF4J would boost the SLF4J
project without tangible gains for log4j. I, in contrast, believe that
having a common vision for log4j would benefit the log4j project as
well. Also keep in mind that one of the main selling points of logback
is it is a native implementation of the SLF4J API. Log4j's adoption of
SLF4J would reduce the relevance of that particular competitive
advantage logback has over log4j.
Anyway, to keep a long story short, you had over 5 years to impart
your vision of log4j, now it is high time to put your seat as
PMC-chair up for elections. You might get re-elected in which case
things would probably continue as they are, or another candidate might
be elected who could set a new direction for the log4j project.
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java
Process...)
Posted by Ceki Gülcü <ce...@qos.ch>.
On 19/02/2010 7:03 PM, Christian Grobmeier wrote:
> This said, why not having another election. I don't think its
> necessary, but if you feel better with that, lets do it.
Elections should not be held just to assuage my feelings.
> Here is a list of team members:
> http://logging.apache.org/team-list.html
> But its out of date. Are there complete lists somewhere? That might be
> a good start for seeing who is eligible.
Looking at the board's committee-info.txt file, here is the list of
the Logging PMC members in alphabetical order:
Curt Arnold (chair)
Nicko Cadell
Scott Deboy
Ron Grabowski
Christian Grobmeier
Ceki Gulcu
Jacob Kjome
Paul Smith
Mark Womack
and the list of committers is a bit longer
Andreas Fester
Alvaro Carrasco
Curtis William Arnold
Christophe de Vienne
Ceki Gulcu
Gert Driesen
Elias Nathan Ross
Gavin McDonald
Christian Grobmeier
Jacob Kjome
Knut Urdalen
Michael Catanzariti
Michael Schmitz
Mark Dwayne Womack
Niall Daley
Nicko Cadell
Paul Jeffrey Smith
Ralph Goers
Ron Grabowski
Scott Deboy
Yoav Shapira
From the above list, only the following persons have committed code
within the last 12 months:
Scott Deboy (chainsaw, sandbox)
Curt Arnold (log4j, log4cxx, site),
Ron Grabowski (log4net),
Christian Hammers (log4php)
Gavin McDonald (log4php)
Christian Grobmeier (log4php)
From the looks of it, log4php is the most active Apache Logging
project, and still in the incubator. Jacob Kjome, Ceki Gulcu and Ralph
Goers are active by regularly answering questions and by participating
on the various mailing lists. Sorry if I am forgetting to mention
another active person. To dissipate any misunderstanding, voting
rights are a formal right not directly linked to to one's level of
activity.
As Ralph points out, there is not point of holding the elections
unless someone else actually wants the job. This question is a little
different than the PMC putting his chair up for elections. He may
indeed be the only candidate but if the question is never raised, a
new chair cannot be elected even when there are other volunteers for
the job.
> Cheers,
> Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java
Process...)
Posted by Christian Grobmeier <gr...@gmail.com>.
> The definitive list is
> at https://svn.apache.org/repos/private/committers/board/committe-info.txt.
> You have to be a committer to have access to this repository. The list you
> refer to is fairly accurate, however you are also listed as being on the PMC
> even though you don't appear on the web page.
Thanks for the link, actually interesting
> Although I'm not on the PMC I fail to see the point of holding a vote unless
> someone else actually wants the job.
Good point too - we might ask who is willing to do this job besides
Curt first. There might not be too much other people :-)
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java Process...)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 19, 2010, at 10:03 AM, Christian Grobmeier wrote:
>>
>
> I think asking for a new election is not a bad thing and you might not
> need to utilize the board for this. I just think that your are asking
> here for the wrong reasons. However - you are PMC member yourself and
> I think your voice should be heard too. Just to say clear, the
> direction of Log4J is not given by the chair but by the community
> discussion.
>
> This said, why not having another election. I don't think its
> necessary, but if you feel better with that, lets do it.
>
> Here is a list of team members:
> http://logging.apache.org/team-list.html
>
> But its out of date. Are there complete lists somewhere? That might be
> a good start for seeing who is eligible.
The definitive list is at https://svn.apache.org/repos/private/committers/board/committe-info.txt. You have to be a committer to have access to this repository. The list you refer to is fairly accurate, however you are also listed as being on the PMC even though you don't appear on the web page.
Although I'm not on the PMC I fail to see the point of holding a vote unless someone else actually wants the job.
Ralph
Re: log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java
Process...)
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi,
>> I am due to file another quarterly board report and will mention your
>> concerns. You are also free to petition the ASF Board.
>>
>> Except in extraordinary circumstances, the PMC chair should have no
>> more control over the direction of the project than any other PMC
>> member. The PMC chair is required to report to the board quarterly or
>> as directed by the board and is responsible for managing SVN rights.
>> Nothing prevents anyone else from sending an email to board@apache.org
>> if the PMC chair is out of line. Managing SVN rights should be in
>> response to a PMC vote.
having this in mind, a PMC chair is a person who fills out the reports
for the board.
> In the Apache projects I am familiar with, the PMC chair put his or
> her chair up for elections every year or so. While I cannot point you
> to a document stating this on black or white, as far as I know,
> holding elections for the PMC-chair position is part of the Apache
> tradition.
I only know MINA doing regular votes on the PMC chair. I even don't
know who is it in Commons world. I cannot remember a vote on the chair
too, but i might have missed it.
> When I and later Mark Womack held the position of Logging
> PMC chair, we both put up our seats for elections every year. It is
> ironic that you should point out that QOS.ch does follow the Apache
> governance model and then proceed to justify that indefinitely holding
> on to your position as chairman does not formally contravene the
> Apache model, all in the same thread.
I think Curt has done a very well job in the past years. As far as I
can see he is one of the guys who kept this project alive for a time.
Without him, Log4J as a Apache project might have died a while ago.
That said, I think there were no interest of anybody here to step up
as a chair. As Curt already pointed out, a chair is nothing else than
a PMC member who reports to the board. The direction of the project is
not given by its chair but by the PMC, the committers and at least
from the community itself.
Curt has a strong voice in Log4J world. It is not because he "reigns"
or "leads" this project. It is because he cared about it. This is - in
my eyes the difference to QOS (which I don't know very well) were a
leader is giving the direction. At least, he wouldn't do things which
are not in line with the community; if he does errors (what we all do
from time to time) he has already proven to correct it and to wait
until the issue is solved.
What I want to say is, that Curt has done a very good job and having
the chair for a long while is not against Apache principles in my
eyes. What you said sounds a bit like he would have taken over
complete control, but I cannot see this.
> Asking you to put up your seat for elections after five years is a
> reasonable demand. I should not need to petition the board on this
> issue.
I think asking for a new election is not a bad thing and you might not
need to utilize the board for this. I just think that your are asking
here for the wrong reasons. However - you are PMC member yourself and
I think your voice should be heard too. Just to say clear, the
direction of Log4J is not given by the chair but by the community
discussion.
This said, why not having another election. I don't think its
necessary, but if you feel better with that, lets do it.
Here is a list of team members:
http://logging.apache.org/team-list.html
But its out of date. Are there complete lists somewhere? That might be
a good start for seeing who is eligible.
On another note: the whole discussions of the past days are full of
emotions, sometimes quite bad words and problems on a very personal
level. Please lets keep this outside and continue on a objective and a
more "nice" level. This all is what we should enjoy - it should not
frustrate anybody of us.
Cheers,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java
Process...)
Posted by Ceki Gülcü <ce...@qos.ch>.
On 13/02/2010 5:59 AM, Curt Arnold wrote:
> I am due to file another quarterly board report and will mention your
> concerns. You are also free to petition the ASF Board.
>
> For background for those who are new to this topic. From
> http://www.apache.org/foundation/how-it-works.html#pmc-chair:
>
> > The Chair of a Project Management Committee (PMC) is appointed by the
> > Board from the PMC Members. The PMC as a whole is the entity that
> > controls and leads the project. The Chair is the interface between the
> > Board and the Project.
>
> Except in extraordinary circumstances, the PMC chair should have no
> more control over the direction of the project than any other PMC
> member. The PMC chair is required to report to the board quarterly or
> as directed by the board and is responsible for managing SVN rights.
> Nothing prevents anyone else from sending an email to board@apache.org
> if the PMC chair is out of line. Managing SVN rights should be in
> response to a PMC vote.
>
> I am due to file another quarterly board report and will mention your
> concerns. You are also free to petition the ASF Board.
In the Apache projects I am familiar with, the PMC chair put his or
her chair up for elections every year or so. While I cannot point you
to a document stating this on black or white, as far as I know,
holding elections for the PMC-chair position is part of the Apache
tradition. When I and later Mark Womack held the position of Logging
PMC chair, we both put up our seats for elections every year. It is
ironic that you should point out that QOS.ch does follow the Apache
governance model and then proceed to justify that indefinitely holding
on to your position as chairman does not formally contravene the
Apache model, all in the same thread.
Asking you to put up your seat for elections after five years is a
reasonable demand. I should not need to petition the board on this
issue.
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
log4j governance (was Re: DO NOT REPLY [Bug 48704] Multiple Java Process...)
Posted by Curt Arnold <ca...@apache.org>.
On Feb 12, 2010, at 8:29 AM, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
>
> --- Comment #7 from Ceki Gulcu <ce...@apache.org> 2010-02-12 14:29:36 UTC ---
> (In reply to comment #6)
>> I have not reviewed the logback implementation, but there is nothing that
>> indicates that implementing the "prudent" mode in log4j would not be possible.
>
> Prudent mode could be implemented in log4j. It would just take a few days of
> work.
Will spin that off into another thread.
>
>> Apache log4j and QoS.ch's logback have a shared heritage, but have divergent
>> licenses, communities and governance. Statements from one fork about the other
>> should be considered in that light.
>
> Arnold, speaking of governance, when do you plan to put your seat as
> chairman of the Apache Logging project for elections? Five years
> without elections is not exactly the Apache way, is it?
For background for those who are new to this topic. From http://www.apache.org/foundation/how-it-works.html#pmc-chair:
>
> The Chair of a Project Management Committee (PMC) is appointed by the Board from the PMC Members. The PMC as a whole is the entity that controls and leads the project. The Chair is the interface between the Board and the Project.
Except in extraordinary circumstances, the PMC chair should have no more control over the direction of the project than any other PMC member. The PMC chair is required to report to the board quarterly or as directed by the board and is responsible for managing SVN rights. Nothing prevents anyone else from sending an email to board@apache.org if the PMC chair is out of line. Managing SVN rights should be in response to a PMC vote.
I am due to file another quarterly board report and will mention your concerns. You are also free to petition the ASF Board.
> You previously
> stated that since the advent of java.util.logging there was no longer
> any need for log4j. It is my understanding that your vision for the
> future of log4j is to see it vegetate and die. Or am I misquoting you
> in some way?
>
Yes.
I believe the thread that you are thinking about is http://marc.info/?l=log4j-dev&m=122841935827332&w=2.
You were arguing that log4j 1.2 should make a significant API change (changing Logger.info(Object) to Logger.info(String) et al) to enable convergence to a logging standard (SLF4J). My statement was to the effect that the API standardization war was won by java.util.logging and isn't going to be deprecated in favor of SLF4J if only log4j would change its API to align with SLF4J.
I think that log4j 2.0 should clearly separate the logging backend from the API and that the backend be capable with working with multiple API's including java.util.Logging, org.apache.log4j.Logger and SLF4J. Relevant JIRA issues:
http://issues.apache.org/jira/browse/LOG4J2-5
http://issues.apache.org/jira/browse/LOG4J2-6
http://issues.apache.org/jira/browse/LOG4J2-11
http://issues.apache.org/jira/browse/LOG4J2-12
http://issues.apache.org/jira/browse/LOG4J2-27
I do believe that incremental fixes and enhancements to log4j 1.2 are worthwhile for the established community. While I'm not making as many commits as I would like, I'm making a whole lot more than someone who wants log4j to vegetate and die. Due to the large number of implementation details exposed in the classes, it is very difficult to make substantial changes to log4j 1.2 without compatibility issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #7 from Ceki Gulcu <ce...@apache.org> 2010-02-12 14:29:36 UTC ---
(In reply to comment #6)
> I have not reviewed the logback implementation, but there is nothing that
> indicates that implementing the "prudent" mode in log4j would not be possible.
Prudent mode could be implemented in log4j. It would just take a few days of
work.
> Apache log4j and QoS.ch's logback have a shared heritage, but have divergent
> licenses, communities and governance. Statements from one fork about the other
> should be considered in that light.
Arnold, speaking of governance, when do you plan to put your seat as
chairman of the Apache Logging project for elections? Five years
without elections is not exactly the Apache way, is it? You previously
stated that since the advent of java.util.logging there was no longer
any need for log4j. It is my understanding that your vision for the
future of log4j is to see it vegetate and die. Or am I misquoting you
in some way?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #1 from Curt Arnold <ca...@apache.org> 2010-02-09 21:04:43 UTC ---
You are correct that it is a known issue. I don't have the time at the moment
to check which bug I should mark this as a duplicate.
The unavoidable issue (at least for anything derived from WriterAppender) is
that java.io provides no mechanism to synchronize file writing between multiple
JVM's or even multiple FileOutputStreams within a single JVM's.
Most of the time when people configure multiple appender to write to the same
file, everything seems to work. However, they are depending on implementation
details. Things do go spectacularly wrong with the RFA's as you have noticed.
There is no way to reliably address this using java.io. The right thing to do
would be to write a RFA replacement using java.nio which has been on my wish
list for years now.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48704] Multiple Java Process in Cluster Logging to
the same log file and rotating the same log file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48704
--- Comment #2 from Jess Holle <je...@ptc.com> 2010-02-09 21:19:15 UTC ---
Or you just avoid the contention of trying to share one log file across
multiple processes, e.g. by using process id (and host name as needed) in the
log file name. [The process id is readily available in Java 5 and higher.]
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org