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 <[email protected]>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: [email protected] > Subject: Re: [AOLSERVER] ns_adp_parse issue > To: [email protected] > > > > On Sun, Jul 5, 2009 at 6:13 PM, Francesco Petrarch <[email protected] > > 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 > <[email protected]> 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.<http://go.microsoft.com/?linkid=9660824> > > > -- > 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.
