7

i have a requirement where i need to reload my osgi bundles 4 times a day . Reloading a bundle means recreating static instance Beans , reloading camel routes , recreating and injecting thread pools ,database connection pools ..etc(other spring xml stuff) . I tried to refresh my bundles through ssh but i needed bundle id's for that which can change overtime . So , i wrote a Manager Bundle which gets the bundles by symbolic names and refreshes them 4 times a day 

          osgi impl : felix 

          container : apache-servicemix-4.4.1-fuse-03-06

          Service Dependency spec : Blueprint

There are 3 bundles along with a helper bundle .The helper bundle has all the common classes used and service interfaces . There is no code sharing among these 3 bundles (None of them export any packages ).All of them interact through camel vm endpoints and services . I only refresh the other 3 bundles and helper bundle doesn't provide any services .

Now, the problem is when ever i do an update on these 3 bundles they start up and work fine , but i see an increase of 800-900 classes on jconsole every time i do this . Forcing gc also doesn't seem to clean up these objects . So , what could these old wired objects be ? Service dependencies should get updated automatically and there are no code dependencies between the bundles .I checked the difference in the count of classes after and before the update .

i could see that count of some classes have doubled like org.apache.activemq.camel.component.VmComponent, org.apache.commons.dbcp.BasicDataSource..etc and some custom beans that i have defined in my camel routes . I am dependent on the container for camel-core,blueprint,quartz...etc .What exactly happens to the beans,VM endpoints..etc in camel-context and components defined in blueprint-config xml's on update . I know its recommended to call FrameworkWiring.refreshBundles() once you update the bundle . But, i have no code sharing between bundles and i presumed any other dependencies container should handle which i think is wrong now . And i am not sure if the current felix framework implementation in servicemix supports FrameworkWiring.refreshBundles() (ref) , i was not able to get it work . How can i fix this problem ?

Thanks sanre6

рüффп
  • 4,475
  • 34
  • 62
  • 99
sanre6
  • 787
  • 2
  • 11
  • 28
  • Do you have threads from the old bundle instance hanging around? – artbristol Apr 18 '12 at 07:54
  • yes , their count has doubled . Are you trying to say that i have to close my instances ,shutdown camel routes before updating the bundle? – sanre6 Apr 19 '12 at 06:01
  • We found the same issue. Switching to equinox implementation make this problem disappear, then I suspect an issue with Felix OSGI container. – рüффп Mar 10 '15 at 10:55

2 Answers2

1

In general, only invoking an update on bundles is not enough. You must at some point also refresh your packages. If everything is well-behaved, that should be enough to update all package wiring, effectively allowing old versions of the bundle to be garbage collected. However, if there is something in one of the bundles that does not behave well, and keeps a thread running or some resources around in a cache or something, you have to start tracking down the issue. Get yourself a good profiler, see what bundle and classloader these "extra" objects belong to and go from there.

Marcel Offermans
  • 3,294
  • 1
  • 13
  • 23
0

I don't know much about Camel but if you are providing the platform with runnables that refer to bundle classes, then you need to make sure they all get cancelled or otherwise destroyed on refresh, since the threads they're running in will hold a reference to the old Class instances (which are different from the Class instances of the new bundle, even though they are really the same). Hence, increasing class counts.

artbristol
  • 30,694
  • 5
  • 61
  • 93
  • my application is heavily dependent on the servicemix bundles and i believe the best practice is let container handle your dependencies , identifying all these dependencies and clearing them will be a lot of painful work .I am not even sure if you can remove the core osgi and and blueprint related dependencies before updating a bundle – sanre6 Apr 19 '12 at 06:53