[
https://issues.apache.org/jira/browse/UIMA-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-139:
--------------------------------------------
Labels: Stale (was: )
This issue is marked as "stale" due to inactivity for 5 years or longer. If no
further activity is detected on this issue, it is scheduled be closed as
'unresolved' in 3 months time from now (Dec 2016).
> Client could send timeout value along with request, to save service from
> unnecessary work
> -----------------------------------------------------------------------------------------
>
> Key: UIMA-139
> URL: https://issues.apache.org/jira/browse/UIMA-139
> Project: UIMA
> Issue Type: Wish
> Components: Transport Adapters - SOAP, Vinci
> Reporter: Adam Lally
> Priority: Minor
> Labels: Stale
>
> On 12/11/06, Eddie Epstein <[email protected]> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
