Community
Participate
Working Groups
Build Identifier: I would like to specify DeploymentOptions.synchronous = false during "deployer-recovery". I believe that is the way initial deployment happens (i.e. -clean or empty recovery log). I would like to do that because I have number of plan files and dependencies on services between them. But because of the naming scheme the one that imports comes before plan that exports. That forces me to always deploy with -clean right now. I would not mind modifying the dm-server code if need be to get this options configurable. Discussion: http://forum.springsource.org/showthread.php?t=84529 patch here: http://forum.springsource.org/showthread.php?t=84529&page=2 Reproducible: Always
Thank you Dmitry. We think this would be a worthwhile modification. We are of the opinion that the code patch you sent us is on the right lines: 1) modify the format of the log to preserve the 'synchronous' deployment option (yes or no) 2) augment (unit) tests to check the synchronous option is preserved on the log The outcome would be that artefacts deployed asynchronously and recovered (on a non-clean start) would be re-deployed during recovery asynchronously -- instead of synchronously as at present. The artefacts deployed asynchronously at the moment are those put in the pickup directory or those explicitly deployed with this option on the deployment api (i.e. programmatically). I refer to the patch supplied in the thread: > Discussion: http://forum.springsource.org/showthread.php?t=84529 and make the following comments: 1. The patch is for an older version of dm Server; would it be easy to rework this for a version of Virgo? 2. The log format is made more complex than it need be, and it would be a service to simplify this a bit: a. Can you avoid using a suffix indicator? b. There is no requirement for backward log format compatibility, so we could make the options independently specified in the format. For example YNY, YYY, NNY, YNN, YYN could be the option 'commands' for Recoverable(Y|N), Owned(Y|N), Synchronous(Y|N), in the various combinations and use '---' for the UNDEPLOY_URI_COMMAND case. This would mean that they were always 3-chars long, and the code for getCommandString() could be made much simpler and easier to read. Glyn has suggested that Y|N is a bit cryptic when peeking at the recovery log using an editor, so I'll leave you to think of a better fixed format. (R|N) (O|N) (S|A) perhaps? In any case the format is entirely self-contained in this area of code, so we have a free hand. Finally, if there are references in the documentation you can dig out that would be helpful. We could draft some changes there between us. Steve Powell
I decided to go with format of "'commands' for Recoverable(Y|N), Owned(Y|N), Synchronous(Y|N)" This can be javadoced and documented and we can even add a header in the file to explain i.e.: #'commands' for Recoverable(Y|N), Owned(Y|N), Synchronous(Y|N). I honestly don't think there will be a lot of people looking in that file with a text editor.
Created attachment 174926 [details] Fix for deployer recover log patch.
I wrote 100% of the code contributed, and have the right to contribute the code to Eclipse
(In reply to comment #4) Brilliant, Dmitry. I'm looking at the patch in detail now.
Your patch (with a couple of trivial modifications) is now pushed to org.eclipse.virgo.kernel.git. Thank you for this enhancement; especially for the test modifications you put with it. Here is the commit header. sha1: 77913bed42425fda2f4ca5c9a836eb6c86a27348 Author: Steve Powell <spowell@vmware.com> Date: Thu Jul 22 2010 17:21:43 GMT+0100 (BST) Subject: Patch to preserve synchronous deployment option in recovery log. This contribution will be visible on the IPLog for the project.
There is an error (my fault) in the commit. It should have had Author: Dmitry Sklyut <dmitry@dsklyut.com> in the git repository commit. This is because I forgot the git option. Apologies. Please confirm you will allow this to remain so as the commit is now pushed and fixing it will be time consuming and error-prone.
(In reply to comment #7) > Apologies. Please confirm you will allow this to remain so as the commit is > now pushed and fixing it will be time consuming and error-prone. That is perfectly fine. Thanks!
Closed with permission of raiser.
