You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Ramkrishna Kulkarni <ra...@gmail.com> on 2011/07/01 08:29:32 UTC
Re: changes_timeout
I have this same issue when I start replication through a Couchapp. If I
start it through command line curl, it takes few minutes but works. I faced
this problem with a DB containing around 30K documents and the filter
selected 500-1000 documents from it.
Ram
On Thu, Jun 30, 2011 at 5:07 PM, Benoit DECHERF <bd...@gmail.com> wrote:
> Hi,
>
> I'm playing with the filter replication.
> So my filter is:
> function(doc, req) { if (doc.type && doc.type == 'user' && doc.userId ==
> req.query.userId) { return true; } else { return false; } }
>
> This is to replicate all document from a given user. (This is not
> a continuous replication)
> The replication fails because of a changes_timeout error. (same error with
> 1.1.0 and 1.0.2)
> I check the code, and it seems that the pb comes from:
> src/couchdb/couch_rep_changes_feed.erl
> All timeout are hardcoded, and one of them is 10s.
> the request filter took between 10 and 25s.
>
> Am I doing something wrong ? Or is this a bug ?
>
> Thanks,
> Benoit
>
Re: changes_timeout
Posted by Benoit DECHERF <bd...@gmail.com>.
Great!
I hadn't check the trunk before writing.
I had already do the modification and create a modified version of couchdb.
Thanks!
Benoit
2011/7/5 Dave Cottlehuber <da...@muse.net.nz>
> On 5 July 2011 21:26, Filipe David Manana <fd...@apache.org> wrote:
> > I think the most right thing here would be to make the connection
> > timeout configurable (globally or per replication), exactly like the
> > in new replicator implementation (trunk, upcoming 1.2.0 release).
> > However just replacing that 10 seconds timeout with 30 seconds (like
> > everywhere else in the code) should do it for most cases.
> >
> >
> > On Tue, Jul 5, 2011 at 8:40 AM, Dave Cottlehuber <da...@muse.net.nz>
> wrote:
> >> On 5 July 2011 18:53, Benoit DECHERF <bd...@gmail.com> wrote:
> >>> So ?
> >>> Should I enter a bug for this ?
> >>>
> >>> Benoit
> >>>
> >>> 2011/7/1 Ramkrishna Kulkarni <ra...@gmail.com>
> >>>
> >>>> I have this same issue when I start replication through a Couchapp. If
> I
> >>>> start it through command line curl, it takes few minutes but works. I
> faced
> >>>> this problem with a DB containing around 30K documents and the filter
> >>>> selected 500-1000 documents from it.
> >>>>
> >>>> Ram
> >>>>
> >>>> On Thu, Jun 30, 2011 at 5:07 PM, Benoit DECHERF <bd...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> > Hi,
> >>>> >
> >>>> > I'm playing with the filter replication.
> >>>> > So my filter is:
> >>>> > function(doc, req) { if (doc.type && doc.type == 'user' &&
> doc.userId ==
> >>>> > req.query.userId) { return true; } else { return false; } }
> >>>> >
> >>>> > This is to replicate all document from a given user. (This is not
> >>>> > a continuous replication)
> >>>> > The replication fails because of a changes_timeout error. (same
> error
> >>>> with
> >>>> > 1.1.0 and 1.0.2)
> >>>> > I check the code, and it seems that the pb comes from:
> >>>> > src/couchdb/couch_rep_changes_feed.erl
> >>>> > All timeout are hardcoded, and one of them is 10s.
> >>>> > the request filter took between 10 and 25s.
> >>>> >
> >>>> > Am I doing something wrong ? Or is this a bug ?
> >>>> >
> >>>> > Thanks,
> >>>> > Benoit
> >>>> >
> >>>>
> >>>
> >>
> >> Hi Benoit,
> >>
> >> yes please. I will take a look & see if I can provide a fix for this.
> >>
> >> A+
> >> Dave
> >>
> >
> >
> >
> > --
> > Filipe David Manana,
> > fdmanana@gmail.com, fdmanana@apache.org
> >
> > "Reasonable men adapt themselves to the world.
> > Unreasonable men adapt the world to themselves.
> > That's why all progress depends on unreasonable men."
> >
>
> Hi Benoit,
>
> Seems Filipe has this covered in trunk already (sorry!) so no need for
> a ticket as it will come across in the next release.
>
> As you've got couchdb installed you also have an erlang compiler; its
> sufficient to edit the source .erl file with your new timeout value
> and then:
>
> erlc <file.erl>
>
> to produce a new .beam file. Copy this over top of the old one,
> restart couchdb & you can quickly check if it addresses your issue.
>
> A+
> Dave
>
Re: changes_timeout
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 5 July 2011 21:26, Filipe David Manana <fd...@apache.org> wrote:
> I think the most right thing here would be to make the connection
> timeout configurable (globally or per replication), exactly like the
> in new replicator implementation (trunk, upcoming 1.2.0 release).
> However just replacing that 10 seconds timeout with 30 seconds (like
> everywhere else in the code) should do it for most cases.
>
>
> On Tue, Jul 5, 2011 at 8:40 AM, Dave Cottlehuber <da...@muse.net.nz> wrote:
>> On 5 July 2011 18:53, Benoit DECHERF <bd...@gmail.com> wrote:
>>> So ?
>>> Should I enter a bug for this ?
>>>
>>> Benoit
>>>
>>> 2011/7/1 Ramkrishna Kulkarni <ra...@gmail.com>
>>>
>>>> I have this same issue when I start replication through a Couchapp. If I
>>>> start it through command line curl, it takes few minutes but works. I faced
>>>> this problem with a DB containing around 30K documents and the filter
>>>> selected 500-1000 documents from it.
>>>>
>>>> Ram
>>>>
>>>> On Thu, Jun 30, 2011 at 5:07 PM, Benoit DECHERF <bd...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I'm playing with the filter replication.
>>>> > So my filter is:
>>>> > function(doc, req) { if (doc.type && doc.type == 'user' && doc.userId ==
>>>> > req.query.userId) { return true; } else { return false; } }
>>>> >
>>>> > This is to replicate all document from a given user. (This is not
>>>> > a continuous replication)
>>>> > The replication fails because of a changes_timeout error. (same error
>>>> with
>>>> > 1.1.0 and 1.0.2)
>>>> > I check the code, and it seems that the pb comes from:
>>>> > src/couchdb/couch_rep_changes_feed.erl
>>>> > All timeout are hardcoded, and one of them is 10s.
>>>> > the request filter took between 10 and 25s.
>>>> >
>>>> > Am I doing something wrong ? Or is this a bug ?
>>>> >
>>>> > Thanks,
>>>> > Benoit
>>>> >
>>>>
>>>
>>
>> Hi Benoit,
>>
>> yes please. I will take a look & see if I can provide a fix for this.
>>
>> A+
>> Dave
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
Hi Benoit,
Seems Filipe has this covered in trunk already (sorry!) so no need for
a ticket as it will come across in the next release.
As you've got couchdb installed you also have an erlang compiler; its
sufficient to edit the source .erl file with your new timeout value
and then:
erlc <file.erl>
to produce a new .beam file. Copy this over top of the old one,
restart couchdb & you can quickly check if it addresses your issue.
A+
Dave
Re: changes_timeout
Posted by Filipe David Manana <fd...@apache.org>.
I think the most right thing here would be to make the connection
timeout configurable (globally or per replication), exactly like the
in new replicator implementation (trunk, upcoming 1.2.0 release).
However just replacing that 10 seconds timeout with 30 seconds (like
everywhere else in the code) should do it for most cases.
On Tue, Jul 5, 2011 at 8:40 AM, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 5 July 2011 18:53, Benoit DECHERF <bd...@gmail.com> wrote:
>> So ?
>> Should I enter a bug for this ?
>>
>> Benoit
>>
>> 2011/7/1 Ramkrishna Kulkarni <ra...@gmail.com>
>>
>>> I have this same issue when I start replication through a Couchapp. If I
>>> start it through command line curl, it takes few minutes but works. I faced
>>> this problem with a DB containing around 30K documents and the filter
>>> selected 500-1000 documents from it.
>>>
>>> Ram
>>>
>>> On Thu, Jun 30, 2011 at 5:07 PM, Benoit DECHERF <bd...@gmail.com>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > I'm playing with the filter replication.
>>> > So my filter is:
>>> > function(doc, req) { if (doc.type && doc.type == 'user' && doc.userId ==
>>> > req.query.userId) { return true; } else { return false; } }
>>> >
>>> > This is to replicate all document from a given user. (This is not
>>> > a continuous replication)
>>> > The replication fails because of a changes_timeout error. (same error
>>> with
>>> > 1.1.0 and 1.0.2)
>>> > I check the code, and it seems that the pb comes from:
>>> > src/couchdb/couch_rep_changes_feed.erl
>>> > All timeout are hardcoded, and one of them is 10s.
>>> > the request filter took between 10 and 25s.
>>> >
>>> > Am I doing something wrong ? Or is this a bug ?
>>> >
>>> > Thanks,
>>> > Benoit
>>> >
>>>
>>
>
> Hi Benoit,
>
> yes please. I will take a look & see if I can provide a fix for this.
>
> A+
> Dave
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: changes_timeout
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 5 July 2011 18:53, Benoit DECHERF <bd...@gmail.com> wrote:
> So ?
> Should I enter a bug for this ?
>
> Benoit
>
> 2011/7/1 Ramkrishna Kulkarni <ra...@gmail.com>
>
>> I have this same issue when I start replication through a Couchapp. If I
>> start it through command line curl, it takes few minutes but works. I faced
>> this problem with a DB containing around 30K documents and the filter
>> selected 500-1000 documents from it.
>>
>> Ram
>>
>> On Thu, Jun 30, 2011 at 5:07 PM, Benoit DECHERF <bd...@gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I'm playing with the filter replication.
>> > So my filter is:
>> > function(doc, req) { if (doc.type && doc.type == 'user' && doc.userId ==
>> > req.query.userId) { return true; } else { return false; } }
>> >
>> > This is to replicate all document from a given user. (This is not
>> > a continuous replication)
>> > The replication fails because of a changes_timeout error. (same error
>> with
>> > 1.1.0 and 1.0.2)
>> > I check the code, and it seems that the pb comes from:
>> > src/couchdb/couch_rep_changes_feed.erl
>> > All timeout are hardcoded, and one of them is 10s.
>> > the request filter took between 10 and 25s.
>> >
>> > Am I doing something wrong ? Or is this a bug ?
>> >
>> > Thanks,
>> > Benoit
>> >
>>
>
Hi Benoit,
yes please. I will take a look & see if I can provide a fix for this.
A+
Dave
Re: changes_timeout
Posted by Benoit DECHERF <bd...@gmail.com>.
So ?
Should I enter a bug for this ?
Benoit
2011/7/1 Ramkrishna Kulkarni <ra...@gmail.com>
> I have this same issue when I start replication through a Couchapp. If I
> start it through command line curl, it takes few minutes but works. I faced
> this problem with a DB containing around 30K documents and the filter
> selected 500-1000 documents from it.
>
> Ram
>
> On Thu, Jun 30, 2011 at 5:07 PM, Benoit DECHERF <bd...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'm playing with the filter replication.
> > So my filter is:
> > function(doc, req) { if (doc.type && doc.type == 'user' && doc.userId ==
> > req.query.userId) { return true; } else { return false; } }
> >
> > This is to replicate all document from a given user. (This is not
> > a continuous replication)
> > The replication fails because of a changes_timeout error. (same error
> with
> > 1.1.0 and 1.0.2)
> > I check the code, and it seems that the pb comes from:
> > src/couchdb/couch_rep_changes_feed.erl
> > All timeout are hardcoded, and one of them is 10s.
> > the request filter took between 10 and 25s.
> >
> > Am I doing something wrong ? Or is this a bug ?
> >
> > Thanks,
> > Benoit
> >
>