Announcement Announcement Module
No announcement yet.
Bundle restarting unexpectedly Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bundle restarting unexpectedly

    I have several plugin bundles, which are used by a rule execution framework. Basically this architecture means, that the plugin bundles export some packages and the framework bundle imports them using DinamicImport-Package, because it cannot know the set of packages beforehand.

    The problem is, when I deploy or redeploy a plugin, the framework bundle is many times (but now always) restarted. This is quite unexpected behavior for me, I couldn't find any mention of a bundle being restarted because another one has been started neither in springsource server docs, or osgi specs. Does anyone have a clue why this could be happening?

    here is the manifest of the framework bundle and one of the plugins:
    Bundle-ManifestVersion: 2
    Bundle-Name: fps-batch-process-osgi
    Bundle-SymbolicName: sk.dvsk.dvg.fps.fps-batch-process-osgi
    Bundle-Version: 0.2
    Bundle-Activator: sk.dvsk.dvg.fps.batch.process.main.PluginInstallList
    Import-Package: javax.sql,javax.activation,,org.osgi.f
    Export-Package: sk.dvsk.dvg.fps.core.jaxb2
    DynamicImport-Package: sk.dvsk.*
    Import-Library: org.springframework.spring.instrumented,org.hibernate.
    Bundle-ClassPath: .,lib/jaxb-impl-2.1.11.jar,lib/jaxb-api-2.1.jar,lib/
    Bundle-ManifestVersion: 2
    Bundle-Name: jaro-winkler-plugin
    Bundle-SymbolicName: sk.dvsk.dvg.fps.jaro-winkler-plugin
    Bundle-Version: 0.0.1
    Import-Package: javax.sql,javax.activation,,org.a
    Export-Package: sk.dvsk.dvg.fps.jaro.winkler.plugin,sk.dvsk.dvg.fps.ja

  • #2
    This behaviour is to be expected. Let me explain.

    When a class load in the framework bundle is satisfied by a dynamically imported package, OSGi records a dependency on the exporting bundle. If that bundle is undeployed or updated then, when refreshPackages is driven (under the covers, by dm Server), the framework bundle will be restarted in order to clean up its "old" dependencies.

    If you want to avoid this behaviour, it would be better to design your system so that the framework bundle uses Spring DM to depend on services published by the plugin bundles. You would need to define the dependency as "optional" (refer to the Spring DM reference for how to spell that. IIRC it's in terms of a cardinality of 0..1 or something similar). The framework bundle, or some other bundle(s) other than the plugin bundles, would need to define the types of these services to avoid the same dependency issue above recurring. Spring DM's service damping behaviour would then allow these services to come and go at runtime as your plugins come and go.

    If you don't want to go quite that far, you may be able to get some mileage out of having the plugin bundles register themselves using a package exported by the framework bundle so that the framework bundle doesn't depend (even dynamically) on the plugins and get impacted when plugins come and go.

    Hope that helps. It sounds like an interesting application.


    • #3
      Thanks for your reply!
      I thought about using service registry for exposing the plugins, it would be much nicer. Unfortunately I'm not using classes from the plugins directly. Inside the framework bundle we have embedded on the classpath the Drools rules engine. The engine is compiling rules files, which reference classes that are in the plugins. This means I can't control how the classes are accessed, all I can do is make them available on the classpath.
      The biggest problem which happens when the framework is restarted many times, that we run out of permgen space. That means we either have a memory leak (it starts a lot of threads, some may not be stopped properly), or we are running into the Sun JVM permgen memoryleak bug (there are a lot of classes in the framework bundle). The easiest sollution to both possible problems would be if I could avoid restarting the bundle, but still making classes available on the classpath from various packages. Maybe it would be possible to put all the public classes of the plugins into the same package, but even that is problematic, because this is an already working project which we only want to enhance with dynamic behavior, so refactoring all the plugins wouldn't be a very popular idea...
      What do you think, do I have some options (even some dirty hack) how to resolve this without changes to the code, or do I have to start thinking about more drastic measures?


      • #4
        Hmmm. It seems that you need the hard (dynamic) dependency on the plugins. Updates to plugins really do need to update the framework to pick up the new classes.

        So unless you come up with a drastic solution, it may be worth checking the reason for the permgen leak. We use YourKit to track down that kind of issue.

        Good luck!


        • #5
          Can't I use a custom classloader? I can set one for the rule engine. Can't I do something tricky from there? Restarting the framework has other problems than the permgen leak (it takes too much time).


          • #6
            Sure you can use custom class loaders! I use the plural because it seems you need class reloading, so one custom class loader is insufficient.


            • #7
              That sound great and also difficult

              Could you point me in the right direction how to do it? I'm getting quite good at osgi but frankly I don't have a clue how to do this...

              Should I ommit DynamicImport-Package entirely, and somehow load the classes by "hand"? Or should I keep that one, and with my own classload I can prevent restarting the framework? Why do I need more than one classloader?

              Thank you very much for your help so far, I hope I'll have all the info I need soon. Then I will post my sollution here, so everyone can benefit


              • #8
                It depends so much on the rules engine and whether you can persuade it to use a custom class loader for each rules file. Then you might be able to isolate the bulk of the framework from impacts when a plugin is updated.

                It's not particularly clear how you should proceed. I'm afraid I can't really help you further as it would take more time than I have.