3 Replies Latest reply: May 5, 2011 10:13 AM by 792002 RSS

    Stopping a bundle running on the CEP Server


      I am trying to figure out how a bundle can stop itself and then re-start due to some external error involving database or other network connections. At the same time, I don't want to affect the state of other running bundles that are independent of the bundle being stopped/restarted.

      Has anyone figured out a way to accomplish this?

      Thanks -- Jim Leary
        • 1. Re: Stopping a bundle running on the CEP Server

          This may be best done using another bundle, especially because of the restart requirement. You can use CEP's DeploymentServiceMBean to start/stop or suspend/resume the application bundle from the other management bundle.

          If the requirement was to just stop the bundle, you should be able to do it from the same bundle using DeploymentServiceMBean, but I haven't tried it yet.

          • 2. Re: Stopping a bundle running on the CEP Server

            Another option might be to try simply refreshing the application context. Each bundle registers an OSGi service that represents the application context, so you could find the one you are interested in and call refresh. e.g. by using this:

            <osgi:list cardinality="0..N" interface="org.springframework.osgi.context.ConfigurableOsgiBundleApplicationContext"/>

            against a method that looks something like this:

            public void setDeployedContexts(List<ConfigurableOsgiBundleApplicationContext> contexts) {
            this.deployedContexts = contexts;

            • 3. Re: Stopping a bundle running on the CEP Server
              Hi Andy,

              Thanks for the info. Does refreshing the ApplicationContext do the same thing as essentially "re-setting" the bundle? It looks like this would have to be done with an external bundle such as the idea that Manju mentioned previously.

              One thing that the product lacks (and which is why I'm trying to implement this manually via code) is a easy way to monitor and automatically re-start and/or failover bundles that become unstable for one reason or another, along with some sort of messaging that states this action has occurred.

              When you start getting into an architecture of running multiple bundles on one WLEVS instance as we do, having a finer-grain control and failover capability at the bundle level that is easy to implement and maintain would be useful. There's probably some OSGi magic that one could do here, but I'm not an OSGi expert so that would need to be defined and documented within the context of how the OCEP product operates.

              --Jim Leary