Re: [AOLSERVER] Error Handling
Wow, that is a *great* idea. Then you could register an exception handler for a url path. If it's possible, it would probably have to be something set inside the Tcl interp that is running the ADP or Tcl code, before it starts running the code. Unfortunately I don't yet know enough about Tcl internals to know how to go about doing this, but it is well worth looking into. /s. Is there any way in AOLServer to register an exception handler? What I would like to avoid is going over all the pages in my site and adding a catch statement so that if an exception is thrown, either through the tcl interpreter or or a postgresql query or action, I could catch it with a proc or page. Thanks, Vince
Re: [AOLSERVER] Error Handling
Yes it is. If we end up using AOLserver, we will require something like that. If it can't do it, I'll be writing a parser (in TCL) for our pages that will do it. -- Mark Hubbard: [EMAIL PROTECTED] Microsoft Certified Professional Knowledge is Power. -Original Message- From: Scott Goodwin [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, August 22, 2001 2:04 PM Subject: Re: Error Handling Wow, that is a *great* idea. Then you could register an exception handler for a url path. If it's possible, it would probably have to be something set inside the Tcl interp that is running the ADP or Tcl code, before it starts running the code. Unfortunately I don't yet know enough about Tcl internals to know how to go about doing this, but it is well worth looking into. /s. Is there any way in AOLServer to register an exception handler? What I would like to avoid is going over all the pages in my site and adding a catch statement so that if an exception is thrown, either through the tcl interpreter or or a postgresql query or action, I could catch it with a proc or page. Thanks, Vince
Re: [AOLSERVER] Error Handling / post-processing
Along the same lines, is there a way to capture all the output from an ADP in a buffer, and then alter it before it's transmitted? This would allow things that can't be done easily, or at all, in IIS/ASP. -- Mark Hubbard: [EMAIL PROTECTED] Microsoft Certified Professional Knowledge is Power. -Original Message- From: Scott Goodwin [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, August 22, 2001 2:04 PM Subject: Re: Error Handling Wow, that is a *great* idea. Then you could register an exception handler for a url path. If it's possible, it would probably have to be something set inside the Tcl interp that is running the ADP or Tcl code, before it starts running the code. Unfortunately I don't yet know enough about Tcl internals to know how to go about doing this, but it is well worth looking into. /s. Is there any way in AOLServer to register an exception handler? What I would like to avoid is going over all the pages in my site and adding a catch statement so that if an exception is thrown, either through the tcl interpreter or or a postgresql query or action, I could catch it with a proc or page. Thanks, Vince
Re: [AOLSERVER] Error Handling / post-processing
+-- On Aug 22, Mark Hubbard said: Along the same lines, is there a way to capture all the output from an ADP in a buffer, and then alter it before it's transmitted? This would allow things that can't be done easily, or at all, in IIS/ASP. Register your own Tcl proc for /*.adp. Use ns_adp_parse to process the ADP, then alter the result as necessary, then ns_return the altered string.
Re: [AOLSERVER] Error Handling
We do this. Register a proc for /dir, put your TCL scripts there, in the /dir handler look at the URL suffix and do a TCL source command or ns_returnfile. (Put a catch around the source command - that's the important part). Jim Wow, that is a *great* idea. Then you could register an exception handler for a url path. If it's possible, it would probably have to be something set inside the Tcl interp that is running the ADP or Tcl code, before it starts running the code. Unfortunately I don't yet know enough about Tcl internals to know how to go about doing this, but it is well worth looking into. /s. Is there any way in AOLServer to register an exception handler? What I would like to avoid is going over all the pages in my site and adding a catch statement so that if an exception is thrown, either through the tcl interpreter or or a postgresql query or action, I could catch it with a proc or page. Thanks, Vince
Re: [AOLSERVER] Error Handling
At 12:33 PM 8/22/01, you wrote: We do this. Register a proc for /dir, put your TCL scripts there, in the /dir handler look at the URL suffix and do a TCL source command or ns_returnfile. (Put a catch around the source command - that's the important part). Jim I think an important thing to remember is what the suggestions from Jim, Rob allude to: there are already many paths within AOLserver (and even more if you include the ACS) for serving files. Within AOLserver, there are different paths for serving .tcl, .adp, and static files. You presumably don't need too much error handling around the static files, but I believe your .tcl and .adp files will have different solutions required for each. Plus, I don't believe the suggestions already mentioned will catch errors in registered filters. But! This is good stuff, so let me encourage you to continue! Jerry = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
Re: [AOLSERVER] Error Handling
Yes. We do virtual hosting this way. Register a proc for /, look at the Host: header and URL, then source/read the files from whatever directory you want. The downside is that you are invoking TCL on every request, which has some overhead. But we've been doing it for years, have 1M+ hits/day, and our server is mostly idle. You could also do the same thing with a C extension (and there is one already available somewhere...) We've found that using TCL is easier, safer, and has excellent performance characteristics. Jim Excellent. Could this technique also be used to, say, set your PageRoot based on the request URL, or maybe a Host header? Maybe not the real PageRoot could be set, but maybe a falsified or virtualized one? -- Mark Hubbard: [EMAIL PROTECTED] Microsoft Certified Professional Knowledge is Power. -Original Message- From: Jim Wilcoxson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, August 22, 2001 2:31 PM Subject: Re: Error Handling We do this. Register a proc for /dir, put your TCL scripts there, in the /dir handler look at the URL suffix and do a TCL source command or ns_returnfile. (Put a catch around the source command - that's the important part). Jim Wow, that is a *great* idea. Then you could register an exception handler for a url path. If it's possible, it would probably have to be something set inside the Tcl interp that is running the ADP or Tcl code, before it starts running the code. Unfortunately I don't yet know enough about Tcl internals to know how to go about doing this, but it is well worth looking into. /s. Is there any way in AOLServer to register an exception handler? What I would like to avoid is going over all the pages in my site and adding a catch statement so that if an exception is thrown, either through the tcl interpreter or or a postgresql query or action, I could catch it with a proc or page. Thanks, Vince
Re: [AOLSERVER] Error Handling
Yes! Thank you! That elusive bit of info will clear a major roadblock to adopting AOLS. I've been puzzling over why the nsvhr and those other modules are needed, if that can be done instead. I guess the C modules would be good for a REALLY high traffic site. But that wouldn't be us. I also agree with what Jerry said earlier. The many paths through the server, and the many hooks into its processing steps, are what make it attractive. More software should be like that. -- Mark Hubbard: [EMAIL PROTECTED] Microsoft Certified Professional Knowledge is Power. -Original Message- From: Jim Wilcoxson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, August 22, 2001 2:59 PM Subject: Re: Error Handling Yes. We do virtual hosting this way. Register a proc for /, look at the Host: header and URL, then source/read the files from whatever directory you want. The downside is that you are invoking TCL on every request, which has some overhead. But we've been doing it for years, have 1M+ hits/day, and our server is mostly idle. You could also do the same thing with a C extension (and there is one already available somewhere...) We've found that using TCL is easier, safer, and has excellent performance characteristics. Jim Excellent. Could this technique also be used to, say, set your PageRoot based on the request URL, or maybe a Host header? Maybe not the real PageRoot could be set, but maybe a falsified or virtualized one? -- Mark Hubbard: [EMAIL PROTECTED] Microsoft Certified Professional Knowledge is Power. -Original Message- From: Jim Wilcoxson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, August 22, 2001 2:31 PM Subject: Re: Error Handling We do this. Register a proc for /dir, put your TCL scripts there, in the /dir handler look at the URL suffix and do a TCL source command or ns_returnfile. (Put a catch around the source command - that's the important part). Jim Wow, that is a *great* idea. Then you could register an exception handler for a url path. If it's possible, it would probably have to be something set inside the Tcl interp that is running the ADP or Tcl code, before it starts running the code. Unfortunately I don't yet know enough about Tcl internals to know how to go about doing this, but it is well worth looking into. /s. Is there any way in AOLServer to register an exception handler? What I would like to avoid is going over all the pages in my site and adding a catch statement so that if an exception is thrown, either through the tcl interpreter or or a postgresql query or action, I could catch it with a proc or page. Thanks, Vince
Re: [AOLSERVER] Error Handling
At 01:21 PM 8/22/01, you wrote: Yes! Thank you! That elusive bit of info will clear a major roadblock to adopting AOLS. I've been puzzling over why the nsvhr and those other modules are needed, if that can be done instead. I guess the C modules would be good for a REALLY high traffic site. But that wouldn't be us. Regarding multiple paths as regards virtual hosting. I find both the simple Tcl and the C based virtual hosting techniques have their uses, it depends on what you are trying to do. nsvhr is really a port 80 multiplexer. It lets you seamlessly integrate all sorts of technology into your webservice, at the same time presenting these services to your client on port 80. That both looks nice as well as helps you get past firewalls. But what I really like about nsvhr is that if one aolserver site goes down (and they do at times) that it doesn't take any of your other sites down. This can happen do to AOLserver bugs that haven't been fixed that some one site exploits, or maybe because one site needs to use an as yet experimental module. I've found nsvhr itself to be very stable (modulo the bugs I occasionally put into it.) One shortcoming of AOLserver 3 (rectified in AOLserver 4) is that Tcl based AOLservers all share the same Tcl libraries. So if you want one site to use say library version 1 of TclFOO, and another site wants to use library version 2 of TclFOO, you can't do that. This can lead to site upgrade difficulties when you have lots of sites. If you want to be an ISP that offers thousands of sites that are mainly static pages, CGI, or use a fixed set of Tcl procs that you provide, then Tcl based virtual hosting is what you want. If you want to piece together a complex webservice than you may wish to use an nsvhr/apache/squid reverse proxying solution. Regarding speed, as Jim mention's he's had no problems with up to a million hits using Tcl procs. Recent testing of mine (http://www.theashergroup.com/tag/articles/reverse-proxies/vhr-benchmarks_files/connection-performance.adp) demonstrate that an nsvhr/nssock solution can handle more than 900,000 hits per hour (of a 2K file) (on linux) and about 2.5 million hits per day of nothing but 32K bytes files. Jerry = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
Re: [AOLSERVER] Error Handling
Thanks for the info. I'm reading your howto right now. Sounds like the C modules will be a good solution for later, after we really have lots of sites on AOLserver. For now I think the all-TCL register a proc on / solution will work, as long as we don't have trouble with AOLserver hanging, as I've done many times already using ns_sockopen. -- Mark Hubbard: [EMAIL PROTECTED] Microsoft Certified Professional Knowledge is Power. -Original Message- From: Jerry Asher [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, August 22, 2001 3:37 PM Subject: Re: Error Handling At 01:21 PM 8/22/01, you wrote: Yes! Thank you! That elusive bit of info will clear a major roadblock to adopting AOLS. I've been puzzling over why the nsvhr and those other modules are needed, if that can be done instead. I guess the C modules would be good for a REALLY high traffic site. But that wouldn't be us. Regarding multiple paths as regards virtual hosting. I find both the simple Tcl and the C based virtual hosting techniques have their uses, it depends on what you are trying to do. nsvhr is really a port 80 multiplexer. It lets you seamlessly integrate all sorts of technology into your webservice, at the same time presenting these services to your client on port 80. That both looks nice as well as helps you get past firewalls. But what I really like about nsvhr is that if one aolserver site goes down (and they do at times) that it doesn't take any of your other sites down. This can happen do to AOLserver bugs that haven't been fixed that some one site exploits, or maybe because one site needs to use an as yet experimental module. I've found nsvhr itself to be very stable (modulo the bugs I occasionally put into it.) One shortcoming of AOLserver 3 (rectified in AOLserver 4) is that Tcl based AOLservers all share the same Tcl libraries. So if you want one site to use say library version 1 of TclFOO, and another site wants to use library version 2 of TclFOO, you can't do that. This can lead to site upgrade difficulties when you have lots of sites. If you want to be an ISP that offers thousands of sites that are mainly static pages, CGI, or use a fixed set of Tcl procs that you provide, then Tcl based virtual hosting is what you want. If you want to piece together a complex webservice than you may wish to use an nsvhr/apache/squid reverse proxying solution. Regarding speed, as Jim mention's he's had no problems with up to a million hits using Tcl procs. Recent testing of mine (http://www.theashergroup.com/tag/articles/reverse-proxies/vhr-benchmarks_f iles/connection-performance.adp) demonstrate that an nsvhr/nssock solution can handle more than 900,000 hits per hour (of a 2K file) (on linux) and about 2.5 million hits per day of nothing but 32K bytes files. Jerry = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
Re: [AOLSERVER] Error Handling
In a message dated 8/22/01 2:55:07 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
Is there any way in AOLServer to register an exception handler? What I
would like to avoid is going over all the pages in my site and adding
a catch statement so that if an exception is thrown, either through the
tcl interpreter or or a postgresql query or action, I could catch it with a
proc or page.
You could also simply put a catch in your startpage around the include.
%
if {[catch {
ns_adp_include [ns_url2file [ns_conn url]]
} err]} {
ns_adp_puts An error occurred: $err
# or whatever else you wanna do with the error
}
%
-- michael
___
michael richman
sr. software engineer
aol local technology
214.954.6204
