Can you create JIRA for this so we don't lose it?
| Tim Bartley <[EMAIL PROTECTED]>
24/02/2005 23:34
|
|
Right and I would see a response timeout as applying between each chunk as well as before the first chunk. Now there may be some strange applications that try and stream data in a slow response e.g. send one array element every minute as a stock ticker, I've seen horrible HTTP apps like that but they're the very sparse exception rather than the rule.
Regards,
Tim
--
IBM Tivoli Access Manager Development
Gold Coast Development Lab, Australia
+61-7-5552-4001 phone
+61-7-5571-0420 fax
| Samisa Abeysinghe <[EMAIL PROTECTED]>
24/02/2005 21:15
|
|
As per the pull model used in Axis C++, it starts parsing the message
as soon as some part of the message is received. Hence it would make
more sense to time out on first byte arrival.
However, if a message is partially dealt with the pull parser, and the
other part does not arrive (or too late), there has to be mechanisms
to deal with that as well.
Samisa...
On Thu, 24 Feb 2005 10:00:36 +0000, John Hawkins <[EMAIL PROTECTED]> wrote:
>
> What do exactly do we mean by response timeout - is it the time before the
> first byte comes back across the wire? Or the time for the whole msg to get
> back ?
>
>
>
>
> Samisa Abeysinghe <[EMAIL PROTECTED]>
>
> 24/02/2005 01:35
> Please respond to
> "Apache AXIS C User List"
> ToApache AXIS C User List <[email protected]>
> cc
> SubjectRe: Connection timeout vs response timeout?
>
>
>
>
>
>
>
>
> Hi Tim,
> As of now, we have only the concept of connection timeout.
> It is not defined what would happen if a response gets delayed.
> Sounds to me it is a good idea to look into this.
>
> Thanks,
> Samisa...
>
>
> On Thu, 24 Feb 2005 10:08:50 +1000, Tim Bartley <[EMAIL PROTECTED]>
> wrote:
> >
> > Hi,
> >
> > On the client side, are connection timeouts able to be controlled
> > indpendently of response timeouts?
> >
> > I commonly want a short connection timeout but a longer response timeout -
> > if connection is going to fail I want to know quickly and failover but I'm
> > happy to wait sufficient time for the response to actually be generated.
> >
> > Thanks,
> >
> > Tim
> > --
> > IBM Tivoli Access Manager Development
> > Gold Coast Development Lab, Australia
> > +61-7-5552-4001 phone
> > +61-7-5571-0420 fax
>
>
