[jira] Commented: (COUCHDB-246) allow customization of external process timeout
[ 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
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
[ 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
[ 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
[ 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.