Over 500+ new features & enhancements have been incorporated to our Zoom version control product editions. Major focus of this release has been simplifying version control for the creatives, enhanced usability, tighter integration with popular tools, large previews and a new MacOS X Snow Leopard Finder plug-in. Visit our web site link here to  take a  look at the top ten new features in Zoom.

Mac Folder Coloring via Zoom

The beagle daemon for one is not installed as a normal /etc/init.d or xinetd service. The following recipe worked for me, might need to scipt it and launch it from the bashrc when loggin in:

1. $ beagled –disable-schedule ( this would disable the scheduler)
2. $ beagle-settings (This brings up a GUI to stop it from indexing, just deselect the options, see the screen shot below)
   
3. $ beagle-shutdown (now the damn service should be gone)
4. $ beagle-info –status
   Could not connect to the daemon.

If you see the last line, you are set!

Retreiving software information

A little bit of detective work in another terminal indicates why:

# ps -leaf | grep `cat /var/run/yum.pid`

This number is Pirut’s yum process ID. Let’s see what it’s stuck doing:

# strace -p `cat /var/run/yum.pid
[root@rahul ~]# strace -p 2524
Process 2524 attached – interrupt to quit
ioctl(4, FIONREAD, [0])                 = 0
poll( <unfinished …>

Check, this out; it is waiting in a poll system call. This usually implies that the process is waiting for a network IO event to happen. If the previous pirut process is gone, well, things can get to this mess. By the way, it is possible to nuke pirut yum at this point; you just have to be brutal.

# pkill -9 pirut

Once this is done, a little digging around often shows a couple of __db.* files in /var/lib/rpm. Let’s nule all of these:

# rm -rf /var/lib/rpm/__db.*

At this juncture, retrying the hung yum/pirut command should work. At least, it does so for me. Sometimes, I need to run “yum clean all” after cleaning up the above mess before yum can make progress.

CVS allows you tp specify a run-as user-name in the CVSROOT/passwd file. So for example if we use the following syntax in CVSROOT/passwd file:

john:12$2#&65:cvsadmin
greshim:ac2$2#&65:cvsadmin

The above tells the CVS server to launch/fork the CVS process with the effective user-id as ‘cvsadmin‘ instead of say CVS user ‘john‘ who may have executed the commit command. This allows the CVS administrator to maintaina separation between system user and the CVS user. It allows the admin to avoid polluting UNIX file level permissions inside the CVSROOT.

However the problem is how does a CVS trigger like Loginfo get hold of the actual CVS user on whose behalf the run-as user is executing the CVS command ? If the trigger script uses ‘whoami’ to query the user it would get the effective user-id like ‘cvsadmin’ instead of ‘john’.

THE SOLUTION

Instead of querying for effective user-id from within the trigger script, just pass a $USER variable as an argument to the trigger script in the trigger definition file. For example:

The following `loginfo' file, together with the tiny shell-script below, appends all log messages to the file `$CVSROOT/CVSROOT/commitlog', and any commits to the administrative files (inside the `CVSROOT' directory) are also logged in `/usr/adm/cvsroot-log'. Commits to the `prog1' directory are mailed to ceder.

ALL cvs-log $CVSROOT/CVSROOT/commitlog $USER ^CVSROOT(/|$) cvs-log /usr/adm/cvsroot-log $USER ^prog1(/|$) Mail -s "%p %s" ceder

Inside the trigger script you can query the passed command line argument for the actual CVS user name.

Why does this project exist?

To take over the CVS user base. Specifically, we’re writing a new
version control system that is very similar to CVS, but fixes many
things that are broken. See our front page.

For instance :

1. CVS opens a single client-server connection for any operation. In contrast Subversion is TCP connection hungry. Using the SVN RA protocol, a checkout can trigger 4-5 new TCP connections. On a WAN if you have a Subversion repository being accessed from say China to USA, this can be a killer. Each TCP connection can take 1.5 Round trips. The SVN DeltaV Http protocol fares better but it too can open multiple TCP connections for operations.
2. Chatty protocol. And I thought CVS was chatty, wait till you sniff the Subversion network protocol. I noticed for the SVN RA protocol, repeated invocation on new connections and on each connection the authentciation happens again (if you are using SSH it really slows you down), commands like get-latest-rev, set-path are sent multiple times. Sometimes the same command is sent multiple times on the same connection. Harmless ? Its not an error yeah but why be so wasteful ? I mean its not like this is legacy code that was written 20 years ago. Why not have a clean network protocol model
3. What’s with this lisp like list syntax on the wire :
   

   ( 2 ( edit-pipeline ) 14:svn://zen/mod )
   ( CRAM-MD5 ( ) )
   38:rachel 6195af60930ad5367267948ddacf30ca
   ( get-latest-rev ( ) )
   ( update ( ( 19 ) 0: true ) )
   ( set-path ( 0: 16 false ( ) ) ) ( set-path ( 11:dir1/f1.txt 19 false ( ) ) ) ( set-path ( 9:dir1/foo2 19 false ( ) ) ) ( finish-report ( ) )
   ( success ( ) )

   Why not use a more compact representation like CVS. I used to complain the CVS protocol does 4-5 Round trips to execute a command, Subversion can do litereally 14-15 Round Trips in a checkout. Agreed you don’t checkout the whole repository often but why the sloppiness in initial design.

If the goal was to do better CVS, the Subversion team should have started with looking at how the network protocol is dealt with in CVS and learned from it.

More ramblings on Subversion to follow soon.

THE PROBLEM
The cvs server will automatically (or, more accurately, as part of the update run that automatically happens after a commit) expand valid keyword strings in a text file as part of the commit operation. In other words it is the responsibility of the ‘server-side’ of cvs to fill in the appropriate values for the RCS keywords.

Currently where this breaks down is when the end-user modifies the content of the RCS keywords. For example, let’s say a file contains:

File : foo
=======
Line 1: $Id$

On the initial commit, the server returns the file (if keyword expansion is not turned off) and expands Id a -

File: foo
=======
$Id: id,v 1.1 2005/10/28 18:39:46 userX Exp $

If the user accidentally or intentionally changes just the expanded value (no other change) on the client-side to:

File: foo (revision 1.1 in user sandbox)
=========================
$Id: id,v 1.9 3005/10/28 18:39:46 userYYY Exp $

and then does a commit, the CVS server as it stands today will be happy to commit a new version but as part of the update run that automatically happens after a commit, will re-expand the keyword and the CVS client will have the following file in the sandbox :

File: foo
===========
$Id: id,v 1.2 2005/10/28 18:46:18 userX Exp $

In other words the user’s intent of modifying the keyword content is not honored. This make sense as keyword expansion is owned by the server and a client can not wily-nilly change the keyword content (between the two $, with the exception of $Log$ keyword of-course)

However, this also causes spurious revisions to be created in the CVS repository and this revision is not what the end user expects. The revision metadata within the $..$ keyword expansion is controlled by the server and as seen in the above example, the user can’t change it even though his attempt to do so results in a new revision being committed.

We have come across large CVS repositories where lots of such spurious revisions (no content change except keyword) exist on several files. This causes problems downstream when for example doing branch merges, as differences on just keyword expansion can cause the file to be treated as changed. Creating new revisions is an important step. It has consequence on downstream tools. Per-user stats (how may commits by a given user, for example) are impacted when revisions are created. One way to deal with this problem is to turn off keyword expansion (as available in 1-12-XX feature tree or use -ko for every file that has keywords), but that is a sledgehammer approach that denies the benefits of RCS keywords to the end users.

THE FIX
The patch (off the 1-11-21 tree) that we have attached addresses this bug/mis-feature. It ensures keyword expansion will not cause spurious revisions that differ just in keyword content that the CVS server inserts between $..$ markers. With the patch, a CVS user can still use keyword expansion as expected, but during the file classification phase of a CVS commit, the patch kicks in and triggers a keyword-sensitive diff algorithm, that we have developed, which will ignore RCS/CVS keyword differences during this phase. This reduces spurious revision creation. The patch deals with all keywords except the logmsgs after a $Log$ keyword.

The patch uses a space-time efficient diff’ing algorithm that does not require the entire file to be read into memory to do the keyword canonicalization. It operates on a block at a time. The algorithm does not need to make multiple passes. As described in the src comments, the algorithm is implemented as a finite state machine that tracks the state across block comparisons and can deal with keywords straddled across block boundaries etc.

Right now, the patch is turned on by default. This behavior can be controlled via a new option that we have added to CVSROOT/config: “IgnoreKeywordDiffsAtCommit”. If set to “no” it will switch back to the old semantics, just in case someone needs that. The patch also builds a new executable “kwdiff” that can be used for comparing checked-out files such that keyword differences can be ignored. This is useful when comparing files between two users each with their own sand-box. It is also used for unit testing the implementation(see below).

As part of the patch, we have added new tests to sanity.sh. We have also fixed testcases that were expecting the old behavior (spurious revisions). To test the algorithm for every possible corner case, we have also devised a unit test that generates millions of test file permutations. These are perl based and we didn’t integrate them into sanity.sh as it would change the standalone nature of the script. Memory tools like valgrind have been run on the patch to ensure there are no memory errors.

In the future, it may make more sense to create a unit test subdir for testing components of cvs (as opposed to the full cvs executable), in which case the kwdiff unit tests could be checked in there.

This patch enables the keyword sensitive diff algorithm only during commits, but the CVS community may want to consider it for updates, especially to reduce unnecessary keyword related conflicts during branch merges. Given how the code is structured it is relatively easy to turn on and off the keyword canonicalization algorithm for other cases beyond commits. Today CVS reads the entire RCS file into memory for many operation. This increases the footprint of the CVS process and can be a scalability bottleneck. The file chunk management code in kwfilecmp.c shows that it is possible to operate on a block basis, thus bounding the footprint of the cvs server process, regardless of the size of the file being processed. Perhaps, in the future, this module could be re-used for eliminating the need to read in the entire file into memory for many CVS operations.

The patch has been developed off the 1.11.21 branch. It can easily be enhanced for the feature branch to take into account local keyword aliases. This will require changes to a single function ( is_valid_keyword).

Attached bzip2 file contains the kwdiff.patch (actual patch) and the kwdiff-unit-test/ subdir.

We hope the CVS community will find the patch useful.

The cvs1.12.13 tree’s zlib.c has compatability problems with several Java based cvs clients – SmartCVS, WANdisco, JetBrains Ideaj etc. This manifests via cvs commands will hang for some files. See the bundled test file (add.c from cvs src dir)

We have tested with cvs1.11 tree right upto 1.11.21 and has no problems interoperating with the cvs server’s zlib implementation.

To further confirm the issue we tried with all the zlib levels and the incompatability remains.

We recompiled with cvs 1.12.12 src with the –with-external-zlib and dynamically linked the default libz.so on Gentoo and Red Hat Linux distros (1.1.4) and that works like a charm. While running configure we noticed :

checking selected ZLIB… external
configure: WARNING: Package ZLIB is more recent than requested external version
(1.2.2 > 1.1.4). configure with the –without-external-zlib
option to select the more recent version.
checking that ZLIB library works… yes

Seems like CVS is using 1.2.2, so we downloaded the latest zlib versions (1.2.3) from http://www.zlib.net/ and tried it with the cvs 1.12.12 src. Again no problem, all works like a charm.

This seems to suggest the 1.2.2 version bundled is broken. It may be a good idea to move to 1.2.3 on the cvs1.12. tree.

Also attached is a testcase tar ball. It includes:

• Ethereal sniff of the client – server traffic when the zlib hang happened
• the src file (add.c) that caused the problem
• The cvs server tmp dir with the partially read (by the cvs pserver process) add.c file
• The repository RCS file
• An strace capture of the cvs pserver process when it got hung sucking in the zlib6 compressed add.c file

Hope this provides enough information to debug 1.2.2 zlib, it might be just simpler to migrate to newer zlib (1.2.3)

–
Regards,
Rahul Bhargava
CTO, WANdisco,Inc

I have been benchmarking Java NIO with various JDKs on Linux. Server is running on a 2 CPU 1.7 GHz, 1GB RAM, Ultra160 SCSI 36GB disk

With Linux kernel 2.6.5 (Gentoo) I had NPTL turned on and support for epoll compiled in. The server application was designed to support multiple disptach models :

1. Reactor with Iterative Disptach with multiple selector threads. Essentially the accepted connections were load-balanced between varying number of selector threads. The benchmark then applied a step function to experimentally determine the optimal # of threads and connection per selector ratio.
2. Also a simple concurrent blocking disptach model was supported. This is essentially a reader thread per connection model.

Client application opens concurrent persistent connections to the server and starts blasting messages. Server just reads the messages and does basic un-marshalling to ensure message is ok.

Results were interesting:

1. With NPTL on, Sun and Blackwidow JVM 1.4.2 scaled easily to 5000+ threads. Blocking model was consistently 25-35% faster than using NIO selectors. Lot of techniques suggested by EmberIO folks were employed – using multiple selectors, doing multiple (2) reads if the first read returned EAGAIN equivalent in Java. Yet we couldn’t beat the plain thread per connection model with Linux NPTL.
2. To work around not so performant/scalable poll() implementation on Linux’s we tried using epoll with Blackwidow JVM on a 2.6.5 kernel. While epoll improved the over scalability, the performance still remained 25% below the vanilla thread per connection model. With epoll we needed lot fewer threads to get to the best performance mark that we could get out of NIO.

Here are some becnhmark results:

Concurrent Persistent Connections	Is blocking server	Number of server threads	Connections handled per thread	Thruput of the server (tps)
1700	N	2	850	1379
1700	N	4	425	1214
1700	N	8	212	1240
1700	N	16	106	1140
1700	N	32	53	1260
1700	N	64	26	1115
1700	N	128	13	886
1700	N	256	6	618
1700	N	512	3	184
1700	Y	1700	1	1737

As you can see the last line indicates vanilla blocking server (thread per connection) produced the best thruput even with 1700 threads active in the JVM.

With epoll, the best run was with 2 threads each handling around 850 connections in their selector set. But the thruput is below the blocking server thruput by 25%!

Results shows that the cost of NIO selectors coupled with OS polling mechanism (in this case efficient epoll VS selector/poll) has a significant overhead compared to the cost of context switching 1700 threads on an NPTL Linux kernel.

Without NPTL of course it’s a different story. The blocking server just melts at 400 concurrent connections! We have run the test upto 10K connections and the blocking server outperformed NIO driven selector based server by same margin. Moral of the story – NIO arrives at the scene a little too late – with adequate RAM and better threading models (NPTL), performance gains of NIO don’t show up.

Sun’s JVM doesn’t support epoll() so we couldn’t use epoll with it. Normal poll() based selector from Sun didn’t perform as well. We needed to reduce the number of connections per thread to a small number (~ 6-10) to get comprabale numbers to epoll based selector. That meant running lot more selector threads kind of defeats the purpose of multiplexed IO. The benchmarks also dispell the myth created by Matt Welsh et al (SEDA) that a single threaded reactor can keep up with the network. On a 100Mbps ethernet that was true: network got saturated prior to server CPUs but with > 1Gbps network, we needed multiple selectors to saturate the network. One single selector’s performance was abysmal (5-6x slower than
concurrent connections)

For application that want to have fewer number of threads for debuggability etc, NIO may be the way to go. The 25-35% performance hit may be acceptable to many apps. Fewer threads also means easier debugging, it’s a pain to attach a profiler or a debugger to a server hosting 1000+ threads . Bottom line with better MT support in kernels (Linux already with NPTL), one needs to re-consider the thread per connection model