Dear Saros developers,
as you might know, I worked on some inconsistencies occurring during an
invitation. I uploaded several patches and want make reviewing easier
for you with this email.
These are the related SourcForge bug entries:
* 3541540Activity queuing is broken during synchronization
* 3458952 File changes during Invitation corrupts session
* 3512804 Inconsistency after an invitation
Basically all observations described in those entries occur after a
participant works on files during an invitation. In short:
1. Needs-Based-Sharing feature, especially the Pre-Sharing part, is not
implemented correctly.
* The host is confused by a wrong dialog
* Inconsistencies can occur
2. The queuing of Activities during an invitation is not working correctly
* Activities are lost
* Inconsistencies can occur
3. If inconsistencies occur, the watchdog can either not detect them or
not resolve them
*[FIX] #3458952 File changes during Invitation corrupts session*
* This patch fixes 1) by removing the Pre-Sharing feature. Pre-Sharing
means, that during an invitation the currently opened files are sent
directly using activities.
* Franz has already stated that it is ok to remove this feature if it
causes problems during the invitation process (see comments in
Gerrit and email on DPP-DEVEL)
*[STF] STF test for editing during an invitation process*
* I added the TestCase EditDuringInvitationTest with a test where Bob
invites Carl and Alice (the host) inserts text during an invitation
* I also added a stress test, where multiple files are edited during
an invitation
*[INTERNAL] FileZipper is not dependent on a monitor anymore*
* This patch is a preparation for the patches relating to the Activity
Queuing
* The basic idea was to remove the monitor logic from the util/FileZipper
* Now a ZipListener is passed to the zip functions instead of a monitor
* I took Stefan's patch since it was a lot simpler than mine
*[INTERNAL] multiple ZipListener can be passed to the zip functions*
* This patch extends the previous patch with the possibilities to pass
more than one ZipListener to the Zip functions
* This is important for the next two patches. The idea is, that there
will be two listeners during the zipping of a project:
o One just updates the monitor
o The second one updates a list with files which have already been
packed in the archive.
*[FIX] #3541540 Activity queuing is broken during synchronization - Part1*
* Before the patch:
o Only EditorActivities were queued during the invitation
* Now:
o All ActivitiyDataObjects, that are received in the exec() method
will be queued all the time, not only during the invitation process
o There are two types of Activites. Project independent (mostly
session related, e.g. ChangeColorActivity, ProgressActivity) and
project dependent Activities (e.g. File-, Folder- or
JupiterActivities)
o There is one Blocking Queue for each Project and one for the
project independent Activities
o For each BlockingQueue there is an ActivityDispatcherThread
which processes the queue.
* Why queue each Activity?
o So prevent the loss of Activites during the invitation
o Ensure that ActivityData objectsare converted after the projects
are completely shared, else an Exception would be thrown for
most of the Activities (e.g. JupiterActivities)
o --> Missing JupiterActivtiescause a violation of preconditions
in the Jupiter Algorithm (TransformationException)
* Result:
o With this patch the queuing could slightly be improved, but
there is one problem left:
+ Text inserted right before or during the zip process will
occur twice on Carl's side. The reason is: Activities
containing the Text are sent to Carl and he queues them.
They are also applied by the Alice (Host) before creating
the archive. Carl receives the archive containing the text
and after that he execute the queued Activities. This
problem is fixed in the next patch.
*[FIX] #3541540 Activity queuing is broken during synchronization - Part2*
* This patch fixes the problem described above.
* The idea is to keep track of all files, which have already been
packed to the archive. (see patch "Multiple ZipListerners...")-->
Activities relating to those files need to sent, all others don't
* Based on that information the host can decide, which Activities need
to be sent to the invitee
* If a JupiterActivity does not need to be sent, a empty
JupiterActivity is sent instead to make sure that the timestamps
stay consistent
* I also had to switch around executing and sending of activities
* The decision if an activity needs to be sent is made right before
sending
* The only problem is that this won't work if a non-host invites
another person, since the host has the "broadcast" function. I
talked to Franz about this. The first step would be to disable
invitation for the non-host. Later there could be a function where
Bob can ask Alice to invite Carl. After that the feature could be
implemented using some magic so that the third person invitation
will also work without any inconsistencies.
So that's it. If you have any questions feel free to ask. I hope this
makes reviewing the patches easier.
Best regards,
Sebastian
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Dpp-devel mailing list
Dpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
