microdc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[microdc-devel] "Slave mode" patch and Russian translation plus a small


From: Andrew Zabolotny
Subject: [microdc-devel] "Slave mode" patch and Russian translation plus a small but important bugfix
Date: Tue, 3 Apr 2007 12:17:26 +0400

Hello!

I did some improvements to microdc2 which I hope will help the project
move ahead.

1. The first patch I did is the Russian translation. It's almost
complete, there were a couple of rough edges in the translation that
I have fixed in patch number 2.

2. This patch implements a "slave mode". What it does is that it allows
two microdc2's to run with the same database of shared files. Right now
microdc2 supports connecting just to one hub at a time, so this patch
helps overcome this limit.

To use it, just launch a second copy of microdc2 and set
filelist_refresh_interval to 0. This will tell microdc2 to not refresh
the file list, but rather to check the last modification time on file
~/.microdc2/filelist. When it changes (supposedly re-written by a
"master" microdc2 process), it is re-read by the slave processes.

3. Another small patch is that I've added - the -c switch now accepts
filenames without path, in which case they are looked for in the
~/.microdc2/ directory. For example, you can have two config files -
config.hub1 and config.hub2 in that directory, then you just can run:
"microdc2 -c config.hub1" rather than "microdc2
-c /home/user/config.hub1".

4. Also the later patch incorporates a important bugfix (I haven't
separated it from the slave mode patch, my bad, but it's completely
contained in the subdiff for the file main.c). While having microdc2
running for a couple of days I have observed that sometimes it goes in
a tight loop in the master process (the one that manipulates the
children) doing select() which quits immediately without sleeping
inbetween. This causes 100% CPU load on the server which is a pretty
bad thing.

Some research has shown that sometimes (very seldom) client processes
are left running although all the relevant structures in the main
process (in the user_conns hashmap) are cleaned up, but their file
handle is left in the read_fds/write_fds set. Since these strcutures
are persistent for the lifetime of the master process, as soon as these
handles becomes ready the master process won't be able to sleep in
select() anymore, but still it won't do anything about these "orphan"
handles.

The 'bugfix' is rather a dirty workaround, but it works and it could be
helpful at least in debug mode (when/if the real bug will be fixed).
What it does is that it checks that all handles signalled as ready in
the res_read_fds/res_write_fds filesets are processed. If there are
handles left unprocessed at the end of loop, it emits a warning and
closes those handles, then clears them from read_fds/write_fds.

The patches, together with some additional files that are required in
order to build a Fedora Core 6 RPM can be found here:

http://cs.ozerki.net/zap/pub/microdc2/

I decided not to attach them to the message since they're relatively
big and I'm not sure everyone here is prepared for large file
attachments. I'll keep them there as long as they are relevant.

-- 
Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]