[
https://issues.apache.org/jira/browse/COUCHDB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-703:
--
Attachment: couchdb-703-regression-test-trunk.patch
Regression test.
> doc_ids replicate alw
[
https://issues.apache.org/jira/browse/COUCHDB-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-705:
--
Attachment: 0001-configurable-mochiweb-max-requests.patch
Attached patch adds a new configurat
[
https://issues.apache.org/jira/browse/COUCHDB-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-705:
--
Priority: Minor (was: Major)
> hard limit on number of concurrent requests
>
hard limit on number of concurrent requests
---
Key: COUCHDB-705
URL: https://issues.apache.org/jira/browse/COUCHDB-705
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.11
Envi
[
https://issues.apache.org/jira/browse/COUCHDB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847659#action_12847659
]
Jan Lehnardt commented on COUCHDB-703:
--
Applied in trunk r925488 and 0.11.x r925489.
[
https://issues.apache.org/jira/browse/COUCHDB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847656#action_12847656
]
Filipe Manana commented on COUCHDB-703:
---
$ cd your_couch_db_checkout_dir
$ git appl
How to use the patch file?
On 20.03.2010, at 00:08, Filipe Manana (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/COUCHDB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Filipe Manana updated COUCHDB-703:
> --
>
>
On 19 Mar 2010, at 18:07, J Chris Anderson wrote:
>
> On Mar 19, 2010, at 11:43 AM, Paul Davis wrote:
>
>> On Fri, Mar 19, 2010 at 2:02 PM, Jan Lehnardt wrote:
>>>
>>> On 19 Mar 2010, at 12:50, Noah Slater wrote:
>>>
On 19 Mar 2010, at 17:11, Jan Lehnardt wrote:
> We wan
[
https://issues.apache.org/jira/browse/COUCHDB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-703:
--
Attachment: couchdb-703-trunk.patch
Fixes the issue.
> doc_ids replicate always the same doc
On Mar 19, 2010, at 11:43 AM, Paul Davis wrote:
> On Fri, Mar 19, 2010 at 2:02 PM, Jan Lehnardt wrote:
>>
>> On 19 Mar 2010, at 12:50, Noah Slater wrote:
>>
>>>
>>> On 19 Mar 2010, at 17:11, Jan Lehnardt wrote:
>>>
We want to test the CouchDB code, not the browser's HTTP handling.
>>>
On Fri, Mar 19, 2010 at 2:02 PM, Jan Lehnardt wrote:
>
> On 19 Mar 2010, at 12:50, Noah Slater wrote:
>
>>
>> On 19 Mar 2010, at 17:11, Jan Lehnardt wrote:
>>
>>> We want to test the CouchDB code, not the browser's HTTP handling.
>>
>> Sure, but as one of CouchDB's primary interfaces is the browse
On 19 Mar 2010, at 12:50, Noah Slater wrote:
>
> On 19 Mar 2010, at 17:11, Jan Lehnardt wrote:
>
>> We want to test the CouchDB code, not the browser's HTTP handling.
>
> Sure, but as one of CouchDB's primary interfaces is the browser, it seems to
> makes sense that we would want to test how
[
https://issues.apache.org/jira/browse/COUCHDB-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847477#action_12847477
]
Rachel Willmer commented on COUCHDB-243:
It's an erlang limit, which can be config
[
https://issues.apache.org/jira/browse/COUCHDB-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847475#action_12847475
]
Rachel Willmer commented on COUCHDB-644:
Copious quantities of io:format statement
On 19 Mar 2010, at 17:11, Jan Lehnardt wrote:
> We want to test the CouchDB code, not the browser's HTTP handling.
Sure, but as one of CouchDB's primary interfaces is the browser, it seems to
makes sense that we would want to test how this works. Testing from the browser
allows us to test for
On 19 Mar 2010, at 11:56, Noah Slater wrote:
>
> On 19 Mar 2010, at 16:49, Jan Lehnardt wrote:
>
>>> And if so, what can we do to fix the whole situation post-release?
>>
>> (answering anyway :) Move all JS tests to etap tests to factor out browser
>> issues, caching, timing, etc and don't in
On 19 Mar 2010, at 16:49, Jan Lehnardt wrote:
>> And if so, what can we do to fix the whole situation post-release?
>
> (answering anyway :) Move all JS tests to etap tests to factor out browser
> issues, caching, timing, etc and don't introduce any errors.
Aren't these exactly the type of is
On 19 Mar 2010, at 11:44, Noah Slater wrote:
> Yep, I checked both browsers out of habit more than anything.
>
> What about the other thread discussing an actual issue brought up by some of
> these failures?
It was an issue in the test case, not core code.
> Is it not worrying that they fail
Yep, I checked both browsers out of habit more than anything.
What about the other thread discussing an actual issue brought up by some of
these failures?
Is it not worrying that they failed first then worked, or is this something
ignorable?
And if so, what can we do to fix the whole situation
Hi Noah,
The test suite doesn't support Safari. While I agree that the
first-failing-then-working tests in Firefox are concerning, I say it doesn't
block a release.
Cheers
Jan
--
On 19 Mar 2010, at 06:59, Noah Slater wrote:
> Hey,
>
> I was going to call a vote on the release today, but I a
On Fri, Mar 19, 2010 at 8:41 AM, Robert Dionne
wrote:
>
>>
>> I got the error included below this morning, and when I ran it again, there
>> was no error.
>
>> /tmp/couchdb/0.11.0/test/etap/090-task-status.ok
>> /tmp/couchdb/0.11.0/test/etap/100-ref-counter.FAILED
>
> I got the error included below this morning, and when I ran it again, there
> was no error.
> /tmp/couchdb/0.11.0/test/etap/090-task-status.ok
> /tmp/couchdb/0.11.0/test/etap/100-ref-counter.FAILED test 8
I looked into this random fail a bit
On 19 Mar 2010, at 12:05, Robert Dionne wrote:
> not really. In any event, looking at the code a bit couch_db:is_idle defines
> idle in part as "there are now only two processes referring to this db", so
> it looks like it would err on the side of concluding a db was not idle when
> in fact it
On Mar 19, 2010, at 7:48 AM, Noah Slater wrote:
> I have absolutely no problem with the time taken for the tests.
cool, I misunderstood part of your issue
>
> My only issue is that they intermittently fail. Because of that, I am now
> suspicious of any results I get.
>
> Is it really an e
Hey,
I was going to call a vote on the release today, but I am being blocked by test
suite errors.
Running in Safari:
changes
• Assertion 'should return matching rows' failed: expected '3', got '1'
rev_stemming
• Assertion 'should return a truncated revision
I have absolutely no problem with the time taken for the tests.
My only issue is that they intermittently fail. Because of that, I am now
suspicious of any results I get.
Is it really an error, or is it a timing issue or a race condition?
Suspicious tests are next to useless.
On 19 Mar 2010, a
I see similar issues, though never with 100-ref-counter. It looks like a race
condition but should be checked because the place where it's used,
couch_db:is_idle, depends on that value being right.
make check is much faster that make cover
I think it's ok for tests to take a long time t
Some of the test suites rely on timing delays, and these are unpredictable,
resulting in non-deterministic test failures. The full tag/build/test cycle is
long enough as it is - but having to start again from scratch when the last,
and second, run of the test suite fails adds a significant amoun
28 matches
Mail list logo
