Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: Error 500 - badmatch,{error,system_limit}
From: Damien Katz <damien@apache.org>
In-Reply-To: <1267549295.13419.52.camel@redemption>
Date: Tue, 2 Mar 2010 11:33:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D76F5C57-A759-4183-AA85-C232F7B045DC@apache.org>
References: <1267520815.13419.25.camel@redemption>
 <D1B09B10-4CEB-41AE-969B-BD58FF0A890E@gmail.com>
 <1267549295.13419.52.camel@redemption>
To: user@couchdb.apache.org

Simon, if possible, can you upload the database file somewhere? I want =
to investigate the duplicate document issue. You should email me =
privately if you have confidential info in the database.

-Damien


On Mar 2, 2010, at 9:01 AM, Simon Eisenmann wrote:

> Am Dienstag, den 02.03.2010, 08:54 -0800 schrieb J Chris Anderson:
>>>=20
>>> ServerError: (500, ('error', '{{badmatch,{error,system_limit}},\n
>>>=20
>> =
[{couch_file,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}=
'))
>>>=20
>>> Anyone can tell me what this error message means?
>>>=20
>>> After restart of the Couch things run smoothly again, though i seem
>> to
>>> have a duplicated entry in the database (same id, though different
>>> revisions which is shown in futon). Both of these objects came back
>> when
>>> calling a view, though one of them fails to be retrieved properly by
>>> revision (returns nothing).
>>>=20
>>=20
>> Interesting. Please keep that file around in it's present state if
>> possible. We might want to look at it to see how it got that way.
>>=20
>> Are there any other factors that could be at play? Full disk?=20
>=20
> Disk space was available all the time in that test run. It consists of
> two couch DB instance on seperate machines replicating two database to
> each other, with constant changes on both nodes (but without changing
> the same objects - so no conflicts). =46rom time to time a machine was
> taken down for testing and brought online shortly after again. Though
> the issue started deep in the night without any manual action.
>=20
>=20
>=20
>=20
> --=20
> Simon Eisenmann
>=20
> [ mailto:simon@struktur.de ]
>=20
> [ struktur AG | Kronenstra=DFe 22a | D-70173 Stuttgart ]
> [ T. +49.711.896656.68 | F.+49.711.89665610 ]
> [ http://www.struktur.de | mailto:info@struktur.de ]