It is true that the persistent state can get corrupted, and this is a major pain especially on a device which has to be able to reboot without human intervention. I sometimes (idly) ask myself if the frameworks could not do more to prevent this, i.e. to ensure that the state is always consistent after a reboot. However such corruption should happen only rarely, and can be dealt with when it happens. A database can also occasionally get corrupted, but we still don't reconstruct it from scratch each time just in case.
The most common cause of corruption in the case of an OSGi framework is that the Java process was terminated abruptly, by a 'kill' command or the notorious "OOM killer". In the former case the question arises "why are you doing that?" - sounds like you have a serious deadlock or memory leak in your code which you need to deal with. The OOM killer used to be mainly a problem on embedded devices but now it is turning up in the "cloud" - don't overbook memory is the short answer. Other common causes are disk full and sudden removal of power - these too used to be mainly a problem of embedded but they can also turn up in cloud computing. In both cases your OSGi persistent state is probably not the only thing which has been corrupted, so you need a recovery strategy anyway. Do you actually regard the persistence of e.g. bundle state and configurations in OSGi as a misfeature, even when it works? Is the idea that a system should start up in the state in which it was last shut down fatally flawed in your view? Best regards Chris > Hello, it might be a anti-pattern for some. For others it is a > anti-pattern to have a persistent (corruptable) state location required > and used by the framework when the actual application bundles deliverable > try to need no state, persistence and low permission. > > The frameworks I have looked at (and Equinox is a particular unflexible > example) make this hard for deployers. So deleting the directory (or > starting with -clean) is not always an anti-pattern it is also a symptom > for a unsatisfied need to trade startup speed against robustness. > > greetings > Bernd > -- > http://bernd.eckenfels.net > > ----- Ursprüngliche Nachricht ----- > Von: "[email protected]" <[email protected]> > Gesendet: â13.â08.â2014 22:29 > An: "OSGi Developer Mail List" <[email protected]> > Betreff: Re: [osgi-dev] bundle.getDataFile(string) > > Marcel wrote: > >>> If you ask me, it definitely is. I know a lot of people kill the bundle >>> cache on every startup and re-install all bundles each time, but I >>> would >>> advocate that that is bad practice in OSGi. > > Hear hear. In fact if there are anti-patterns out there then this is one > of them - and not just because of getDataFile. > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
