I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After a
day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I cam to the
same 1 billion
'Jesus' Jeff Rogers wrote:
I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After
a day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I
On May 19, 2006, at 1:04 PM, 'Jesus' Jeff Rogers wrote:
The only bug is that Ns_CondTimedWait doesn't do any wraparound on
the time parameter. All the same, I've been enjoying telling
people that I hit my first y2038 bug.
So are you saying you've fixed it, or just that you've narrowed it
On 2006.05.19, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my
database connections.
Ahahaha! Yes, in the back of my head I always wondered (and never
bothered to compute) when that silly value of 10^9 would bite someone.
I fixed it by simply changing my MaxOpen/MaxIdle settings to 0 which
is interpreted as forever which is probably what the original one
BILLION seconds was undoubtedly intended to be.
It probably wouldn't hurt for Ns_AdjTime (in nsthread/time.c) to check
for negative seconds and have it fail
Ahhh good detective work.
Problem solved.
Thanks!!!
Zach Shaw
Web Developer, Library and Technology Services
Brandeis University
[EMAIL PROTECTED]
781-736-4206
On May 19, 2006, at 4:32 PM, 'Jesus' Jeff Rogers wrote:
I fixed it by simply changing my MaxOpen/MaxIdle settings to 0
which
Stan Kaufman wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
my database connections. My system is ACS-derived, so I wouldn't be
surprised if these database settings are common in other ACS-derived
systems.
What do you think is the reason that not all systems
On 5/19/06, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
I imagine on Linux it manifests differently; on Solaris I got the EINVAL
return from pthread_cond_timedwait (of course it isn't documented that
this can mean a bad time, it usually means a bad pointer) but on linux
with a different
On 2006.05.19, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
Ahahaha! Yes, in the back of my head I always wondered (and never
bothered to compute) when that silly value of 10^9 would bite someone.
Guess it's May 12, 2006. :-)
Can everyone who's affected go and change MaxIdle and MaxOpen
On 2006.05.19, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
I admit I've not been paying as close attention to this thread as I might,
as I've not used 3.3 in years.
Next time remind me that this is a good reason to think before posting,
folks!
--
AOLserver - http://www.aolserver.com/
To
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
(which I think was done to work around some ancient bug in an ancient
version of the nsoracle driver) then you get the problem.
I think the problem was in the oracle library (OCI), but it's been a long,
long time.
Yep.
'Jesus' Jeff Rogers wrote:
Simple, because it's a config file setting, not anything to do with
the underlying system. If your config file has
[ns/db/pool/main]
MaxOpen=10
MaxIdle=10
(which I think was done to work around some ancient bug in an ancient
version of the nsoracle
Stan Kaufman wrote:
Not defining these two vars must have been the way the 3.2.5 config
file was distributed back in the day
Yup, that was the case: http://openacs.org/doc/openacs-3/nsd.txt
Interesting that that inoculated OpenACS 3.2.5 systems from this problem.
--
AOLserver -
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
# You can also set
# them to zero, but at the time the bug was discovered, AOLserver had
# a bug that prevented you from setting them to zero.
Yeah, I knew there was a reason a big number rather than zero was chosen,
On 2006.05.19, Stan Kaufman [EMAIL PROTECTED] wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
my database connections.
My system is ACS-derived, so I wouldn't be surprised if these database
settings are common in other ACS-derived systems.
What do you think is
On 2006.05.19, dhogaza@PACIFIER.COM dhogaza@PACIFIER.COM wrote:
The billion seconds added to the current time when the database handle's
created is causing the problem, with Solaris being nice enough to toss an
error, Linux just screwing up.
To be fair, Linux isn't screwing up -- the
On 2006.05.19, dhogaza@PACIFIER.COM dhogaza@PACIFIER.COM wrote:
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
# You can also set
# them to zero, but at the time the bug was discovered, AOLserver had
# a bug that prevented you from setting them to zero.
Dossy Shiobara wrote:
Generally, the only time I've seen people config the MaxOpen and MaxIdle
to 1B seconds is when they're using an ACS or OpenACS recommended
configuration.
It might be a good idea for the OpenACS folks to edit/update their
documentation and sample configs to correct this, as
On 2006.05.19, Stan Kaufman [EMAIL PROTECTED] wrote:
It might be a good idea for the OpenACS folks to edit/update their
documentation and sample configs to correct this, as well ... although
it'll never be May 13, 2006 ever again, so maybe it's a non-issue. :-)
Now that zero works, we'll
If only folks chose 10^8 instead of 10^9 ... it would have been 1157
days or 3.1 years worth of MaxOpen/MaxIdle, and we wouldn't have
encountered this weird thread hanging bug until Nov 18, 2034. :-)
-- Dossy
Shit like this happens when you know your software platform's reliable and
may not
If only folks chose 10^8 instead of 10^9 ... it would have been 1157
days or 3.1 years worth of MaxOpen/MaxIdle, and we wouldn't have
encountered this weird thread hanging bug until Nov 18, 2034. :-)
-- Dossy
Shit like this happens when you know your software platform's reliable! :)
--
1) ns_info patchlevel
3.3.1+ad13
8.3.2
2) uname -a
Linux my.brandeis.edu 2.4.9-e.68smp #1 SMP Thu Jan 19 18:38:50 EST
2006 i686 unknown
3) glibc version
[EMAIL PROTECTED] root]# rpm -qa | grep glibc
compat-glibc-6.2-2.1.3.2
glibc-common-2.2.4-32.23
glibc-2.2.4-32.23
Cynthia Kiser wrote:
Quoting Gustaf Neumann [EMAIL PROTECTED]:
It seems, as if all problems are in tcl 8.3.*.
But just a data point from the not happening here side. I have
info patchlevel 8.3.2
FWIW, on my boxes where aolserver appears to function correctly, the tcl
in the
On Thu, May 18, 2006 at 10:03:59AM -0700, Stan Kaufman wrote:
On one box I have tcl 8.3.3 installed generally, and on another 8.4.9
(as revealed by checking [info patchlevel] from tclsh). But I presume
that in both cases, aolserver is still using the tcl in its lib
directory, correct?
FWIW, on my boxes where aolserver appears to function correctly,
the tcl in the aolserver lib is 8.3:
I have a what seems reliable test see if aolserver is working properly.
copy off your .ini file
modify any Library entries and point them to a new location.
in the new location put a .tcl
Andrew Piskorski wrote:
If all you want to know is the Tcl version AOLserver is using, it's
trivially easy, just use the Tcl info patchlevel command from inside
AOLserver.
Right; duh. Thanks. So, the version of tcl my 3.3.1+ad13 sites are using
is 8.3.2, and they appear to reboot without the VM
All versions of AOLserver 3.3 REQUIRED and shipped with their own
special version of Tcl 8.3.x. So unless you took very special steps
to make it do so, it's very unlikely that your AOLserver is using any
other version of Tcl. I tried once to make AOLserver 3.3+ad13 use a
newer version of
On 2006.05.17, Zachary Shaw [EMAIL PROTECTED] wrote:
We're experiancing a similar issue at Brandeis University, but we get
no error, our scheduled procs just hang. [...] we're running aolserver
3.3.1 ad13 [...] if I set the system date to may 12th or earilier all
the procs will run. otherwise
1) ns_info patchlevel
3.3 apparently didn't have patchlevel, as that gave me an error. The
output of ns_version is 3.3.1+ad13
2) uname -a
Linux x.furfly.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST
2006 i686 i686 i386 GNU/Linux
3) glibc version
$ rpm -qa | grep glibc
We just decided to move everything left on 3.3ad13 to 4.0, but to help
those who need it:
Can we get everyone who's experiencing this problem to provide a few
things:
1) ns_info patchlevel
I think you mean info patchlevel
I've got 8.3.2
2) uname -a
Linux servername 2.4.21-4.EL #1 Fri
My info patchlevel is also 8.3.2.
janine
On May 17, 2006, at 2:12 PM, Titi Ala'ilima wrote:
We just decided to move everything left on 3.3ad13 to 4.0, but to
help those who need it:
Can we get everyone who's experiencing this problem to provide a few
things:
1) ns_info patchlevel
I
On 2006.05.17, Titi Ala'ilima [EMAIL PROTECTED] wrote:
We just decided to move everything left on 3.3ad13 to 4.0, but to help
those who need it:
So, you're seeing this problem even on AOLserver 4.0? What version of
OpenACS?
Can we get everyone who's experiencing this problem to provide a
On May 17, 2006, at 2:35 PM, Dossy Shiobara wrote:
On 2006.05.17, Titi Ala'ilima [EMAIL PROTECTED] wrote:
Janine, could you give us your info patchlevel too? Same with
everyone else who is seing this problem and is reporting information.
8.3.2 also.
janine
--
AOLserver -
Dossy Shiobara wrote:
No, I meant ns_info patchlevel -- to get the full version of
AOLserverthat's running -- but yes, I should have asked for info
patchleveltoo, to find out what version of Tcl is being used.
patchlevel appears not to be a switch to ns_info in
AOLserver/3.3.1+ad13 (as
On 17 May 2006, at 23:35 , Dossy Shiobara wrote:
On 2006.05.17, Titi Ala'ilima [EMAIL PROTECTED] wrote:
We just decided to move everything left on 3.3ad13 to 4.0, but to
help
those who need it:
So, you're seeing this problem even on AOLserver 4.0? What version of
OpenACS?
I don't think
On 17 May 2006, at 21:34, Dossy Shiobara wrote:
Dave Siktberg seems to have narrowed it down to 2006-05-12 21:25.
In what timezone? It sound like that could equate to Sat May 13
02:27:28 BST 2006, or 1147483648 seconds since epoch, which makes it
*exactly* 1,000,000,000 seconds until expiry
SERVER #1 exhibiting the problem
% info patchlevel
8.3.3
$ rpm -qa | grep glibc
glibc-2.2.4-13
glibc-common-2.2.4-13
glibc-devel-2.2.4-13
$ uname -a
Linux opus 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
ns_info version: 3.3.1+ad13
--
AOLserver - http://www.aolserver.com/
To
So, you're seeing this problem even on AOLserver 4.0? What version of
OpenACS?
I don't think anyone has seen this problem on AOLserver 4.0.
Right, I think he meant they're fleeing to AOLserver 4.x to get rid of the
problem, and was just posting his current system info so others might be
able
It seems, as if all problems are in tcl 8.3.*.
it should be possible to compile aolserver 3.* with e.g. tcl 8.4.13.
Seems worth a try.
-gustaf
Dave Siktberg schrieb:
SERVER #1 exhibiting the problem
% info patchlevel
8.3.3
$ rpm -qa | grep glibc
glibc-2.2.4-13
glibc-common-2.2.4-13
Great detective work! I assumed the watershed time would have this kind of
characteristic.
My timezone is Eastern Daylight, BTW.
Dave Siktberg seems to have narrowed it down to 2006-05-12 21:25.
In what timezone? It sound like that could equate to Sat May 13
02:27:28 BST 2006, or 1147483648
] Something wrong after 2006-05-12 21:25 (was Re: Weird
memory leak problem in AOLserver 3.4.2/3.x)
Date: Wed, 17 May 2006 17:35:07 -0400
On 2006.05.17, Titi Ala'ilima [EMAIL PROTECTED] wrote:
We just decided to move everything left on 3.3ad13 to 4.0, but to help
those who need it:
So, you're
Quoting Gustaf Neumann [EMAIL PROTECTED]:
It seems, as if all problems are in tcl 8.3.*.
it should be possible to compile aolserver 3.* with e.g. tcl 8.4.13.
But just a data point from the not happening here side. I have
AOLserver 3.3.1+ad13 servers that are all running fine - both the ones
42 matches
Mail list logo
