Re: [AOLSERVER] Compression
Don Baccus wrote: On Apr 12, 2008, at 8:46 AM, Brett Schwarz wrote: For *my* application, I would have the config params do the decision almost all of the time. However, I concede that other people's use cases may be different...so I think a hook into the compression decision making from application code is a good idea. I believe what I proposed covers the bases...although the details would need to be worked out... I agree with this, too. Tying in with a different thread, my suggestion for an improvement would be to ship AOLserver should with (or alongside) a standard/sample library that is intended to be looked at and tweaked (the standard library that ships currently is boilerplate). This standard library could include a filter proc to call 'ns_conn gzip 1' (or however it is exposed at the tcl level) based on the config file setting. Another thing to include in this standard library could be compatibility code for the old thread configuration directives mapping them onto the new 4.5 thread configuration commands. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver focus
Daniël Mantione wrote: Ok, practical example: We have a server, two users want to run OpenACS, and 20 users simply wants to code PHP/MySQL. Proposal to the system administrator: Put pound on Port 80 and have requests for the two OpenACS users redirected to their own AOLserver process. Now, everyone on the server will see all requests coming from localhost. Big chance is the PHP/MySQL users won't like that and put the argument "just use what everyone else uses" in place against the OpenACS users. Lots of proxies support adding in additional http headers to indicate that it is a proxied request. In certain environments (firewalled corporate paranoia) you can't avoid everything being proxied and must deal with this. And more to the point, there are simple ways (about 4 lines of code in a PerlFixupHandler) to recover the proxied connection address from such an added-in header if people are really upset about it. Or as an alternate answer: use apache itself as the proxy. The poor saps who subject themselves to PHP will be happy and the OACS users can have a real system to work with. Obnoxious alternate answer 2: tell the php users, "sorry, there's people doing real work on this system." :) Bottom line is, there's no reason why they can't coexist peacefully. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Tcl interpreter bloating
John Buckman wrote: Right restarting is not something I like to doing, because most of the time when I ctrl-c aolserver, it exists uncleanly with one of these errors: Would it work any better/more reliably to have aolserver exit itself, by calling ns_shutdown and hopefully allowing any registered shutdown handlers to run and current requests to complete? Maybe even run the server under inittab or daemontools and set up a scheduled job that checks how much memory it is using and shutting down if it is over some threshold, so the server becomes a little more self-managing. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] perl [was: Re: Advice for writing a ruby-aolserver module]
Mark Aufflick wrote: A smart idea that Vlad gave me is to use nsproxy as a base module, which apparently already fires up a pool of tcl interpreters in seperate processes. It might be a good model for our non-thread safe friends like Ruby and Perl. Perl can be thread-safe, if you jump through the right hoops (-DMULTIPLICITY and maybe another define). I did some work on making the tclperl package thread-safe with the main intent of making it work in aolserver, and got pretty good results. If there was a DBD interface to the Ns_Db functions that would make aolserver a *schweet* environment for perl apps since there is no database pooling on apache. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird "memory leak" problem in AOLserver 3.4.2/3.x)
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 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? 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 driver) then you get the problem. If your timeouts are more reasonable or 0 to explicitly specify never timeout, then no problem. It took me longer than it should have to track down this problem, since it was happenning immediately after the database connections were started, and other servers with no database connections (like the keepalive server) had no problems; we of course thought there was some database issue but didn't think about looking at the settings or that the unix daemon dogging your heels for removing that comment would stop so soon (obscure humor there...) 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 pthreads implementation it could result in locking up or just never returning (which presumably would result in all timed events after it in the queue which us sorted by time getting blocked and not running, as others reported. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird "memory leak" problem in AOLserver 3.4.2/3.x)
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 in a nicer manner, but that problem won't affect anyone for years :) -J Janine Sisk wrote: 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 down to this? If you've fixed it, do tell! :) janine -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Weird "memory leak" problem in AOLserver 3.4.2/3.x
dhogaza@PACIFIER.COM wrote: I have three servers running identical installations of AOLserver/3.3.1+ad13. On two (development and production, very low and relatively low traffic volumes respectively) all scheduled procs have stopped firing. My God, it sounds to me like you're all being bit by the Y2.006K problem! :) That answer is closer than you think (at least if everyone is having the same problem I was) ... actually it's Y2.038K -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird "memory leak" problem in AOLserver 3.4.2/3.x)
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 second issue. 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. 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. -J Bas Scheffers wrote: 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 of 32 bit time. Coincidence? Seems too strange as to a computer that is not a nice round number. I wonder what Dan Brown would have to say about it! :) Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
