7 Replies Latest reply on Mar 25, 2015 2:52 PM by jokser

    Don't startup service bindings automatically


      Hi everyone,


      Excuse me, but it's my third theme about Switchyard ha singleton service . Previous themes are:

      HA singleton service with JPA binding

      Programmatically getting SwitchYardCamelContext or ServiceDomain instances


      Finally, I have implemented ha-singleton service, but there is one problem. Service bindings starts automatically during deployment process and for correct work of ha singleton before all I need stop them and then activate ha singleton service which will manage this bindings remotely (via MBeanServer). In the current situation I need wait for finish of deployment process, stop all bindings on every node in service which I marked as singleton and then start bindings again on one (master) node using ha singleton service.

      Currently I can't do it, because I don't know when deployment process finishes.

      But there is one solution which make my life much easier. E.g. mark service with attribute autoStartup=false or disableAutoStartup=true, and check this option in deployment process before operation handler.start(). But in current version of Switchyard there is no such possibility. I know how to do it and I can do it. But I need make changes in switchyard-core source.

      I want to appeal to community. Can I create issue and then make commit (git pull request)? Or you think this feature is not need and I have to patch Switchyard with my changes with every release?

        • 1. Re: Don't startup service bindings automatically

          This could be an interesting enhancement.  Some considerations:

          • Do you need this flag on each service or would it be better as a domain property (i.e. application-wide) instead?
          • If you need service-level granularity, does it apply to an entire service or just a specific binding on that service?
          • Is there any reason why this should apply to reference bindings?  I can't see how this would be useful at this stage.


          In terms of making a contribution, here's what I would do:

          • File a JIRA requesting the enhancement.
          • Issue a PR for the repositories impacted by your change.
          • Note the PR in the issue and post back to the forum for comments.


          This might help as well:

          Development on SwitchYard

          • 2. Re: Don't startup service bindings automatically

            Hi Keith,


            Thank you for reply. I also asked myself these three questions. I think flag autoStartup=false (with default "true" value) should be applied to each binding for flexible customization. But also services should have disableBindingsAutoStartup flag which overrides similar flag for bindings in case of large number of bindings. For reference bindings this flag does not make sense, because any exchange to reference binding will automatically wake up his Camel route.


            Currently I have necessary changes in switchyard-core deploy module and switchyard-component-common-camel module. I just have to make changes in XSD-schemas for switchyard maven validation plugin and create appropriate unit tests.


            Will wait your JIRA issue.

            • 3. Re: Don't startup service bindings automatically



              I think Keith is suggesting that you go ahead and file the JIRA yourself - you are essentially creating the feature, so you know the requirements best.   The JIRA report doesn't have to be super detailed, but if you can summarize what you said here and link to the discussion thread here, that'd be very useful.


              The one thing I would note is that if you're already adding this feature at the binding level and the service level, it probably also makes sense to add it at the domain level like Keith suggests.



              • 4. Re: Don't startup service bindings automatically

                Oh, I'm sorry. I misread the phrase "here's what I would do" as "I will do" .


                Ok, I will test this feature on domain level also and prepare JIRA request and PR on weekends.


                Thank you for explanation.

                • 5. Re: Don't startup service bindings automatically

                  I have created the issue and sent 2 PR.

                  • 6. Re: Don't startup service bindings automatically

                    Hi Pavel,

                    This is your JIRA ([SWITCHYARD-2580] Make it possible to don't startup service bindings automatically - JBoss Issue Tracker) for others reference.


                    I now I'm facing a similar requirement, in that I need to do an upgrade of my application (a very big application) and I want it to be deployed on stopped mode, so everything is properly deployed before starting the bindings (to do a proper software upgrade as a rolling update). We're using SOAP, JMS, SCA (non-clustered), Quartz, FTP,... and we don't want to start things up before everything gets properly deployed, as it will generate many errors.


                    Have you tested your PR? Is it working fine? What issues have you found?


                    I have voted to incorporate it into next release, as this is a very interesting feature to be able to update systems in production.


                    And yes, we are not using clustered SCA (don't really like how it works on SY 1.1 as it uses HTTP transport always) and we can't use mod_cluster for doing a rolling upgrade as we have many bindings that would start consumption as they are not HTTP based and not balanced with mod_cluster (like timers, file/ftp, jms,...).

                    • 7. Re: Don't startup service bindings automatically

                      Hi Jorge,


                      Yes, I have tested it. It works well. So now I manage bindings lifecycle via MBeanServer by your earlier recommendations without any problems. I have faced with one issue described here: Re: Programmatically getting SwitchYardCamelContext or ServiceDomain instances . But it can be easily solved by first comment on the issue page.