Home > Archive > Tcl > January 2008 > Web Services for Tcl & timeouts...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Web Services for Tcl & timeouts...
|
|
| Georgios Petasis 2008-01-21, 7:35 pm |
| Hi all,
I am using the web services for tcl package (the one from
http://code.google.com/p/tclws/ - although not the latest version),
which implements web services using the tclhttpd as its web browser.
So, using this package I have implemented a service. The problem is that
if the proc that implements the service takes some time to finish, a
timeout error is returned by my service. Is there a way to eliminate
these timeouts? I have definitely concluded that my server is causing
them, as I get the timeouts with clients in two programming languages.
A typical error message (from C# client) is:
The underlying connection was closed: A connection that was expected to
be kept alive was closed by the server.
My setup is that tclhttpd runs on a thread of its own, and the proc that
implements the service runs at a second thread.
Any ideas on how to stop timeout errors?
George
| |
| tom.rmadilo 2008-01-21, 7:35 pm |
| On Jan 21, 1:52 pm, Georgios Petasis <peta...@iit.demokritos.gr>
wrote:
> A typical error message (from C# client) is:
> The underlying connection was closed: A connection that was expected to
> be kept alive was closed by the server.
But this doesn't sound like a timeout error. Usually that would be a
client timing out, not the server.
But how long does it take to 'timeout'?
| |
| George Petasis 2008-01-22, 4:40 am |
| O/H tom.rmadilo _γραψε:
> On Jan 21, 1:52 pm, Georgios Petasis <peta...@iit.demokritos.gr>
> wrote:
>
>
> But this doesn't sound like a timeout error. Usually that would be a
> client timing out, not the server.
>
> But how long does it take to 'timeout'?
About several minutes. But it is the server that closes the connection,
and hapens after some time consuming applications.
George
| |
| George Peter Staplin 2008-01-22, 4:40 am |
| George Petasis wrote:
> O/H tom.rmadilo _γραψε:
>
> About several minutes. But it is the server that closes the connection,
> and hapens after some time consuming applications.
>
> George
If it's a default tclhttpd then according to the sources, the timeout
is:
# timeout1: Time before the server closes a kept-alive socket (msecs)
array set Httpd {
timeout1 120000
timeout2 120000
timeout3 2000
...
}
(from lib/httpd.tcl)
So that's 120 seconds. I guess you could extend the timeout, but it's
probably there for some good reason. Maybe you could send a sort of
ping and pong message back and forth to keep the connection alive.
George
| |
| George Petasis 2008-01-22, 8:28 am |
| O/H George Peter Staplin _γραψε:
> George Petasis wrote:
>
>
> If it's a default tclhttpd then according to the sources, the timeout
> is:
>
> # timeout1: Time before the server closes a kept-alive socket (msecs)
>
> array set Httpd {
> timeout1 120000
> timeout2 120000
> timeout3 2000
> ...
> }
>
> (from lib/httpd.tcl)
>
> So that's 120 seconds. I guess you could extend the timeout, but it's
> probably there for some good reason. Maybe you could send a sort of
> ping and pong message back and forth to keep the connection alive.
>
>
> George
Thanks for the info. Yes, I am using default httpd. The problem is that
I am not managing the transaction, but the webservices package does.
And I am not sure how can I ping/pong messages to keep it alive :-)
I think that in web services, the connections do not timeout. For
example, a gSoap server never times out, no matter how lengthy the
calculations are. But my tcl server (through tclhttpd) does.
Is there to apply a different timeout only for the web service?
George
| |
| George Petasis 2008-01-22, 8:28 am |
| Changing the timeouts, does not work.
What I did is to start tclhttpd normaly, and change the timeouts from
inside the proc that does the lengthy process. The variable changes,
but the timeout still happens :-(
George
O/H George Petasis _γραψε:
> O/H George Peter Staplin _γραψε:
>
> Thanks for the info. Yes, I am using default httpd. The problem is that
> I am not managing the transaction, but the webservices package does.
> And I am not sure how can I ping/pong messages to keep it alive :-)
> I think that in web services, the connections do not timeout. For
> example, a gSoap server never times out, no matter how lengthy the
> calculations are. But my tcl server (through tclhttpd) does.
> Is there to apply a different timeout only for the web service?
>
> George
| |
| Gerald W. Lester 2008-01-22, 7:36 pm |
| George Petasis wrote:
> Changing the timeouts, does not work.
> What I did is to start tclhttpd normaly, and change the timeouts from=20
> inside the proc that does the lengthy process. The variable changes,=20
> but the timeout still happens :-(
I believe that you need to change the timeout in the main thread, not you=
r=20
worker thread. I'd suggest setting it to the value you want in the per=20
thread initialization file (the rc file).
The problem you are seeing is not something that should be addressed at t=
he=20
web services layer, but rather at the application server (tclhttpd) layer=
=2E
BTW, some terminology errors in you original post, tclhttpd is the web=20
server not the web browser. Web browsers are things like Firefox, IE,=20
Opera, ...
[color=darkred]
>=20
> George
>=20
> O/H George Petasis =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
=CB=86=C3=8E=C2=B5:[color=darkred]
a[color=darkred]
=20[color=darkred]
es.[color=darkred]
--=20
+--------------------------------+---------------------------------------=
+
| Gerald W. Lester =
|
|"The man who fights for his ideals is the man who is alive." - Cervantes=
|
+------------------------------------------------------------------------=
+
| |
| tom.rmadilo 2008-01-22, 7:36 pm |
| On Jan 22, 2:28 am, George Peter Staplin
<georgepsSPAMME...@xmission.com> wrote:
> array set Httpd {
> timeout1 120000
> timeout2 120000
> timeout3 2000
> ...
> }
That is really dumb, why would an HTTP server timeout after it has
received all information from the client?
My guess is that you have an event based setup when you need a process
or thread based one. HTTP is not an event based protocol.
Anyway, if tclhttpd were to push the channel to a worker thread, can
the main thread still close the connection? But for a server to close
a connection like this is a bug. It shouldn't happen.
| |
| Georgios Petasis 2008-01-23, 4:36 am |
| O/H Gerald W. Lester _γραψε:
> George Petasis wrote:
>
> I believe that you need to change the timeout in the main thread, not
> your worker thread. I'd suggest setting it to the value you want in the
> per thread initialization file (the rc file).
>
>
> The problem you are seeing is not something that should be addressed at
> the web services layer, but rather at the application server (tclhttpd)
> layer.
>
> BTW, some terminology errors in you original post, tclhttpd is the web
> server not the web browser. Web browsers are things like Firefox, IE,
> Opera, ...
>
>
I don't have a main and a worker thread. Just a thread the web server
runs and a thread that the processing is done. I changed the timeout
in the thread that the server is ran, after I source the tclhttpd main
startup script (so as not to modify tclhttpd server sources).
But again I got the timeout in 120 sec.
And sorry for writing web browser instead of server :-)
George
[color=darkred]
>
>
| |
| Gerald W. Lester 2008-01-23, 7:25 pm |
| Georgios Petasis wrote:
> O/H Gerald W. Lester =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
=20[color=darkred]
=20[color=darkred]
[color=darkred]
=20[color=darkred]
=20[color=darkred]
>=20
> I don't have a main and a worker thread. Just a thread the web server=20
> runs and a thread that the processing is done. I changed the timeout
> in the thread that the server is ran, after I source the tclhttpd main =
> startup script (so as not to modify tclhttpd server sources).
> But again I got the timeout in 120 sec.
How do you hand off work from the main to the worker thread and receive w=
ork=20
back?
How do you wait for the work to be done in the main thread?
--=20
+--------------------------------+---------------------------------------=
+
| Gerald W. Lester =
|
|"The man who fights for his ideals is the man who is alive." - Cervantes=
|
+------------------------------------------------------------------------=
+
| |
| George Petasis 2008-01-23, 7:25 pm |
| O/H Gerald W. Lester _γραψε:
> Georgios Petasis wrote:
>
> How do you hand off work from the main to the worker thread and receive
> work back?
>
> How do you wait for the work to be done in the main thread?
>
I am using the thread package. The steps are:
1) The thread that runs tclhttpd (and is the web service server)
receives a request.
2) It executes the following:
ELEP_eval_async_result_variable ::SOME-GLOBAL-VARIABLE(result) \
proc_to_execute_in_the_other_thread arg1 ... argN
vwait ::SOME-GLOBAL-VARIABLE(result)
The body of the proc is:
proc ELEP_eval_async_result_variable {var args} {
thread::send -async $::ThreadId $args $var
}
and ThreadId is the id of the other thread, where processing is performed.
George
| |
| Gerald W. Lester 2008-01-23, 7:25 pm |
| George,
While what you have should work for a low volume service (i.e. where one =
call does not come in on top of the other, I really need to look at addin=
g=20
an asynch procedure definition to the package. The current interface was =
designed for synchronous calls, not asynchronous. I'll add this to the 1=
=2E10=20
release goals.
As a stop gap, you may want to see if turning on threading in TclHttpd an=
d=20
doing all the work directly in your procedure helps.
George Petasis wrote:
> O/H Gerald W. Lester =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
d[color=darkred]
r[color=darkred]
[color=darkred]
>
> I am using the thread package. The steps are:
>
> 1) The thread that runs tclhttpd (and is the web service server)
> receives a request.
>
> 2) It executes the following:
> ELEP_eval_async_result_variable ::SOME-GLOBAL-VARIABLE(result) \
> proc_to_execute_in_the_other_thread arg1 ... argN
> vwait ::SOME-GLOBAL-VARIABLE(result)
>
> The body of the proc is:
> proc ELEP_eval_async_result_variable {var args} {
> thread::send -async $::ThreadId $args $var
> }
>
> and ThreadId is the id of the other thread, where processing is perfor=
med.
>
> George
--=20
+--------------------------------+---------------------------------------=
+
| Gerald W. Lester =
|
|"The man who fights for his ideals is the man who is alive." - Cervantes=
|
+------------------------------------------------------------------------=
+
| |
| George Petasis 2008-01-23, 7:25 pm |
| Dear Gerald,
No, its not that. All the calls to the service are synchronous, i.e I
will never have a requsest before the previous one has returned.
And if this happens (an incoming call), I return immediately an error
saying the server is busy...
But if you are going to llok at the code again, I need to know that I am
not using the latest version but the previous one, as I couldn't get the
last one to work with my WSDL files...
(I am using the previous version along with the fixes we had discussed
for supporting C# clients/servers...)
Best regards,
George
O/H Gerald W. Lester _γραψε:
> George,
>
> While what you have should work for a low volume service (i.e. where one
> call does not come in on top of the other, I really need to look at
> adding an asynch procedure definition to the package. The current
> interface was designed for synchronous calls, not asynchronous. I'll
> add this to the 1.10 release goals.
>
> As a stop gap, you may want to see if turning on threading in TclHttpd
> and doing all the work directly in your procedure helps.
>
> George Petasis wrote:
> performed.
>
>
| |
| tom.rmadilo 2008-01-23, 7:25 pm |
| On Jan 23, 7:44 am, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
> George,
>
> While what you have should work for a low volume service (i.e. where one
> call does not come in on top of the other, I really need to look at adding
> an asynch procedure definition to the package. The current interface was
> designed for synchronous calls, not asynchronous. I'll add this to the 1.10
> release goals.
>
> As a stop gap, you may want to see if turning on threading in TclHttpd and
> doing all the work directly in your procedure helps.
So if he is doing a thread::send, is this distinct from threads in
TclHttpd? I admit I know nothing about TclHttpd, but the thread::send
stuff I just had to deal with. There were more steps than shown here,
for instance:
# listen (probably done by TclHttpd)
socket -server ::ThreadServer::_IdleAccept -myaddr $address $port
set forever 1
vwait forever
_IdleAccept does this:
after idle [list ::ThreadServer::Accept $channel $clientAddress
$clientPort]
And Accept does an extra step (thread::transfer):
proc ::ThreadServer::Accept {
channel
clientAddress
clientPort
} {
variable threadIt
variable threads
variable threadIds
set index [expr [incr threadIt] % $threads]
set thread_id [lindex $threadIds $index]
puts stderr "::ThreadServer::Accept channel '$channel' to thread
'$thread_id'"
thread::transfer $thread_id $channel
thread::send -async $thread_id [list wsdl_server $channel
$clientAddress $clientPort]
}
I remember several mistakes I made during development caused the
server to just sit there and never respond (accept, then stall out).
This sounds similar to what is happening here, with the addition that
TclHttpd apparently closes the server side of the connection after a
timeout.
Gerald,
What does async mean in this context? Does that simply mean handling
multiple clients in one thread, where each connection appears to be
synchronous?
|
|
|
|
|