Hi Jayanga and Ruwan, > Can we look into a way this can be triggered selectively with some > command-line option or an offline command? Reason to keep this logic from > slowing down the startup in production run.
+1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter. WDYT? Best Regards, Vidura Nanayakkara On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi Ruwan, > > Thanks for the comments. > > In every server startup, it checks the files list in the > [product_home]/lib to check whether there are any changes to the files. > Yes, we could save some 'time' in the server startup if we provide a > separate tool. But there is a possibility that someone would miss running > that script and expect the new changes. Anyway, I'll check on the > possibilities of minimizing startup time taken. > > Regarding the checkpointing thing, the suggested approach keep the > original bundles.info file as a backup and always update it with the > bundles given in the [product_home]/lib. And we haven planned on keeping > the historical changes. Hence it will always be from original state to > latest state change. > > Thanks, > Jayanga. > > > *Jayanga Dissanayake* > Associate Technical Lead > WSO2 Inc. - http://wso2.com/ > lean . enterprise . middleware > email: jaya...@wso2.com > mobile: +94772207259 <+94%2077%20220%207259> > <http://wso2.com/signature> > > On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote: > >> + 1 on the idea of the four steps mentioned. >> Can we look into a way this can be triggered selectively with some >> command-line option or an offline command? Reason to keep this logic from >> slowing down the startup in production run. >> >> In addition to that, in future, we could able to enhance the same logic >> to allow similar behavior like "windows System Restore Point" or "OSX time >> machine" to revert to known point of WUM, by version controlling the >> bundle-info and the respective jars/configs. >> >> Cheers, >> Ruwan >> >> On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <jaya...@wso2.com> >> wrote: >> >>> Hi All, >>> >>> Existing OSGi deployment logic [1] keep updating the bundles.info file >>> as and when a bundle is added/removed from the [product_home]/lib directory. >>> >>> 1. It first read the bundles.info file of the current runtime >>> 2. Then take the list of bundles coming from "plugins" directory. >>> 3. Adds the bundles in the [product_home]/lib directory to the previous >>> list >>> 4. Get distinct bundles based on the bundle symbolic name and version. >>> (ignores bundles with same symbolic name and version already in the list, >>> hence bundles in the plugins directory get the priority) >>> 5. Update the bundles.info file >>> >>> The above-mentioned approach assumes all basic bundles for the runtime >>> coming from the "plugins" directory and adds the external bundles on top of >>> it. >>> >>> Recently we were looking into the C5 update/patching model and there was >>> a concern on how we could add a temporary log patches, etc. to identify an >>> issue. (in a case where all other possibilities failed). >>> >>> The most convenient to the client is to just add the given log patch to >>> the pack, restart, collect the relevant logs, and finally revert the log >>> patch. Any additional steps would be an overhead as the client is already >>> undergoing a severe issue and client is trying to help us to identify the >>> issue by applying the log patch. Hence this should be modeled in a >>> convenient way to the users. >>> >>> There is a possibility to let the clients add the log patch into the >>> [product_home]/lib directory and remove it once done. But with the current >>> OSGi bundle deployment logic, we can't do that as it always gives the >>> priority to the bundles in the plugins directory. If we put a bundle with >>> the same bundle-symbolic-name and version into the plugins directory it >>> will be ignored. >>> >>> To achieve this behavior we have to modify the existing OSGi bundle >>> deployment logic as follows. >>> >>> 1. In the first run make a backup of the original bundles.info file >>> (bundles.info.original this will be used as the baseline for each time it >>> updated the bundles.info file) >>> 2. Read the bundles.info.original file >>> 3. Add the bundles in the [product_home]/lib directory >>> 4. Update the bundles.info file >>> And >>> The logic in selecting effective bundles list should be changed to not >>> to give priority to bundles in the plugins directory. Instead modify the >>> entries, if a similar bundle (symbolic name and version) is found in the >>> [product_home]/lib >>> >>> Above suggested approach allows easily add the patched jars into the >>> [product_home]/lib directory for temporary purposes. And reverting the >>> patch is also possible as we have a backup of the original bundles.info >>> file >>> >>> WDYT? >>> >>> [1] https://github.com/wso2/carbon-kernel/blob/v5.2.0-m3/lau >>> ncher/src/main/java/org/wso2/carbon/launcher/extensions/OSGi >>> LibBundleDeployerUtils.java >>> >>> Thanks, >>> *Jayanga Dissanayake* >>> Associate Technical Lead >>> WSO2 Inc. - http://wso2.com/ >>> lean . enterprise . middleware >>> email: jaya...@wso2.com >>> mobile: +94772207259 <+94%2077%20220%207259> >>> <http://wso2.com/signature> >>> >> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Associate Director/Architect**,* >> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >> *lean.enterprise.middleware.* >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
