Re: Bug + Patch (Intersync 0.9.5)

>> The patch I posted does not solve all problems.
>> It does not work when the permit is revoked by
>> the server (after revoking from client B holding
>> permit) and the server is not yet informed of
>> KML waiting at client B. When this happens,
> the server sends an outdated value of kml offset
> (using JOB_SEND_KMLSIZE).
>
>If the server and client B are not disconnected, can't we revoke the
>permit syncronously with sending of the KML offset? Maybe even by
>putting the permit revocation ack in the same packet as the kml offset?

Without new calls:

a) on client B, to synch revoke_permit with server_has_fetched_KML
does not seem possible because client B does not know when server
fetches KML (KML is fetched directly by http://.....cache/KML_file;
that is, not passing through cgi calls)

b) on server, to sync revoke_permit with client_has_no_more_KML
is also impossible because client B puts KML notifications in
job queue and server does not know when queue is empty.

Possible solutions:

a) implement new call from server to client B that blocks
until all client_B_KML_notifications have been sent out
by client B (i.e. flush job queue). This call should
return the client KML offset, and be used by server to
block revoke_permit until server has received all expected
KML. Then, the server can send a confirmed kml_offset to client B
to update lr_remote_offset correctly.

b) for better perf, we could allow revocation to proceed
while KML is fetched by server. This seems more complex.
Also, we have to make sure that permit is not given back
to client B before all client_B_KML is fetched and
lr_remote_offset is updated.


Before trying to implement any of these, I would prefer
to have advice from original programmers ... (to avoid
waisting time)


> Also, I'd recommend anyone who wants to get some ideas of the problems
> with disconnected operation and resolving conflicts look at Bitkeeper,
> and in particular, the way some of the PowerPC linux kernel people use
> it. Bitkeeper has a reasonably well thought out model for this kind if
> stuff.

> (On another note, some days I wonder if I'll eventually wind up
> violating Bitkeeper's "you can't develop a competitor to bitkeeper"
> license if I work on intermezzo enough)


I'll have a look at bitkeeper !





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com