Anyone using couchdb on windows for real?? I'm considering.

[Juhani Ränkimies <ju...@juranki.com>]

Hi,

I started playing with 0.10.0 binary installation on windows
(http://people.apache.org/~mhammond/dist/0.10.0/). Couldn't have been
easier, thanks.

I've had an instance running since monday, receiving event data. Db is
0.8GB now (141 MB after compact on a patched replica), >90000
documents, 10 views and a list to export data to excel for analysis.
Not fancy, but very useful. Only problem apart from known issues so
far has been that manual ibrowse:start() is needed before remote
replication.

I searched windows related issues from jira and I'm worried about two of them:

https://issues.apache.org/jira/browse/COUCHDB-86 ( compaction doesn't work )
https://issues.apache.org/jira/browse/COUCHDB-222 ( fsync problem )

The compaction issue resolution is "Don't Fix", and it refers to
discussion on issue 67 (unicode chars in db names) for a solution. I
need the compaction from the start and I got it to work with the
attached dirty fix. That'll do for now, but I'd like to understand how
67 will solve the problem.

The fsync issue worries me because I don't exactly undestand it's
implications. It'd be great if someone would elaborate.


Cheers,
Juhani



Attachments:
inst_couch_service.bat.txt: example of installing couchdb as a service.
win32_compact_hack.patch: dirty hack to enable compact on win32

Re: Anyone using couchdb on windows for real?? I'm considering.

[Juhani Ränkimies <ju...@juranki.com>]

> This is all fairly vague, but IIUC the general idea was that issue 67 would
> provide a level of indirection between the DB name and the actual file name,
> primarily to support database names which are invalid file-system names.
>  Then this general support could possibly be leveraged so that whenever a
> database needs to be rolled over, instead of trying to replace it directly
> on the file-system (which fails on Windows), we just update the "pointer" to
> use a new name, serving all new requests from that db and deleting the old
> database once everything has caught up and released the old DB.
>

Ok, I see.

> Also, my mailer isn't showing the "dirty fix" attachment - could you please
> resend it (either to me personally or via the list)?
>

Let's see if zipping it helps. There's two versions now:

The original fixes the opening of db so that if db.couch is missing
db.couch.compact is renamed before opening. compact_done -handler is
tweaked to help windows to actually delete the db.couch, then the
couch_db_updater is intentionally crashed, and after a while
couch_db:open is called to let couch heal itself.

The second approach doesn't crash couch_db_updater anymore, but adds
couch_file:win32_rename which closes the file, renames it and opens it
again.

>> The fsync issue worries me because I don't exactly undestand it's
>> implications. It'd be great if someone would elaborate.
>
...
>
> Which looks to me like it is no longer of concern.
>

Great!

Thanks,
Juhani

Re: Anyone using couchdb on windows for real?? I'm considering.

[Mark Hammond <sk...@gmail.com>]

On 1/11/2009 1:55 AM, Juhani Ränkimies wrote:
> I searched windows related issues from jira and I'm worried about two of them:
>
> https://issues.apache.org/jira/browse/COUCHDB-86 ( compaction doesn't work )
> https://issues.apache.org/jira/browse/COUCHDB-222 ( fsync problem )
>
> The compaction issue resolution is "Don't Fix", and it refers to
> discussion on issue 67 (unicode chars in db names) for a solution. I
> need the compaction from the start and I got it to work with the
> attached dirty fix. That'll do for now, but I'd like to understand how
> 67 will solve the problem.

This is all fairly vague, but IIUC the general idea was that issue 67 
would provide a level of indirection between the DB name and the actual 
file name, primarily to support database names which are invalid 
file-system names.  Then this general support could possibly be 
leveraged so that whenever a database needs to be rolled over, instead 
of trying to replace it directly on the file-system (which fails on 
Windows), we just update the "pointer" to use a new name, serving all 
new requests from that db and deleting the old database once everything 
has caught up and released the old DB.

Also, my mailer isn't showing the "dirty fix" attachment - could you 
please resend it (either to me personally or via the list)?

> The fsync issue worries me because I don't exactly undestand it's
> implications. It'd be great if someone would elaborate.

I'm not 100% sure, but I *think* the issue was that file:sync() on 
erlang under windows used to be a noop - eg, see:

http://www.erlang.org/pipermail/erlang-questions/2007-March/025485.html

But following the lead from that post, I see in R13B01 the source for 
that impl is now:

efile_fsync(errInfo, fd)
Efile_error* errInfo;		/* Where to return error codes. */
int fd;				/* File descriptor for file to sync. */
{
     if (!FlushFileBuffers((HANDLE) fd)) {
	return check_error(-1, errInfo);
...

Which looks to me like it is no longer of concern.

Cheers,

Mark