felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Reich <jeanbaptiste.re...@gmail.com>
Subject Re: On demand bundle
Date Wed, 05 Jan 2011 10:13:44 GMT
Thanks for your answers.

In my case I just want to manage a subset of bundles that expose a certain
property at registration for example. They will be managed with an agent and
every managed bundle must be access with this agent (to start and stop and
refresh). So, just managing the state of these bundles will be enough for me
as the RESOLVED state unload the bundle from memory and that's my


2011/1/4 David Savage <david.savage@paremus.com>

> On Tue, Jan 4, 2011 at 10:53 AM, Jean-Baptiste Reich
> <jeanbaptiste.reich@gmail.com> wrote:
> > Hello,
> >
> > I would like to have on demand bundles in felix.
> > So, is there a mean to load bundles in memory only when needed and to
> remove
> > them when they are not necessary anymore with another bundle that acts as
> a
> > Manager.
> > With that it would be possible to precisely control the memory used and
> to
> > have policies like:
> >  - every bundle that stays inactive for 5 minutes is removed
> This depends on how you define "active" if your bundles provide
> services then it is possible to find out when the services are no
> longer in use but you have to do this yourself by registering a
> ServiceFactory instead of a Service - you then get a callback when
> services are discarded by clients - you can then do the reference
> counting and tidy up when there have been no services usages within a
> specified timeout. Though bundles uninstalling themselves is a hard
> thing to do so you'd probably want a management agent to do this on
> your behalf.
> If the client is a pure library however then I think this is basically
> impossible from the spec point of view as there is no way to find out
> when all references to the classes have been discarded. I put together
> some proof of concept code based on Richard Halls virtual bundles work
> [1] that would achieve a similar feature for the use case of garbage
> collecting bundles that provide marshalled classes - but I would guess
> that this will remain a proof of concept for some time.
> >  - limit the total number of loaded bundles
> This would be pretty easy to do if you have a management agent
> handling all the installs, but you'd have to make sure "there can be
> only one" management agent as there is no way in the spec at the
> moment to do a framework wide veto.
> >  - download from a repository a bundle to serve a request and remove it
> This sounds a lot like the sort of capabilities our product Nimble is
> designed to achieve - if you want to take a look there's a free
> download available and there's online docs here [2] [3].
> Hope that's of help.
> Regards,
> Dave
> [1] http://svn.apache.org/repos/asf/felix/sandbox/rickhall/vb/
> [2] http://www.paremus.com/downloads/downloads_nimble.html
> [3] https://docs.paremus.com//display/NIM20/Home
> >  ...
> >
> > Maybe this is possible by managing the bundle state in OSGi ? But I don't
> > know exactly when the bundle is concretely loaded into memory in felix...
> >
> > Regards
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message