Re: Read Timeout (again)

[Jess Sightler <js...@eximtechnologies.com>]

I'm a non-committer :), but +1 to the idea of being able to globally
configure this outside of coding to the API.

Thanks,
Jess


On Fri, 2003-07-18 at 11:15, Erik_Vanherck@inventivedesigners.com wrote:
> Hi,
> 
> I'm a relatively new Axis user so the read timeout discussion a few
> days ago passed by me, without giving it much attention. However by
> now I have a full client - server system up and running. Unfortunately
> in some instances our server may require a long time to generate the
> result requested, especially on initial startup. So the read timeout
> pops up. No biggy, let's set the timeout value on the Stub and be done
> with it. I read the discussion and I understand perfectly all the
> views expressed in it. However I'd like to add something to this
> discussion and explain why I believe the timeout should either be 0 or
> configurable in an external "configuration". 
> 
> Axis is an implementation of among other packages the standardized
> javax.xml.rpc classes. As a programmer working with external libraries
> I have little control over (or time to invest in), I tend to shield
> myself as much as I can from implementation dependent API's. So I use
> the standard API's , just like I do with xerces and xalan. However to
> control the timeout I would have to cast my javax.xml.rpc.Call
> instance to org.apache.axis.client.Call (As far as I know, if'm wrong
> then by all means correct me and forget about the rest of this comment
> ;-p). This is ugly, dirty code that can easily break if I switch
> implementation but still leave the axis.jar somewhere in the classpath
> of the IDE. It will cause a runtime class cast exception.
> 
> At first I thought, this is a blatant omission in the standard API,
> and if someone on the axis developers group is part of the relevant
> JCP's they should suggest an enhancement. But then again is the
> standard API specifically designed for HTTP ? I can imagine a
> transport where a timeout doesn't make much sense, maybe this should
> be set on the transport configuration somehow.
> 
> ---------
> 
> Erik Vanherck  -  System Programmer & Designer
> Inventive Designers 
> Visit http://www.inventivedesigners.com
> Visist http://www.inventivedesigners.com/scriptura for Scriptura
> information !
> 
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Erik_Vanherck@inventivedesigners.com
> 
> "Computers in the future may weigh no more than 1.5 tons." - Popular
> Mechanics, forecasting the relentless march of science, 1949  
-- 
=======================================
Jess Sightler
Senior Developer
Exim Technologies
131 Falls Street
Greenville SC 29601
Phone: 864-679-4651
=======================================