You are viewing a plain text version of this content. The canonical link for it is here.
Posted to websh-user@tcl.apache.org by David McTavish <dm...@sandvine.com> on 2006/02/08 16:16:59 UTC

flush or blocking web::put

Hi all,

I was wondering if anybody had any information on how to block on calls
of web::put until the client receives all of the content, OR, conversely
to flush the socket, OR, to detect if all web::put's have been received
by the client over the socket.

I'm having problems with websh & my application using large amounts of
memory which are never reclaimed by apache, so in an effort to reduce
the overhead of the process, I'd like to kill the socket. I initially
attempted to do this by using the retire method of the websh
interpreter, however, that does not seem to reclaim any memory
whatsoever (running apache 1.3 on freebsd 5).

code in question:

    web::finalizer \
    {
        if {[getApacheMemoryUtilization] > 100000} \
        {
            #make this interpreter retire, it's memory is too high
            web::interpcfg retire true
            itcl::delete object [SingletonFactory::instance]
        }
    }

since this wasn't doing anything, i decided to just kill the child
process and force a new one to start, ie:

    web::finalizer \
    {
        if {[getApacheMemoryUtilization] > 100000} \
        {
            #make this interpreter retire, it's memory is too high
            web::interpcfg retire true
            itcl::delete object [SingletonFactory::instance]
            exec kill -9 [pid]
        }
    }

however, this has the awkward behaviour of truncating hte html received
by the client. i dont want to add sleeps into the code for various
amounts of time, as this code is in place at sites with large amounts of
latency, so determining the amount of time to sleep is difficult at
best. is there a way to determine whether the current websh socket is
flushed of data?

thanks,
d.

---------------------------------------------------------------------
To unsubscribe, e-mail: websh-user-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-user-help@tcl.apache.org


Re: flush or blocking web::put

Posted by Ronnie Brunner <ro...@netcetera.ch>.
Hi David

> I was wondering if anybody had any information on how to block on calls
> of web::put until the client receives all of the content, OR, conversely
> to flush the socket, OR, to detect if all web::put's have been received
> by the client over the socket.

I don't think you can find out if the client has all data (as there
can be proxies around etc.) But what might help is trying to flush the
output. As long as you don't use variables to write to (e.g. by
[web::response -select #varname]) you should be able to flush the
current default channel using 

	flush [web::response]

This flushes the Tcl channel to Apache (in your case) or Stdout in CGI
and shell mode.

> I'm having problems with websh & my application using large amounts of
> memory which are never reclaimed by apache, so in an effort to reduce
> the overhead of the process, I'd like to kill the socket. I initially
> attempted to do this by using the retire method of the websh
> interpreter, however, that does not seem to reclaim any memory
> whatsoever (running apache 1.3 on freebsd 5).

The code in web::finalizer is only called when the interpreter is
retired anyway (just before Tcl_DeleteInterp() is called) -> Your
attempt to retire the interp does not help.

As for the memory: Tcl has its own memory allocation/freeing
mechanism. If I'm not mistaken, Tcl allocates memory in chunks and
uses this for multiple internal "allocs". When freeing it also just
keeps track of what's used and whatnot -> even if you delete objects
and variables and whatever, it does not mean that there is actually any
memory freed (I think). Imho this has nothing to do with Websh but
with Tcl. (That helps doesn't it ;-)

> since this wasn't doing anything, i decided to just kill the child
> process and force a new one to start, ie:
...
> however, this has the awkward behaviour of truncating hte html received
> by the client. i dont want to add sleeps into the code for various
> amounts of time, as this code is in place at sites with large amounts of
> latency, so determining the amount of time to sleep is difficult at
> best. is there a way to determine whether the current websh socket is
> flushed of data?

As mentioned above: try flush [web::response] but no guarantee. Apache
might as well just buffer the output and still truncate it if the
process dies...

hth
Ronnie
--
Ronnie Brunner | ronnie.brunner@netcetera.ch
phone +41 (0)44 247 79 79 | fax +41 (0)44 247 70 75
Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: websh-user-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-user-help@tcl.apache.org