Hello!
On Tuesday 12 May 2009 12:51:02 Gustaf Neumann wrote:
Very wierd. So, the behavior must be influenced by the environment.
What is the output, if you call time-format from aolserver (via exec)
(this way, the external program runs with the same set of
environment variables as the
Mr Spock would say: fascinating.
We know at least, that the environment is indeed
not the problem. Can you check, whether both programs
use the same strftime function?
such as:
$ nm time-format| fgrep strftime
U strftime@@GLIBC_2.2.5
$ nm
Hello!
On Tuesday 12 May 2009 17:29:38 Gustaf Neumann wrote:
Mr Spock would say: fascinating.
We know at least, that the environment is indeed
not the problem. Can you check, whether both programs
use the same strftime function?
such as:
$ nm time-format| fgrep strftime
Looking at the source for a strftime, I see only two possible problems:
1. The format passed to sprintf is wrong, or
2. the case 'd' branch could be missing the continue, so that case 'e'
runs, and replaces the result of 'd':
case 'd':
pt = _conv(t-tm_mday, %02d, pt, ptlim);
Hello!
I'm sorry but the problem is produced by patch for non-english locale.
This patch use wrong format string:
snprintf(buf, 40, %s, %d %s %d %02d:%02d:%02d GMT,
I did fix the bug and I'm think this patch may be added to upstream.
Patch is here:
Thanks Gustaf, that fixed it.
janine
On May 11, 2009, at 9:59 AM, Gustaf Neumann wrote:
Dear Janine,
please check:
http://www.openacs.org/forums/message-view?message_id=488620
The problem was fixed in OpenACS more than 2 years ago.
Great! I was actually thinking that it would be much easier in this
particular case to avoid strftime, since all of the variability in the
format is removed. It is huge overkill, and obviously broken in
non-english languages.
tom jackson
On Tue, 2009-05-12 at 20:36 +0400, Alexey Pechnikov
On May 11, 2009, at 12:11 AM, Gustaf Neumann wrote:
Janine,
the values make sense, since the 4.5.1 does not omit the cleanups
but instead of doing these at the same time, it distributes these
(by default by a randomization factor of 20%). The longer the
server runs the spikes should go down,
Hello!
I think you can try these:
1. Disable https (HAProxy+stunnel is better).
2. Disable fancy parser if simple parser is enough.
3. The database pool of 300 connections to Oracle or PostgreSQL is
huge. 25 or may be 50 is more reason.
4. Disable logs (may be replaced to HAProxy logging).
5.
Janine Sisk schrieb:
When I first started working on this problem, the settings were
ns_param maxconnections 5
ns_param maxthreads 5
ns_param minthreads 5
maxconnections of 5 is for most applications to small. The term
maxconnections is misleading since it does not
On May 12, 2009, at 1:23 PM, Gustaf Neumann wrote:
Janine Sisk schrieb:
When I first started working on this problem, the settings were
ns_param maxconnections 5
ns_param maxthreads 5
ns_param minthreads 5
maxconnections of 5 is for most applications to small. The
On Tue, 2009-05-12 at 22:23 +0200, Gustaf Neumann wrote:
Janine Sisk schrieb:
When I first started working on this problem, the settings were
ns_param maxconnections 5
ns_param maxthreads 5
ns_param minthreads 5
maxconnections of 5 is for most applications
On Tue, 2009-05-12 at 20:36 +0400, Alexey Pechnikov wrote:
Hello!
I'm sorry but the problem is produced by patch for non-english locale.
This patch use wrong format string:
snprintf(buf, 40, %s, %d %s %d %02d:%02d:%02d GMT,
I did fix the bug and I'm think this patch may be added to
13 matches
Mail list logo
