> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 04 February 2004 03:15 > To: Cactus Users List > Subject: RE: Browser/Web Server timeout when accessing ServletTestRunner > for long tests > > > > Vincent, > > Client side transformation is good enough for me and I am happy to keep > the > solution as simple as possible. > Unfortunately I have had a look at the returned XML and the <testsuite> > node > contains attributes e.g. failures, errors that will not be known until the > end > of the testing. This will prevent me, as far as I know, from streaming the > xml > down to the browser.
Argh! Good point, I hadn't thought of this... > > Perhaps I could set a dummy HTTP header variable after each test This won't work. HTTP headers must be set before you start sending response body. > (or send > some > other dummy data) just so the timeout does not occur. Not a nice solution, > I far > prefer streaming the actual data, but I am not sure it can actually be > done. I don't see a solution right now. Anyone has an idea? > > I am happy to provide a patch once we have sorted out a solution. Cool. Let's try to find a solution... :-) Thanks -Vincent > > Cheers Dave > > > > > "Vincent Massol" <[EMAIL PROTECTED]> > 04/02/2004 08:35 > From > On > > Please respond to "Cactus Users List" <[EMAIL PROTECTED]> > > To "'Cactus Users List'" <[EMAIL PROTECTED]> > cc (bcc: DSEARLE/R&SA/NZ) > > Subject RE: Browser/Web Server timeout when accessing ServletTestRunner > for > long tests > > > > Hi Dave, > > You're the first one to report this issue. Congrats! :-) > > It seems to me the only case where we have a real problem is when > performing server-side XSLT. If the returned data is XML or if the XSLT > transformation is done in the browser then we can easily implement your > solution 1 (i.e. send back data as soon as a test finishes). > > Would that be good enough for you? > > I'd rather do simple things than start playing with threads and > committed/uncommitted responses tricks... :-) > > If you agree on this, the next step would to provide a patch for it :-) > > Thanks > -Vincent > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: 03 February 2004 05:31 > > To: [EMAIL PROTECTED] > > Subject: Browser/Web Server timeout when accessing ServletTestRunner > for > > long tests > > > > > > > > We use cactus to test our internal application and it is called as > part of > > our > > build script which works well. We have also made use of the > > ServletTestRunner to > > access the test cases through a custom JSP on our applications > website. > > This > > allows us to run our tests from any browser at any time. However, when > we > > access > > a large test suite, it times out ("The page cannot be displayed") > because > > it > > takes a number of minutes to run all the tests. We could modify > timeout > > settings > > on both the server and the client (I believe in IE it is a reg edit) > but I > > would > > like to be able to call the tests from any browser so need a server > > solution. > > > > Has any one else come across this issue before? > > > > I can think of two solutions: > > > > 1 Send information to the browser while the tests are being run which > > would stop > > the timeout occurring. > > By modifying the Servlet Test Runner I could add another TestListener > that > > writes to the response as each test completes. > > > > 2 Modify Servlet Test Runner (or create a new runner) that can run in > a > > asynchronous mode. > > This would involve spawning a thread to run the actual test and > storing > > the > > TestResult somewhere (e.g. ServletContext) with an ID. > > The browser could then reload the page (automatically if required) > with an > > ID > > for the TestResult. My only concern with this approach is any > threading > > issues? > > > > Any thoughts most appreciated. > > > > Cheers Dave > > > > > > > > > > > > ********************************************************************** > > CAUTION - This message is intended for the addressee named above. It > > may contain privileged or confidential information. If you are not the > > intended recipient of this message you must not use, copy, distribute > > or disclose it to anyone. > > ********************************************************************** > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ************************************************************************ ** > ** > The following message has been automatically added by the Internet mail > gateway to comply with a Promina Group Services Limited IT Security > requirement. > > "This e-mail has arrived via the Internet and, therefore you should be > cautious about its origin and content. Replies which contain sensitive > information or legal/contractual obligations are particularly vulnerable. > In these cases you should not reply unless you are authorised to do so, > and adequate encryption is employed." > > If you have any questions, please contact [EMAIL PROTECTED] > or the Helpdesk on 09 357 2383 > ************************************************************************ ** > ** > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
