You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Vincenzo Gianferrari Pini <vi...@praxis.it> on 2003/02/03 17:42:34 UTC
RE: CPU loop in "heavy" production environment
> I will (1) run (tomorrow or Monday) v2.1.1a5 with <deliveryThreads> set to
> 1, and (2) later on with <deliveryThreads> set back to a higher
> value, just
> to help understand what happens and to test the fix.
Noel, for your information:
This morning I ran v2.1.1a5 with <deliveryThreads> set to 1 for 4 hours, and
I didn't get any ConcurrentModificationException: everything was OK.
This afternoon I ran 2.1.1a5 with <deliveryThreads> set to 5 for 3 hours,
and I got ConcurrentModificationException 7 times, until the CPU problem
came back again, and ConcurrentModificationException started to appear at a
high rate. This time the CPU problem took much longer to occur, compared
with v2.1.
Now I switched back to <deliveryThreads> set to 1, as I don't need any
higher value, and I will stick with that.
If you want me to do any other testing let me know; in the meantime thanks
for the help!
Vincenzo
P.S. for v2.1.1a5:
1) I'm happy to see NNTP support working, as we are going to use it.
2) Small bug found: the "hh" part of the log file names generated with the
new rotation mechanism (very nice to have) is not 24 hours based but 12
hours based, as in "mailet-2003-02-03-05-14.log" for example, that should
have been "mailet-2003-02-03-17-14.log" instead.
Bye again
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: CPU loop in "heavy" production environment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vicenzo,
Thank you for pointing it out. It looks as if the packaging process picked
up some files that it should not have, in addition to the ones that it
should. If you delete environment.xml and re-run James, you'll get the
correct one, which is in the .sar file.
This is a good lesson (for me) to make sure that I delete the directories
entirely before I build the packages.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: CPU loop in "heavy" production environment
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
> > you mean it's just enough to change "hh" to "HH"
> > in pattern="-yyyy-MM-dd-hh-mm" inside environment.xml
>
> Yes, that is exactly what I mean. :-)
>
> > With log rotation, this morning I found something strange in my log
> > directory: all log messages written into all kinds of log files after
> > midnight were going into different files, one for each different minute
>
> Yes, I reported that bug to Avalon last week. It seems to happen
> only with
> my configuration that uses both <date> and <size>. If I just use
> <date>, it
> doesn't happen. They are in the process of preparing a new
> Release version
> of LogKit, and will make sure that this is fixed before that happens.
>
> > My environment.xml file is the one coming from the installation,
> > having changed just a couple of "INFO" into "WARN".
>
> I just downloaded v2.1.1.a5 to doublecheck. The log rotation in that
> release is:
>
> <file id="smtpserver-target">
> <filename>${app.home}/logs/smtpserver</filename>
> <format>...</format>
> <append>true</append>
> <rotation type="unique" pattern="-yyyy-MM-dd" suffix=".log">
> <or>
> <date>dd</date>
> </or>
> </rotation>
> </file>
>
> So if you have the "-yyyy-MM-dd-hh-mm" pattern, and are seeing the bug you
> reported, you must have changed the rotation.
>
> --- Noel
The file I downloaded was
"/builds/jakarta-james/nightly/bin/james-binary-2.1.1a5.zip 29-Jan-2003
20:38 5.9M", the environment.xml file was last modified on 27/01/2003 2.23
(11,227 bytes) and, believe me, the log rotation was :-)
<file id="spoolmanager-target">
<filename>${app.home}/logs/spoolmanager</filename>
<format>%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}</format>
<append>true</append>
<rotation type="unique" pattern="-yyyy-MM-dd-hh-mm" suffix=".log">
<or>
<date>dd</date>
<size>10485760</size>
</or>
</rotation>
</file>
I checked right now the
"/builds/jakarta-james/nightly/bin/james-binary-2.1.1a5.zip" file, and it's
still like that. I may have downloaded and be using a wrong one then? Let me
know please.
Anyhow, I will set the file as you show in this message.
Thanks,
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: CPU loop in "heavy" production environment
Posted by "Noel J. Bergman" <no...@devtech.com>.
> you mean it's just enough to change "hh" to "HH"
> in pattern="-yyyy-MM-dd-hh-mm" inside environment.xml
Yes, that is exactly what I mean. :-)
> With log rotation, this morning I found something strange in my log
> directory: all log messages written into all kinds of log files after
> midnight were going into different files, one for each different minute
Yes, I reported that bug to Avalon last week. It seems to happen only with
my configuration that uses both <date> and <size>. If I just use <date>, it
doesn't happen. They are in the process of preparing a new Release version
of LogKit, and will make sure that this is fixed before that happens.
> My environment.xml file is the one coming from the installation,
> having changed just a couple of "INFO" into "WARN".
I just downloaded v2.1.1.a5 to doublecheck. The log rotation in that
release is:
<file id="smtpserver-target">
<filename>${app.home}/logs/smtpserver</filename>
<format>...</format>
<append>true</append>
<rotation type="unique" pattern="-yyyy-MM-dd" suffix=".log">
<or>
<date>dd</date>
</or>
</rotation>
</file>
So if you have the "-yyyy-MM-dd-hh-mm" pattern, and are seeing the bug you
reported, you must have changed the rotation.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: CPU loop in "heavy" production environment
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
> The "hh" should have been "HH". I've fixed the Wiki page, and am testing
> again today with a new release candidate of LogKit that should also fix a
> bug in their file name generation.
1) I don't understand this: you mean it's just enough to change "hh" to "HH"
in pattern="-yyyy-MM-dd-hh-mm" inside environment.xml, or should I wait for
a new release candidate?
2) With log rotation, this morning I found something strange in my log
directory: all log messages written into all kinds of log files after
midnight were going into different files, one for each different minute (say
log messages written on "04/02/03 06:32:45" and "04/02/03 06:32:58" went
into "smtpserver-2003-02-04-06-32.log", and "04/02/03 06:33:12" went into
"smtpserver-2003-02-04-06-33.log"), and now I have lots of log files. After
restarting James things got fixed. My environment.xml file is the one coming
from the installation, having changed just a couple of "INFO" into "WARN".
Thanks,
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: CPU loop in "heavy" production environment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincenzo,
I am testing a few changes, and may upload another test build tonight or
tomorrow. These are changes I had made months ago, but hadn't committed
because of where we were at in the v2.1 release cycle.
Basically, there are some infinite loops in the spooler that are never
supposed to really be infinite. My changes allow them to be interruptable,
and I also added some logging messages for some
ConcurrentModificationException catch clauses that were being ignored.
--- Noel
-----Original Message-----
From: Vincenzo Gianferrari Pini
[mailto:vincenzo.gianferraripini@praxis.it]
Sent: Monday, February 03, 2003 11:43
To: James Users List
Subject: RE: CPU loop in "heavy" production environment
> I will (1) run (tomorrow or Monday) v2.1.1a5 with <deliveryThreads> set to
> 1, and (2) later on with <deliveryThreads> set back to a higher
> value, just
> to help understand what happens and to test the fix.
Noel, for your information:
This morning I ran v2.1.1a5 with <deliveryThreads> set to 1 for 4 hours, and
I didn't get any ConcurrentModificationException: everything was OK.
This afternoon I ran 2.1.1a5 with <deliveryThreads> set to 5 for 3 hours,
and I got ConcurrentModificationException 7 times, until the CPU problem
came back again, and ConcurrentModificationException started to appear at a
high rate. This time the CPU problem took much longer to occur, compared
with v2.1.
Now I switched back to <deliveryThreads> set to 1, as I don't need any
higher value, and I will stick with that.
If you want me to do any other testing let me know; in the meantime thanks
for the help!
Vincenzo
P.S. for v2.1.1a5:
1) I'm happy to see NNTP support working, as we are going to use it.
2) Small bug found: the "hh" part of the log file names generated with the
new rotation mechanism (very nice to have) is not 24 hours based but 12
hours based, as in "mailet-2003-02-03-05-14.log" for example, that should
have been "mailet-2003-02-03-17-14.log" instead.
Bye again
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: CPU loop in "heavy" production environment
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincenzo,
Thanks for the report. Sounds like we have some improvement, but not
perfection. Please put a report in bugzilla, if you would. I may look at
this further, but since we're planning to replace a lot of this code in
James v3, I'm not sure how much time it makes sense to invest in this issue
right now.
My most significant problem with is the lack of support for cancel messages.
The way to fix that properly requires a pipeline, similar for what we use
with SMTP. Other than that, NNTP appears to work OK in v2.1.1a5.
The "hh" should have been "HH". I've fixed the Wiki page, and am testing
again today with a new release candidate of LogKit that should also fix a
bug in their file name generation.
--- Noel
-----Original Message-----
From: Vincenzo Gianferrari Pini
[mailto:vincenzo.gianferraripini@praxis.it]
Sent: Monday, February 03, 2003 11:43
To: James Users List
Subject: RE: CPU loop in "heavy" production environment
> I will (1) run (tomorrow or Monday) v2.1.1a5 with <deliveryThreads> set to
> 1, and (2) later on with <deliveryThreads> set back to a higher
> value, just
> to help understand what happens and to test the fix.
Noel, for your information:
This morning I ran v2.1.1a5 with <deliveryThreads> set to 1 for 4 hours, and
I didn't get any ConcurrentModificationException: everything was OK.
This afternoon I ran 2.1.1a5 with <deliveryThreads> set to 5 for 3 hours,
and I got ConcurrentModificationException 7 times, until the CPU problem
came back again, and ConcurrentModificationException started to appear at a
high rate. This time the CPU problem took much longer to occur, compared
with v2.1.
Now I switched back to <deliveryThreads> set to 1, as I don't need any
higher value, and I will stick with that.
If you want me to do any other testing let me know; in the meantime thanks
for the help!
Vincenzo
P.S. for v2.1.1a5:
1) I'm happy to see NNTP support working, as we are going to use it.
2) Small bug found: the "hh" part of the log file names generated with the
new rotation mechanism (very nice to have) is not 24 hours based but 12
hours based, as in "mailet-2003-02-03-05-14.log" for example, that should
have been "mailet-2003-02-03-17-14.log" instead.
Bye again
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org