[AOLSERVER] AOL Server support on Windows 64 bit.
Hi All, Is any of the AOL server versions certified to work on 64 bit Windows.?. Was this ever compiled and tested on 64 bit and confirmed the runtime to be working. If so is there any release notes/documentation specifyiong the list of files and changes pertaining to this in AOL source code?. This is critical for us. Any help is appreciated -Balaji -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Handling threads the right way
On Tue, Jun 29, 2010 at 03:23:38PM -0700, Sep Ng wrote: Basically we had aolservers running and while serving pages, it's also doing some heavy load processing from a ton of scheduled custom written procedures. Scheduled using AOLserver built-in scheduler, ns_schedule_proc, ns_schedule_daily, or the like? Aolserver crashes and segmentation faults are fairly frequent and the logs at the time pointed to these running threads as a probable cause. Then the first place to look is in your custom code, it's the most likely place for the bug. Is your scheduled code purely Tcl or does it use any C code? If you turn off your scheduled procs, does the crashing go away? This is a debugging problem, you need to find the bug before you decide how to fix it. After the crash look at the core file's stack trace in a debugger and see if that gives you any clues. Can you reproduce the problem by hitting your development AOLserver with a particular load-testing script? If the problem is non-obvious, you'll probably need that to track it down. Your focus on AOLserver's thread creation and scheduling mechanisms seems misplaced. You're speculating about ways to fix some imagined problem, but you don't know yet whether your actual problem has any similarity at all to your speculations. So basically, what I'm currently beating my head over is to build a much cleaner and better way of handling all the load It's not clear that building any such thing will help you. If the crash-inducing bugs are in your custom scheduled code, it's fairly likely that they're still going to crash no matter what thread you run them in or how you go about scheduling those threads. If after lots of looking you REALLY can't find the crash-causing bug(s), THEN I'd start thinking about ways to live with and ameliorate the problem. The simplest one of course, which you've probably already done, is to just let your AOLserver crash and make sure that it's always able to come back up quickly and pick up as close to where it left off as possible. Better, is to isolate your custom scheduled code in an entirely separate process, with communication between your AOLserver and that helper process. AOLserver 4.5 definitely includes a mechanism for doing that, but I forget what it's called. That way, your code may well still crash, but it will only take down the helper process rather than your entire AOLserver. -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Handling threads the right way
On Tue, Jun 29, 2010 at 06:19:06PM -0700, Sep Ng wrote: How can I tell which ones are thread safe? This sounds like something I will need to look into before I start writing code. *All* AOLserver modules must be thread safe. If they have any parts that are not, then that's clearly a bug which their developer overlooked, and needs to be fixed. Keep in mind however, that it's entirely possible for a module to call some external C library which happens to be completely thread-safe on one operating system, but horribly unsafe another. All part of the fun of cross-platform programming... If you manage to find a list somewhere of what MS Windows library calls are or are not thread-safe, then you could use various tools to find ALL the calls in your AOLserver binaries, and compare the two lists to see if AOLserver seems to be calling anything unsafe. Unfortunately very few operating systems provide any such clear, consolidated documentation of what function calls are thread-safe vs. not. You're lucky if the docs on each individual function call even tell you, and of course as Gustaf mentioned, occasionally those docs are wrong. My general impression though, is that historically MS Windows has tended to have a lot FEWER non-thread-safe library calls in use than Unix. This is probably because Win32 was first written in an era when threads were very popular, while most versions of Unix have roots stretching back well before then. (Supposedly that's also why the multi-process support in Win32 has always been said to be lousy, but the success of multi-process Google Chrome on Win32 suggest that those problems have either been fixed, or can be effectively worked around.) I prefer libthread, since all such threads run in an event loop. I don't think I've ever heard of this on Aolserver... I always thought Aolserver's threads would eventually end up using the tcl+libthread but it seems that there's a real difference in this. The Tcl Threads Extension's libthread was written AFTER AOLserver; in fact AOLserver is what inspired Zoran to write libthread in the first place. Generally speaking, libthread is backwards compatible with AOLserver, but also includes some newer stuff that AOLserver does not. libthread is designed so that you can easily use it from inside AOLserver, including as a drop-in replacement for AOLserver's older nsv_* code. It should be technically feasible to change AOLserver to use libthread directly, but no one has done the work. (And anyway, none of that has much of anything to do with your debugging problem.) So typically the config file has no connection whatsoever to the threads of aolserver and that it only pertains to the connection threads, or am I confusing this even further? Your the threads of aolserver terminology above is certainly confused. A connection thread is one of the various flavors of threads used in AOLserver. -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Handling threads the right way
On Jul 1, 4:59 am, Andrew Piskorski a...@piskorski.com wrote: On Tue, Jun 29, 2010 at 03:23:38PM -0700, Sep Ng wrote: Basically we had aolservers running and while serving pages, it's also doing some heavy load processing from a ton of scheduled custom written procedures. Scheduled using AOLserver built-in scheduler, ns_schedule_proc, ns_schedule_daily, or the like? Yeah. A lot of ns_schedule_* calls. We also have a thread that retrieves jobs from the database and spawns more threads to execute those jobs. Aolserver crashes and segmentation faults are fairly frequent and the logs at the time pointed to these running threads as a probable cause. Then the first place to look is in your custom code, it's the most likely place for the bug. Is your scheduled code purely Tcl or does it use any C code? If you turn off your scheduled procs, does the crashing go away? It's purely TCL code. When we did turn off the scheduled procs, aolserver would definitely not crash but with the scheduled tasks not running, aolserver does not seem to be in any burden at all and serving pages are pretty fast. This is a debugging problem, you need to find the bug before you decide how to fix it. After the crash look at the core file's stack trace in a debugger and see if that gives you any clues. Can you reproduce the problem by hitting your development AOLserver with a particular load-testing script? If the problem is non-obvious, you'll probably need that to track it down. I suppose this is as you describe it. I've been meaning to set the servers to create the core dump flie, but it never seemed to. That's a separate issue altogether and that even though ulimit reports the core file size as unlimited, it doesn't seem to be creating it. Your focus on AOLserver's thread creation and scheduling mechanisms seems misplaced. You're speculating about ways to fix some imagined problem, but you don't know yet whether your actual problem has any similarity at all to your speculations. So basically, what I'm currently beating my head over is to build a much cleaner and better way of handling all the load It's not clear that building any such thing will help you. If the crash-inducing bugs are in your custom scheduled code, it's fairly likely that they're still going to crash no matter what thread you run them in or how you go about scheduling those threads. That's a good point. If after lots of looking you REALLY can't find the crash-causing bug(s), THEN I'd start thinking about ways to live with and ameliorate the problem. The simplest one of course, which you've probably already done, is to just let your AOLserver crash and make sure that it's always able to come back up quickly and pick up as close to where it left off as possible. Yeah, we've been surviving on that for a while now. Better, is to isolate your custom scheduled code in an entirely separate process, with communication between your AOLserver and that helper process. AOLserver 4.5 definitely includes a mechanism for doing that, but I forget what it's called. That way, your code may well still crash, but it will only take down the helper process rather than your entire AOLserver. -- Andrew Piskorski a...@piskorski.comhttp://www.piskorski.com/ -- AOLserver -http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Handling threads the right way
On Jul 1, 5:21 am, Andrew Piskorski a...@piskorski.com wrote: On Tue, Jun 29, 2010 at 06:19:06PM -0700, Sep Ng wrote: How can I tell which ones are thread safe? This sounds like something I will need to look into before I start writing code. *All* AOLserver modules must be thread safe. If they have any parts that are not, then that's clearly a bug which their developer overlooked, and needs to be fixed. Keep in mind however, that it's entirely possible for a module to call some external C library which happens to be completely thread-safe on one operating system, but horribly unsafe another. All part of the fun of cross-platform programming... This likely means that whatever issues I'm hitting will still happen even with a rewrite. Alright, I will try and take a closer look at all of this. If you manage to find a list somewhere of what MS Windows library calls are or are not thread-safe, then you could use various tools to find ALL the calls in your AOLserver binaries, and compare the two lists to see if AOLserver seems to be calling anything unsafe. Unfortunately very few operating systems provide any such clear, consolidated documentation of what function calls are thread-safe vs. not. You're lucky if the docs on each individual function call even tell you, and of course as Gustaf mentioned, occasionally those docs are wrong. My general impression though, is that historically MS Windows has tended to have a lot FEWER non-thread-safe library calls in use than Unix. This is probably because Win32 was first written in an era when threads were very popular, while most versions of Unix have roots stretching back well before then. (Supposedly that's also why the multi-process support in Win32 has always been said to be lousy, but the success of multi-process Google Chrome on Win32 suggest that those problems have either been fixed, or can be effectively worked around.) I prefer libthread, since all such threads run in an event loop. I don't think I've ever heard of this on Aolserver... I always thought Aolserver's threads would eventually end up using the tcl+libthread but it seems that there's a real difference in this. The Tcl Threads Extension's libthread was written AFTER AOLserver; in fact AOLserver is what inspired Zoran to write libthread in the first place. Generally speaking, libthread is backwards compatible with AOLserver, but also includes some newer stuff that AOLserver does not. libthread is designed so that you can easily use it from inside AOLserver, including as a drop-in replacement for AOLserver's older nsv_* code. It should be technically feasible to change AOLserver to use libthread directly, but no one has done the work. (And anyway, none of that has much of anything to do with your debugging problem.) So typically the config file has no connection whatsoever to the threads of aolserver and that it only pertains to the connection threads, or am I confusing this even further? Your the threads of aolserver terminology above is certainly confused. A connection thread is one of the various flavors of threads used in AOLserver. Right. Thanks for that clarification. You guys have been tremendously helpful in giving me such immensely informative posts so this is all well appreciated. -- Andrew Piskorski a...@piskorski.comhttp://www.piskorski.com/ -- AOLserver -http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Handling threads the right way
On Wed, Jun 30, 2010 at 05:21:40PM -0400, Andrew Piskorski wrote: If you manage to find a list somewhere of what MS Windows library calls are or are not thread-safe, then you could use various tools to find ALL the calls in your AOLserver binaries, and compare the two lists to see if AOLserver seems to be calling anything unsafe. Hm, I thought you were running AOLserver on MS Windows (which is possible but certainly unusual), but later you mention using ulimit, so in hindsight my assumption was almost certainly incorrect. Are you using some flavor of Linux like most people? As for lists of thread-unsafe functions for various OSs, it seems some progress has been made since I last looked into it c. 2002 or 3. Some brief googling suggests: http://blog.josefsson.org/2009/06/23/thread-safe-functions/ http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/ http://developers.sun.com/solaris/articles/multithreaded.html http://www.devx.com/cplus/Article/4/1763/page/3 http://valgrind.org/info/tools.html#helgrind Those three guys' various lists of functions are of course unlikely to be conclusive. But it's a lot better than nothing. Personally, I think it's pretty crazy that shared libraries shipped with OSs don't provide some sort of simple list noting the thread-safety status of every single public function they provide. -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Handling threads the right way
On Jul 1, 10:42 am, Andrew Piskorski a...@piskorski.com wrote: On Wed, Jun 30, 2010 at 05:21:40PM -0400, Andrew Piskorski wrote: If you manage to find a list somewhere of what MS Windows library calls are or are not thread-safe, then you could use various tools to find ALL the calls in your AOLserver binaries, and compare the two lists to see if AOLserver seems to be calling anything unsafe. Hm, I thought you were running AOLserver on MS Windows (which is possible but certainly unusual), but later you mention using ulimit, so in hindsight my assumption was almost certainly incorrect. Are you using some flavor of Linux like most people? I'm handling quite a few differnet flavours and it's kind of maddening. I've got a Lenny, an Etch and a few old RHEL ones as well. I brought up Windows because I read here http://aolserver.am.net/docs/tuning.adpx that there were instability issues with Windows and AOLserver with certain settings. And I was wondering if the same problems extend to other OSes like Linux. As for lists of thread-unsafe functions for various OSs, it seems some progress has been made since I last looked into it c. 2002 or 3. Some brief googling suggests: http://blog.josefsson.org/2009/06/23/thread-safe-functions/ http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/ http://developers.sun.com/solaris/articles/multithreaded.html http://www.devx.com/cplus/Article/4/1763/page/3 http://valgrind.org/info/tools.html#helgrind Those three guys' various lists of functions are of course unlikely to be conclusive. But it's a lot better than nothing. That's a great bunch of links and I will pour over them for sure! Personally, I think it's pretty crazy that shared libraries shipped with OSs don't provide some sort of simple list noting the thread-safety status of every single public function they provide. That sounds like common sense to me. Would have been nice. -- Andrew Piskorski a...@piskorski.comhttp://www.piskorski.com/ -- AOLserver -http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
