[jira] Commented: (COUCHDB-246) allow customization of external process timeout

2009-02-11 Thread Chris Anderson (JIRA)

[ 
https://issues.apache.org/jira/browse/COUCHDB-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672727#action_12672727
 ] 

Chris Anderson commented on COUCHDB-246:


Curently, sending log() responses occasionally is all it takes to prevent a 
time out. I'm not suggesting that we don't need a special keep-alive 
intermediate response, just that it should be fairly trivial to crib from what 
the log case does, and, if you can't wait for the patch, you can use log() as a 
stand in.

> allow customization of external process timeout
> ---
>
> Key: COUCHDB-246
> URL: https://issues.apache.org/jira/browse/COUCHDB-246
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 0.9
>Reporter: Robert Newson
>Priority: Blocker
> Fix For: 0.9
>
>
> If an external process takes too long to respond, it is killed. The timeout 
> is quite short (a few seconds) and is not configurable from .ini files today.
> couchdb-lucene could use this ability as the first attempt to sort on a field 
> in a large index is slow while it builds a cache. With the timeout, it's 
> killed and the partial work is lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [jira] Commented: (COUCHDB-246) allow customization of external process timeout

2009-02-11 Thread Paul Davis
On Wed, Feb 11, 2009 at 3:54 AM, Antony Blakey (JIRA)  wrote:
>
>[ 
> https://issues.apache.org/jira/browse/COUCHDB-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672558#action_12672558
>  ]
>
> Antony Blakey commented on COUCHDB-246:
> ---
>
> I mean a keep-alive back to couch, not to the HTTP server, although the 
> ability to propagate the keep-alive as an HTTP continue might be interesting, 
> though I'm not sure of the HTTP continue semantics.
>
> The keep-alive was trivial - 2/3 lines to handle the message, because IIRC 
> the timeout is in the receive loop of the external driver. I think its not 
> more work than the configurable option.
>

That's a good point, unless there are objections, I'll throw this in as well.

> As far as UUIDs are concerned, do you mean session multiplexing over the 
> _external channel?
>

That's exactly what I was thinking.

>> allow customization of external process timeout
>> ---
>>
>> Key: COUCHDB-246
>> URL: https://issues.apache.org/jira/browse/COUCHDB-246
>> Project: CouchDB
>>  Issue Type: Bug
>>  Components: Database Core
>>Affects Versions: 0.9
>>Reporter: Robert Newson
>>Priority: Blocker
>> Fix For: 0.9
>>
>>
>> If an external process takes too long to respond, it is killed. The timeout 
>> is quite short (a few seconds) and is not configurable from .ini files today.
>> couchdb-lucene could use this ability as the first attempt to sort on a 
>> field in a large index is slow while it builds a cache. With the timeout, 
>> it's killed and the partial work is lost.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


[jira] Commented: (COUCHDB-246) allow customization of external process timeout

2009-02-11 Thread Antony Blakey (JIRA)

[ 
https://issues.apache.org/jira/browse/COUCHDB-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672558#action_12672558
 ] 

Antony Blakey commented on COUCHDB-246:
---

I mean a keep-alive back to couch, not to the HTTP server, although the ability 
to propagate the keep-alive as an HTTP continue might be interesting, though 
I'm not sure of the HTTP continue semantics.

The keep-alive was trivial - 2/3 lines to handle the message, because IIRC the 
timeout is in the receive loop of the external driver. I think its not more 
work than the configurable option.

As far as UUIDs are concerned, do you mean session multiplexing over the 
_external channel?

> allow customization of external process timeout
> ---
>
> Key: COUCHDB-246
> URL: https://issues.apache.org/jira/browse/COUCHDB-246
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 0.9
>Reporter: Robert Newson
>Priority: Blocker
> Fix For: 0.9
>
>
> If an external process takes too long to respond, it is killed. The timeout 
> is quite short (a few seconds) and is not configurable from .ini files today.
> couchdb-lucene could use this ability as the first attempt to sort on a field 
> in a large index is slow while it builds a cache. With the timeout, it's 
> killed and the partial work is lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (COUCHDB-246) allow customization of external process timeout

2009-02-10 Thread Paul Joseph Davis (JIRA)

[ 
https://issues.apache.org/jira/browse/COUCHDB-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672533#action_12672533
 ] 

Paul Joseph Davis commented on COUCHDB-246:
---

Adding a configurable timeout would be simple. I should've added this during 
the original writing of this code. I'm assuming though that when I wrote the 
original I thought, "Not important until someone complains."

Either way, the time has come.

Adding a configurable timeout is trivial. I'll add an initial patch tomorrow 
most likely that would grant some *.ini control for this.

In regards to Antony's comments I definitely agree, having a more dynamic 
timeout mechanism would be best, but would require me more than the expected 10 
or so lines of code.

Antony, also, when you say Keep-Alive, do you mean a heart beat to CouchDB or 
all the way through to the HTTP client? I'd assume just to CouchDB in terms of 
a "Back off mofo, I'm still working!" sort of way which we don't have yet.

In another slightly unlreated context, I contemplated the other day passing a 
UUID with all  requests to os_process's. This would allow an asynchronous 
communication protocol for all things dealing with non-erlang code. In terms of 
view servers, we could possibly push some effort into the different view 
servers. I think it could also simplify internal code quite a bit. The only 
thing that makes me push less hard is the fact that everything is happening 
over stdio. I know that its optimized through the kernel and I don't have 
benchmarks to show that it's a bottleneck, but its like a large pink flamingo 
standing there staring at me.

> allow customization of external process timeout
> ---
>
> Key: COUCHDB-246
> URL: https://issues.apache.org/jira/browse/COUCHDB-246
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 0.9
>Reporter: Robert Newson
>Priority: Blocker
> Fix For: 0.9
>
>
> If an external process takes too long to respond, it is killed. The timeout 
> is quite short (a few seconds) and is not configurable from .ini files today.
> couchdb-lucene could use this ability as the first attempt to sort on a field 
> in a large index is slow while it builds a cache. With the timeout, it's 
> killed and the partial work is lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (COUCHDB-246) allow customization of external process timeout

2009-02-10 Thread Antony Blakey (JIRA)

[ 
https://issues.apache.org/jira/browse/COUCHDB-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672520#action_12672520
 ] 

Antony Blakey commented on COUCHDB-246:
---

I have this problem with _externals that implement lazy-view update semantics. 
The problem being that the amount of work required for the _external to catchup 
to the current update_seq is unknown. I experimented with a solution that 
allows the external to return a keep-alive message to the server, which doesn't 
return a value to the client but does stop the server killing the external.

I got distracted and didn't complete that work, but I think this is a better 
solution than a fixed timeout. The problem with a timeout is that it doesn't 
account for machine performance or load, or the possible highly variable amount 
of work that the external needs to do on a per-request basis, whereas a 
keep-alive more correctly captures what you want e.g. the external process is 
making progress. Such a keep alive could specify a timeout value, so that the 
external process could control the definition of failure according to how often 
it will send keep-alives, but that might be an unnecessary complication.

> allow customization of external process timeout
> ---
>
> Key: COUCHDB-246
> URL: https://issues.apache.org/jira/browse/COUCHDB-246
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 0.9
>Reporter: Robert Newson
>Priority: Blocker
> Fix For: 0.9
>
>
> If an external process takes too long to respond, it is killed. The timeout 
> is quite short (a few seconds) and is not configurable from .ini files today.
> couchdb-lucene could use this ability as the first attempt to sort on a field 
> in a large index is slow while it builds a cache. With the timeout, it's 
> killed and the partial work is lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.