[
https://issues.apache.org/jira/browse/JENA-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636266#comment-13636266
]
Claude Warren commented on JENA-440:
------------------------------------
If no timeout is specified then infinity is the default. If we assume that
specificity changes the default then N should be equivalent to (N,infinity)
The last project I worked on we wanted to ensure that the remote end would
respond when using SERVICE calls. So we were looking for a connection timeout
on the call. If we connected we wanted the data, but had no idea how much data
there was. Thus I think I implemented the timeout as CONNECTION, SO. Thus if
the remote went away we could continue on with the remaining SERVICE calls (in
our case were were UNIONing the results so partial were acceptable). Perhaps
we need to take a step back and look at how the timeouts are used and then
figure out how to handle all the cases.
I see the case for :
1. a connection timeout (CONNECTION_TIMEOUT)
2. an inter result timeout (SO_TIMEOUT)
3. a maximum time limit. (M in your discussion)
> Query timeout does not always correctly move to the second query timeout
> after first row yielded
> ------------------------------------------------------------------------------------------------
>
> Key: JENA-440
> URL: https://issues.apache.org/jira/browse/JENA-440
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 2.10.0
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
