Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <8515878.1163481637640.JavaMail.jira@brutus>
Date: Mon, 13 Nov 2006 21:20:37 -0800 (PST)
From: "nadir amra (JIRA)" <axis-c-dev@ws.apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Updated: (AXISCPP-526) Response timeouts in addition to
 connection timeouts
In-Reply-To: <1231960390.1110406854449.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/AXISCPP-526?page=all ]

nadir amra updated AXISCPP-526:
-------------------------------

    Description: 
It would be highly useful to be able to specify an independent response timeout in addition to the connection timeout currently specifiable.

The following e-mail chain records a discussion from the user list about this:

> 
> Tim Bartley <tbartley@au1.ibm.com> 
> 24/02/2005 23:34 
> Subject
> 
> Re: Connection timeout vs response timeout?
> 
> 
> 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

> 
> Samisa Abeysinghe <samisa.abeysinghe@gmail.com> 
> 24/02/2005 21:15 
> 
> Subject
> 
> Re: Connection timeout vs response timeout?
> 
> 
> 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 <hawkinsj@uk.ibm.com> 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 <samisa.abeysinghe@gmail.com> 
> > 
> > 24/02/2005 01:35 
> > 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 <tbartley@au1.ibm.com>
> > 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 responsetimeout -
> > > 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
> > >  --

  was:
It would be highly useful to be able to specify an independent response timeout in addition to the connection timeout currently specifiable.

The following e-mail chain records a discussion from the user list about this:

> 
> Tim Bartley <tbartley@au1.ibm.com> 
> 24/02/2005 23:34 
> 
> Please respond to
> "Apache AXIS C User List"
> 
> To
> 
> "Apache AXIS C User List" <axis-c-user@ws.apache.org> 
> 
> cc
> 
> Subject
> 
> Re: Connection timeout vs response timeout?
> 
> 
> 
> 
> 
> 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 <samisa.abeysinghe@gmail.com> 
> 24/02/2005 21:15 
> 
> Please respond to
> "Apache AXIS C User List"
> 
> To
> 
> Apache AXIS C User List <axis-c-user@ws.apache.org> 
> 
> cc
> 
> Subject
> 
> Re: Connection timeout vs response timeout?
> 
> 

> 
> 
> 
> 
> 
> 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 <hawkinsj@uk.ibm.com> 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 <samisa.abeysinghe@gmail.com> 
> > 
> > 24/02/2005 01:35 
> > Please respond to
> > "Apache AXIS C User List"
> > ToApache AXIS C User List <axis-c-user@ws.apache.org> 
> > 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 <tbartley@au1.ibm.com>
> > 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 responsetimeout -
> > > 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
> > 
> >


Just consolidating JIRA's.  AXISCPP-745 is basically a duplicate of this one.  Adding the following comment from that issue:

Non-blocking should be tied to a timeout value that the client would set. Thus, if a timeout value was not set, then blocking I/O would be done; otherwise, non-blocking with the use of select()/poll().

> Response timeouts in addition to connection timeouts
> ----------------------------------------------------
>
>                 Key: AXISCPP-526
>                 URL: http://issues.apache.org/jira/browse/AXISCPP-526
>             Project: Axis-C++
>          Issue Type: Improvement
>          Components: Transport (Client)
>    Affects Versions: current (nightly)
>            Reporter: Tim Bartley
>
> It would be highly useful to be able to specify an independent response timeout in addition to the connection timeout currently specifiable.
> The following e-mail chain records a discussion from the user list about this:
> > 
> > Tim Bartley <tbartley@au1.ibm.com> 
> > 24/02/2005 23:34 
> > Subject
> > 
> > Re: Connection timeout vs response timeout?
> > 
> > 
> > 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
> > 
> > Samisa Abeysinghe <samisa.abeysinghe@gmail.com> 
> > 24/02/2005 21:15 
> > 
> > Subject
> > 
> > Re: Connection timeout vs response timeout?
> > 
> > 
> > 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 <hawkinsj@uk.ibm.com> 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 <samisa.abeysinghe@gmail.com> 
> > > 
> > > 24/02/2005 01:35 
> > > 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 <tbartley@au1.ibm.com>
> > > 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 responsetimeout -
> > > > 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
> > > >  --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org