> 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! :)
> 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
m
> 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'
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, 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.
>
> Yeah, I knew th
On 2006.05.19, 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 time-to-sleep being
passe
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 y
> 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 chose
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 - http://www.ao
'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
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.
>> 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/
> (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.
> I imagine on Linux it manifests differently; on Solaris I got the EINVAL
> re
On 5/19/06, Stan Kaufman <[EMAIL PROTECTED]> wrote:
What do you think is the reason that not all systems encounter this 1B
second issue? The passage of time is the one factor inevitably shared by
every system running aolserver, yet not every system barfs in the same
fashion. Why?
In our case w
> 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 Ma
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 pthre
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 enc
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"
whic
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 f
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 someon
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
'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 ca
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 sec
> 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 o
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 V
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
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? S
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 aol
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
glibc-devel-2.2.
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 on
[AOLSERVER] 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, bu
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 114748
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
glibc-de
>> 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
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 Remove
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
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 thin
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
patchlevel"too, 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 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 - http://www.aol
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
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 th
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 Fr
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
glib
43 matches
Mail list logo
