Re: [tclwebtest] Non blocking http requests

[Grzegorz A. H. <gr...@ef...>]

On Wed, Mar 05, 2003 at 05:30:54AM +0000, Tilmann Singer wrote:
> I don't know how callback would help in this case as that would
> mean that you want the same instantiation of tclwebtest (e.g. a
> set of initialised global variables etc.) to do several requests in
> parallel, right? So when the callback fires tclwebtest should know
> which currently running set of global variables to associate that
> with - this is totally impossible with the current architecture.

At the moment I'm not doing anything special to create two instances
of tclwebtest, the server seems intelligent enough to create two
separate threads each with it's set of variables, which might happen
because at the moment I reload the complete tclwebtest script for
each run or because aolserver by default creates a separate memory
space for each thread (a logical behaviour after all: if two users
request the same dynamic page, the requests shouldn't share the
same memory space). It looks like the problem is opening an http
connection, it seems to freeze the whole server. My boss said that's
because the geturl command might open the socket in blocking mode,
and this could block the whole process.

I verified this launching two test units concurrently, one against
the local server and another one against a slow external one. Then
I tried to connect with a browser to the local server (which runs
tclwebtest inside aolserver), and the request was frozen: after
several seconds the html code appeared, some more later one image,
and so on for the rest of the images. From my limited point of view
this means that the unit tests are waiting for the external query
to finish, and meanwhile other threads of the server are unable to
progress. The slow one by one appearing of images suggests that after
each geturl command the other threads get a little CPU time only
to get blocked again by the next scheduled blocking geturl command.

My supposition was that running geturl with the callback option
would open the socket in non-blocking mode, and thus the rest of
the threads wouldn't be blocked, I would separate do_request in
two parts and simulate the sequencial behaviour. Therefore each
tclwebtest instance would still be able to run along others and
open any number of separate sockets.

It's not a requested feature yet, I was just asking. If I have to
solve this problem in the future I will try this callback approach
first and get back to you with the results.

-- 
 Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89.
 eFaber SL, Maria Diaz de Haro, 68, 2         http://www.efaber.net/
 48920 Portugalete, Bizkaia (SPAIN)