Sorry, I guess I wasn't clear. That script runs on SERVERA just to do a lot of http requests on SERVERB and stops when SERVERB returns something of 0 size (less than 2 actually). Monitoring the aolserver/log/server.log file on SERVERA will show the progress of requests and monitoring the access.log file on SERVERB will show the progress of responces.
When a "bad" page is requested on SERVERB, the "bad" page processes normally and without any detected errors, however, upon exit seems to corrupt a thread which then causes "the problem" the next time a request is made and the thread needs to parse an adp. Since all of these so called "bad" pages I have found use a ns_returnredirect followed by a ns_adp_abort I assumed that that was the culprit, however, it seems that something else is required to cause the problem as well since it does not happen with all redirect/aborts, just with some, and always with the same ones. I haven't had time to look into it more since last night, but I plan on narrowing down the problem this evening once I have time. Currently the site in question with these bad pages is about 12 years old, version built on version and as you can no doubt imagine is now quite bloated and complex in some areas, so instead of posting 1000 lines of code which may contain an issue, I'll wait till I cannarrow it down a bit. _Peter Date: Mon, 6 Jul 2009 10:42:28 -0700 From: t...@rmadilo.com Subject: Re: [AOLSERVER] ns_adp_parse issue To: AOLSERVER@LISTSERV.AOL.COM Did I miss something? Your script below does not contain a redirect and does not contain ns_adp_abort. Why do you think this script tells you anything about your problem? But one thing seems apparent: this adp script should return nothing. It is just a script, it doesn't produce content. If no content is produced, then it is working. On Sun, Jul 5, 2009 at 10:32 PM, Francesco Petrarch <f_petra...@hotmail.com> wrote: Hummmm, on further testing I guess I was pretty much completely wrong.... I guess I spoke too soon..... I have tried to turn on all error logging but have come up with nothing. I am able to intentionally kill a thread, though I am not entirely sure how :S There are some pages I can request that will kill an additional ADP thread, at first I thought this was simply the ns_returnredirect or the ns_adp_abort but seems to be something else since I can't duplicate it with all redirects/aborts (although it does happen each time these specific pages are requested). For example, the profile.html page redirects to the login/signup page if you are not logged in and if it does so causes "the problem" Here is the latest..... I have a script at http://SERVERA/test .adp <% set count 0 while {$count<20000} { incr count set page [ns_httpget "http://SERVERB/file.html?count=$count";] ns_log notice "page $count size [string length $page]" if {[string length $page]<2} { break } } %> it basically requests a file 20000 times from SERVERB (which also hosts the aforementioned profile.html page) and stops if the file size is small. The file file.html contains just a single word "test". If .html is not in "ns_section ns/server/serverb/adp" then "the problem" does not happen, it only occurs when file.html may or may not need the parser. In the event that .html is not in the ns_section and is static, fastpath settings do not seem to make a difference, everything works. Now.... from my observations, it appears that when a file such as the aforementioned profile.html page is requested and the redirect happens, that thread becomes contaminated. The next time that contaminated thread is used for an adp "the problem" appears. It appears as though the ns_adp_abort value is still set and adps can not be parsed, even if the file.html file has no <% %> tags, if .html is set as a file to be parsed then an empty string is returned, however, just once. Once this thread is closed again it seems fixed for future requests. However, this "contamination" is only cleaned when the thread tries to serve/parse an adp, if it's serving static content the contamination is not removed. Going back to the filters I had originally I believe the request still comes in for the page with the adp, the filter can log info, but ns_adp_parse just returns an empty string. Anyways, I'll be digging further into this, trying to see what exactly is "contaminating" the thread as it appears now. To repeat, this "problem" is repeatable everytime profile.html is requested, and if it is related to ns_adp_abort or ns_adp_redirect there must be other variables to the problem since I can not seem to duplicate the problem with just those functions. Also I do not use ns_perms, I simply set a cookie once someone is logged in. I don't suppose there is a ns_adp_unabort _Peter Date: Sun, 5 Jul 2009 18:50:53 -0700 From: t...@rmadilo.com Subject: Re: [AOLSERVER] ns_adp_parse issue To: AOLSERVER@LISTSERV.AOL.COM On Sun, Jul 5, 2009 at 6:13 PM, Francesco Petrarch <f_petra...@hotmail.com> wrote: It's been awhile since I have looked into this and I think I have tracked it down. In short, I now believe that ns_adp_abort aborts all current threads/adps, not just the one currently executing the ns_adp_abort line. Therefore, when these "blank screens" were appearing on my site to VISITOR A it was because another visitor (VISITOR B) had visited a page which called ns_adp_abort (for example after a ns_returnredirect) before the VISITOR A thread finished. Does that make sense? Can someone with more experience in the code take a look and let me know? No, makes no sense. This is essentially impossible. Each thread executes pretty much independently of all others. The problem probably has to do with the adp configuration...error without signaling an error, which is a configuration which is necessary to keep complex sites up if one component is not working. tom jackson -- 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. Windows Live helps you keep up with all your friends, in one place. -- 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. _________________________________________________________________ We are your photos. Share us now with Windows Live Photos. http://go.microsoft.com/?linkid=9666047 -- 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.
