couchdb-dev mailing list archives

Hi,
On Windows and RHEL5 couchdb currently seems to run without the 'heart' command.
I'm trying to understand how to turn this on.
I was hoping it was an option in the init.d script configuration and I
found the "RECURSED" option (-R) that seems to use HEART_COMMAND and
HEART_BEAT_TIMEOUT.
However when I add -R to the COUCHDB_OPTIONS in /etc/sysconfig/couchdb
then the init script seems to hang in "Starting couchdb".
Do the current scripts in couchdb repository support running with
'heart' and how do I correctly turn this on?
Thanks in advance,
Jeroen
On Thu, Nov 18, 2010 at 12:28 PM, Robert Newson <robert.newson@gmail.com> wrote:
> I know that the Windows version does not run 'heart' which is the bit
> that restarts beam if it crashes. If that's true in RHEL too, then the
> crashes can be explained fairly simply.
>
> B.
>
> On Thu, Nov 18, 2010 at 10:15 AM, Sebastian Cohnen
> <sebastiancohnen@googlemail.com> wrote:
>> short reply, inline:
>>
>> On 18.11.2010, at 10:49, Jeroen Janssen wrote:
>>
>>> Hello,
>>>
>>> I am currently investigating the migration of data to couchdb and am
>>> experiencing couchdb crashes that are not visible in the couchdb.log
>>> file.
>>> These couchdb crashes have occured on Windows (couchdb 1.0.1, erlang
>>> 14A) and RHEL5 (couchdb 1.0.1, erlang R12B).
>>>
>>> I understand it could be a bit difficult to answer, but I was
>>> wondering what kind of errors would result in couchdb not logging an
>>> error in its logfile?
>>
>> out of memory errors are one example. couch (actually beam.smp) will crash and couch
will be restarted. I've seen this in production when replicating or compacting databases with
documents having lots of revisions (not sure if this will help you though).
>>
>>>
>>> For the moment I am trying to run with debug logging and hope that I
>>> can get some better logging to show you (the problem seems to be
>>> reasonable reproduceable, although it takes a while to get to it).
>>>
>>> The problem I have might have to due with me 'frequently' calling
>>> compaction on the database while also new documents are inserted.
>>> I do the compaction because there is a problem with appending to 4G+
>>> files on the Windows platform (in Erlang).
>>> As part of the migration process, I will compact the database after a
>>> certain amount of new documents have been added since last compaction.
>>> This is to ensure that I can get to a situation where all current data
>>> is actually inside couchdb (which unfortunately I have not reached
>>> yet)
>>>
>>> I initially thought the problem was maybe due to Erlang on Windows,
>>> but since I have also had the issue on a RHEL5 machine, I am posting
>>> here to see if it could be something in couchdb itself.
>>>
>>> Let me know if I can do something specific to get more (usefull) logging.
>>> Unfortunately, due to the data that's inside the database I can not
>>> send the actual database files for analysis, but I will try if I can
>>> create a testscript that mimics the migration of my data to couchdb.
>>>
>>> Best regards,
>>>
>>> Jeroen Janssen
>>
>>
>