You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Eddie Epstein <ed...@aewatercolors.com> on 2006/12/11 17:29:24 UTC

Re: Does Vinci Service-side Timeout make sense, or should it be removed?

>
> Does this timeout even make sense?  We have a client-side timeout
> where the client indicates how long they are willing to wait for a
> response.  Why should the service get to decide how long the client
> should wait?
>
> Opinions?
>
> -Adam
>

A server-side timeout is an optimization that allows a client to submit a
new request without opening a new socket connection. The recent change
allowing customization of this parameter in order to extend the timeout
well beyond the 1 minute default was added to work around client problems
reopening the connection which were never resolved for international
connectivity.

Eddie

Re: Does Vinci Service-side Timeout make sense, or should it be removed?

Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Eddie Epstein <ed...@aewatercolors.com> wrote:
> Sounds good. Maybe we should add a JIRA issue to remove any other code
> hanging around that doesn't work?
>

:)  That only works if the feature that doesn't work *is also
ill-conceived*...  an important qualification. :)

-Adam

Re: Does Vinci Service-side Timeout make sense, or should it be removed?

Posted by Eddie Epstein <ed...@aewatercolors.com>.
> For now I'll just yank out the last
> vestiges of the server-side timeout that doesn't work now anyway.
> What do you think?
>
> -Adam
>

Sounds good. Maybe we should add a JIRA issue to remove any other code
hanging around that doesn't work?

Eddie

Re: Does Vinci Service-side Timeout make sense, or should it be removed?

Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Eddie Epstein <ed...@aewatercolors.com> wrote:
> The server rejecting a request after this timeout does not make sense to
> me, as the client should decide how long to wait. On the other hand,
> services that require lots of processing per request may not want to start
> processing "long-delayed" requests if there is a good chance the client
> may have already timed it out.
>

Maybe, the client could send the timeout value as part of the request,
and the server could use that as its timeout on acquiring an AE pool.

But I'm not sure this is worth tackling right now.  We can add that to
JIRA as a possible new feature.  For now I'll just yank out the last
vestiges of the server-side timeout that doesn't work now anyway.
What do you think?

-Adam

Re: Does Vinci Service-side Timeout make sense, or should it be removed?

Posted by Eddie Epstein <ed...@aewatercolors.com>.
> I was referring to the "timeoutPeriod" value in the deployment
> descriptor, which as the JIRA issue says is currently not even
> implemented for Vinci.
Are you implying that people should read the JIRA issue before commenting?

> The idea of this timeout was that if a request
> came in but the service was busy processing other requests such that
> there was no AE instance available, the service would wait for at most
> the specified timeoutPeriod for an AE instance to be come free.  If
> the timeout elapsed the service would report an error.  This is the
> functionality I'm questioning.  It does not seem to make a whole lot
> of sense to me.
The server rejecting a request after this timeout does not make sense to
me, as the client should decide how long to wait. On the other hand,
services that require lots of processing per request may not want to start
processing "long-delayed" requests if there is a good chance the client
may have already timed it out.

Eddie

Re: Does Vinci Service-side Timeout make sense, or should it be removed?

Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Eddie Epstein <ed...@aewatercolors.com> wrote:
> A server-side timeout is an optimization that allows a client to submit a
> new request without opening a new socket connection. The recent change
> allowing customization of this parameter in order to extend the timeout
> well beyond the 1 minute default was added to work around client problems
> reopening the connection which were never resolved for international
> connectivity.
>

I was referring to a different kind of timeout.  You are talking about
the "serverSocketTimeout" parameter, which was added relatively
recently and I agree we should keep.

I was referring to the "timeoutPeriod" value in the deployment
descriptor, which as the JIRA issue says is currently not even
implemented for Vinci.  The idea of this timeout was that if a request
came in but the service was busy processing other requests such that
there was no AE instance available, the service would wait for at most
the specified timeoutPeriod for an AE instance to be come free.  If
the timeout elapsed the service would report an error.  This is the
functionality I'm questioning.  It does not seem to make a whole lot
of sense to me.

-Adam