You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matt Tennant <mt...@4home.com> on 2010/07/07 23:01:39 UTC
RE: bundle cache version directories
Hi all,
I have a follow up question from this thread I started some time ago.
Since then, I have been trying out the following property and value:
org.osgi.framework.storage.clean=onFirstInit
Which appears to work well, and removes extraneous directories and files
from my bundle cache directory shortly after startup. Note that it
doesn't matter whether these directories and files were originally created
by Felix. If they are in the bundle cache directory, they are removed.
I also tried calling refreshPackages(null) on the PackageAdmin service
object at runtime. When I do this, the message "FrameworkEvent PACKAGES
REFRESHED" is logged. It may be doing something, but the behavior is not
the same as with the org.osgi.framework.storage.clean property.
Extraneous directories and files are not removed.
I was expecting the behavior to be the same between the two approaches.
Can somebody please explain the distinction? Is there runtime access to
the behavior that org.osgi.framework.storage.clean exhibits?
In case there is some confusion, I am not worrying about precisely the
same problem as in the original thread, but instead solving a problem
where occasionally old bundle caches are present for bundles that are no
longer in use.
Thank you,
Matt
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Thursday, June 03, 2010 12:00 PM
To: users@felix.apache.org
Subject: Re: bundle cache version directories
On 6/3/10 14:01, Matt Tennant wrote:
> That was a useful read, thank you. It leaves me with just one question:
> what triggers a framework refresh? (other than a startup/shutdown)
>
Explicitly calling PackageAdmin.refreshPackages(), which is done by
getting the PackageAdmin service or the Felix shell provides a "refresh"
command.
-> richard
> From this point onward I will make a note of whether I ever see
multiple
> version directories at a point in time when I should not.
>
> Thanks!
> Matt
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, June 03, 2010 5:50 AM
> To: users@felix.apache.org
> Subject: Re: bundle cache version directories
>
> On 6/2/10 19:20, Matt Tennant wrote:
>
>> Hi all,
>>
>>
>>
>> I have a question about the "versionX.X" directories inside the Felix
>> bundle cache. I am using Felix 2.0.0, and I often see something like
>>
> the
>
>> following in my bundle cache directory:
>>
>>
>>
>>
>>
>>> ls -l
>>>
>>>
>> bundle0
>>
>> bundle1
>>
>> ...
>>
>>
>>
>>
>>
>>> cd bundle0
>>>
>>>
>>
>>
>>> ls -l
>>>
>>>
>> version0.1
>>
>> version0.0
>>
>> bundle.location
>>
>> bundle.startlevel
>>
>> bundle.lastmodified
>>
>> bundle.id
>>
>> bundle.state
>>
>>
>>
>>
>>
>>> ls -l version0.0
>>>
>>>
>> bundle.jar
>>
>>
>>
>>> ls -l version0.1
>>>
>>>
>> bundle.jar
>>
>>
>>
>> What I mean to be pointing out here are the two "bundle.jar" files in
>>
> two
>
>> different "versionX.X" directories in the cache area for one bundle.
>>
> What
>
>> is the reason that I might get more than one of these? How can I avoid
>> that? I have limited space on the device our product runs on, and even
>> the size of these jar files can make a difference.
>>
>>
>>
>> Note that I am using the autodeploy feature with actions
>> "install,start,update". Sometimes the original bundle jars in the
>> autodeploy directory change from one run to the next.
>>
>>
> You might want to read:
>
>
http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>
> Typically, what you are seeing is the result of doing updates. However,
> typically the extra JAR files should be deleted after a refresh.
>
> Starting with "install,start,update" causes the update, but generally
> i'd assume you'd autorefresh during startup so you wouldn't see
> additional JAR files. Perhaps you could verify that refreshing is
> deleting the JAR files. If so, you could verify that they are
> automatically getting deleted on startup.
>
> By and large, after your framework starts I'd expect there to be no
> additional JAR files and after it stops I'd expect there to be no
> additional JAR files too. At run time, it just depends on whether you've
> updated and not refreshed yet.
>
> -> richard
>
>
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bundle cache version directories
Posted by Guillaume Nodet <gn...@gmail.com>.
Could you please raise a JIRA issue at
https://issues.apache.org/jira/browse/KARAF ?
On Thu, Jul 8, 2010 at 00:18, Chris Blunck <ch...@thebluncks.com> wrote:
> It would also be beneficial to know if it's possible to avoid caching
> feature files.
>
> It's quite common for someone to change the configuration section of a
> feature file in the deploy directory and restart only to have their changes
> ignored because the feature file has been cached. Having a startup flag
> that says "don't cache features" that the bundle deployer would honor would
> be most helpful.
>
>
> -c
>
> On Wed, Jul 7, 2010 at 6:12 PM, Matt Tennant <mt...@4home.com> wrote:
>
>> I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
>> doing. It turns out that it is deleting the entire bundle cache directory
>> and starting from scratch. I thought it was simply removing unused files
>> and directories, which is less useful to me. I guess I was doing some
>> wishful thinking.
>>
>> So I guess I should ask a new question. Is there support for what I
>> thought that option was doing? Basically, I want the caches for bundles
>> that are still in use to survive, but anything else, especially caches for
>> uninstalled bundles, to get removed.
>>
>> Some background: I cannot just nuke the bundle cache directory because
>> some bundles have been previously installed from remote URLs, and I cannot
>> repeat that operation every time the framework starts up. Bundles
>> previously installed this way must be preserved. Also, a few times we
>> have seen bundle cache directories get extremely bloated with caches for
>> bundles that are no longer installed. On an embedded device this is
>> catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
>> problem, but it's hard to test for sure because the problem has not been
>> easily repeated. I have a workaround the looks for these directories
>> manually, but the workaround is very Felix-specific and I try to avoid
>> that sort of thing.
>>
>> Thanks for any help,
>> Matt
>>
>> -----Original Message-----
>> From: Matt Tennant [mailto:mtennant@4home.com]
>> Sent: Wednesday, July 07, 2010 2:02 PM
>> To: users@felix.apache.org
>> Subject: RE: bundle cache version directories
>>
>> Hi all,
>>
>> I have a follow up question from this thread I started some time ago.
>> Since then, I have been trying out the following property and value:
>> org.osgi.framework.storage.clean=onFirstInit
>>
>> Which appears to work well, and removes extraneous directories and files
>> from my bundle cache directory shortly after startup. Note that it
>> doesn't matter whether these directories and files were originally created
>> by Felix. If they are in the bundle cache directory, they are removed.
>>
>> I also tried calling refreshPackages(null) on the PackageAdmin service
>> object at runtime. When I do this, the message "FrameworkEvent PACKAGES
>> REFRESHED" is logged. It may be doing something, but the behavior is not
>> the same as with the org.osgi.framework.storage.clean property.
>> Extraneous directories and files are not removed.
>>
>> I was expecting the behavior to be the same between the two approaches.
>> Can somebody please explain the distinction? Is there runtime access to
>> the behavior that org.osgi.framework.storage.clean exhibits?
>>
>> In case there is some confusion, I am not worrying about precisely the
>> same problem as in the original thread, but instead solving a problem
>> where occasionally old bundle caches are present for bundles that are no
>> longer in use.
>>
>> Thank you,
>> Matt
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Thursday, June 03, 2010 12:00 PM
>> To: users@felix.apache.org
>> Subject: Re: bundle cache version directories
>>
>> On 6/3/10 14:01, Matt Tennant wrote:
>> > That was a useful read, thank you. It leaves me with just one question:
>> > what triggers a framework refresh? (other than a startup/shutdown)
>> >
>>
>> Explicitly calling PackageAdmin.refreshPackages(), which is done by
>> getting the PackageAdmin service or the Felix shell provides a "refresh"
>> command.
>>
>> -> richard
>>
>> > From this point onward I will make a note of whether I ever see
>> multiple
>> > version directories at a point in time when I should not.
>> >
>> > Thanks!
>> > Matt
>> >
>> > -----Original Message-----
>> > From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> > Sent: Thursday, June 03, 2010 5:50 AM
>> > To: users@felix.apache.org
>> > Subject: Re: bundle cache version directories
>> >
>> > On 6/2/10 19:20, Matt Tennant wrote:
>> >
>> >> Hi all,
>> >>
>> >>
>> >>
>> >> I have a question about the "versionX.X" directories inside the Felix
>> >> bundle cache. I am using Felix 2.0.0, and I often see something like
>> >>
>> > the
>> >
>> >> following in my bundle cache directory:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> ls -l
>> >>>
>> >>>
>> >> bundle0
>> >>
>> >> bundle1
>> >>
>> >> ...
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> cd bundle0
>> >>>
>> >>>
>> >>
>> >>
>> >>> ls -l
>> >>>
>> >>>
>> >> version0.1
>> >>
>> >> version0.0
>> >>
>> >> bundle.location
>> >>
>> >> bundle.startlevel
>> >>
>> >> bundle.lastmodified
>> >>
>> >> bundle.id
>> >>
>> >> bundle.state
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> ls -l version0.0
>> >>>
>> >>>
>> >> bundle.jar
>> >>
>> >>
>> >>
>> >>> ls -l version0.1
>> >>>
>> >>>
>> >> bundle.jar
>> >>
>> >>
>> >>
>> >> What I mean to be pointing out here are the two "bundle.jar" files in
>> >>
>> > two
>> >
>> >> different "versionX.X" directories in the cache area for one bundle.
>> >>
>> > What
>> >
>> >> is the reason that I might get more than one of these? How can I avoid
>> >> that? I have limited space on the device our product runs on, and even
>> >> the size of these jar files can make a difference.
>> >>
>> >>
>> >>
>> >> Note that I am using the autodeploy feature with actions
>> >> "install,start,update". Sometimes the original bundle jars in the
>> >> autodeploy directory change from one run to the next.
>> >>
>> >>
>> > You might want to read:
>> >
>> >
>> http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>> >
>> > Typically, what you are seeing is the result of doing updates. However,
>> > typically the extra JAR files should be deleted after a refresh.
>> >
>> > Starting with "install,start,update" causes the update, but generally
>> > i'd assume you'd autorefresh during startup so you wouldn't see
>> > additional JAR files. Perhaps you could verify that refreshing is
>> > deleting the JAR files. If so, you could verify that they are
>> > automatically getting deleted on startup.
>> >
>> > By and large, after your framework starts I'd expect there to be no
>> > additional JAR files and after it stops I'd expect there to be no
>> > additional JAR files too. At run time, it just depends on whether you've
>> > updated and not refreshed yet.
>> >
>> > -> richard
>> >
>> >
>> >>
>> >> Thanks,
>> >>
>> >> Matt
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bundle cache version directories
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/7/10 6:18 PM, Chris Blunck wrote:
> It would also be beneficial to know if it's possible to avoid caching
> feature files.
>
> It's quite common for someone to change the configuration section of a
> feature file in the deploy directory and restart only to have their changes
> ignored because the feature file has been cached. Having a startup flag
> that says "don't cache features" that the bundle deployer would honor would
> be most helpful.
It sounds like you are talking about something related to Karaf, not
specifically the framework bundle cache.
-> richard
>
> -c
>
> On Wed, Jul 7, 2010 at 6:12 PM, Matt Tennant<mt...@4home.com> wrote:
>
>> I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
>> doing. It turns out that it is deleting the entire bundle cache directory
>> and starting from scratch. I thought it was simply removing unused files
>> and directories, which is less useful to me. I guess I was doing some
>> wishful thinking.
>>
>> So I guess I should ask a new question. Is there support for what I
>> thought that option was doing? Basically, I want the caches for bundles
>> that are still in use to survive, but anything else, especially caches for
>> uninstalled bundles, to get removed.
>>
>> Some background: I cannot just nuke the bundle cache directory because
>> some bundles have been previously installed from remote URLs, and I cannot
>> repeat that operation every time the framework starts up. Bundles
>> previously installed this way must be preserved. Also, a few times we
>> have seen bundle cache directories get extremely bloated with caches for
>> bundles that are no longer installed. On an embedded device this is
>> catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
>> problem, but it's hard to test for sure because the problem has not been
>> easily repeated. I have a workaround the looks for these directories
>> manually, but the workaround is very Felix-specific and I try to avoid
>> that sort of thing.
>>
>> Thanks for any help,
>> Matt
>>
>> -----Original Message-----
>> From: Matt Tennant [mailto:mtennant@4home.com]
>> Sent: Wednesday, July 07, 2010 2:02 PM
>> To: users@felix.apache.org
>> Subject: RE: bundle cache version directories
>>
>> Hi all,
>>
>> I have a follow up question from this thread I started some time ago.
>> Since then, I have been trying out the following property and value:
>> org.osgi.framework.storage.clean=onFirstInit
>>
>> Which appears to work well, and removes extraneous directories and files
>> from my bundle cache directory shortly after startup. Note that it
>> doesn't matter whether these directories and files were originally created
>> by Felix. If they are in the bundle cache directory, they are removed.
>>
>> I also tried calling refreshPackages(null) on the PackageAdmin service
>> object at runtime. When I do this, the message "FrameworkEvent PACKAGES
>> REFRESHED" is logged. It may be doing something, but the behavior is not
>> the same as with the org.osgi.framework.storage.clean property.
>> Extraneous directories and files are not removed.
>>
>> I was expecting the behavior to be the same between the two approaches.
>> Can somebody please explain the distinction? Is there runtime access to
>> the behavior that org.osgi.framework.storage.clean exhibits?
>>
>> In case there is some confusion, I am not worrying about precisely the
>> same problem as in the original thread, but instead solving a problem
>> where occasionally old bundle caches are present for bundles that are no
>> longer in use.
>>
>> Thank you,
>> Matt
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Thursday, June 03, 2010 12:00 PM
>> To: users@felix.apache.org
>> Subject: Re: bundle cache version directories
>>
>> On 6/3/10 14:01, Matt Tennant wrote:
>>> That was a useful read, thank you. It leaves me with just one question:
>>> what triggers a framework refresh? (other than a startup/shutdown)
>>>
>> Explicitly calling PackageAdmin.refreshPackages(), which is done by
>> getting the PackageAdmin service or the Felix shell provides a "refresh"
>> command.
>>
>> -> richard
>>
>>> From this point onward I will make a note of whether I ever see
>> multiple
>>> version directories at a point in time when I should not.
>>>
>>> Thanks!
>>> Matt
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Thursday, June 03, 2010 5:50 AM
>>> To: users@felix.apache.org
>>> Subject: Re: bundle cache version directories
>>>
>>> On 6/2/10 19:20, Matt Tennant wrote:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I have a question about the "versionX.X" directories inside the Felix
>>>> bundle cache. I am using Felix 2.0.0, and I often see something like
>>>>
>>> the
>>>
>>>> following in my bundle cache directory:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> ls -l
>>>>>
>>>>>
>>>> bundle0
>>>>
>>>> bundle1
>>>>
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> cd bundle0
>>>>>
>>>>>
>>>>
>>>>> ls -l
>>>>>
>>>>>
>>>> version0.1
>>>>
>>>> version0.0
>>>>
>>>> bundle.location
>>>>
>>>> bundle.startlevel
>>>>
>>>> bundle.lastmodified
>>>>
>>>> bundle.id
>>>>
>>>> bundle.state
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> ls -l version0.0
>>>>>
>>>>>
>>>> bundle.jar
>>>>
>>>>
>>>>
>>>>> ls -l version0.1
>>>>>
>>>>>
>>>> bundle.jar
>>>>
>>>>
>>>>
>>>> What I mean to be pointing out here are the two "bundle.jar" files in
>>>>
>>> two
>>>
>>>> different "versionX.X" directories in the cache area for one bundle.
>>>>
>>> What
>>>
>>>> is the reason that I might get more than one of these? How can I avoid
>>>> that? I have limited space on the device our product runs on, and even
>>>> the size of these jar files can make a difference.
>>>>
>>>>
>>>>
>>>> Note that I am using the autodeploy feature with actions
>>>> "install,start,update". Sometimes the original bundle jars in the
>>>> autodeploy directory change from one run to the next.
>>>>
>>>>
>>> You might want to read:
>>>
>>>
>> http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>>> Typically, what you are seeing is the result of doing updates. However,
>>> typically the extra JAR files should be deleted after a refresh.
>>>
>>> Starting with "install,start,update" causes the update, but generally
>>> i'd assume you'd autorefresh during startup so you wouldn't see
>>> additional JAR files. Perhaps you could verify that refreshing is
>>> deleting the JAR files. If so, you could verify that they are
>>> automatically getting deleted on startup.
>>>
>>> By and large, after your framework starts I'd expect there to be no
>>> additional JAR files and after it stops I'd expect there to be no
>>> additional JAR files too. At run time, it just depends on whether you've
>>> updated and not refreshed yet.
>>>
>>> -> richard
>>>
>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bundle cache version directories
Posted by Chris Blunck <ch...@thebluncks.com>.
It would also be beneficial to know if it's possible to avoid caching
feature files.
It's quite common for someone to change the configuration section of a
feature file in the deploy directory and restart only to have their changes
ignored because the feature file has been cached. Having a startup flag
that says "don't cache features" that the bundle deployer would honor would
be most helpful.
-c
On Wed, Jul 7, 2010 at 6:12 PM, Matt Tennant <mt...@4home.com> wrote:
> I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
> doing. It turns out that it is deleting the entire bundle cache directory
> and starting from scratch. I thought it was simply removing unused files
> and directories, which is less useful to me. I guess I was doing some
> wishful thinking.
>
> So I guess I should ask a new question. Is there support for what I
> thought that option was doing? Basically, I want the caches for bundles
> that are still in use to survive, but anything else, especially caches for
> uninstalled bundles, to get removed.
>
> Some background: I cannot just nuke the bundle cache directory because
> some bundles have been previously installed from remote URLs, and I cannot
> repeat that operation every time the framework starts up. Bundles
> previously installed this way must be preserved. Also, a few times we
> have seen bundle cache directories get extremely bloated with caches for
> bundles that are no longer installed. On an embedded device this is
> catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
> problem, but it's hard to test for sure because the problem has not been
> easily repeated. I have a workaround the looks for these directories
> manually, but the workaround is very Felix-specific and I try to avoid
> that sort of thing.
>
> Thanks for any help,
> Matt
>
> -----Original Message-----
> From: Matt Tennant [mailto:mtennant@4home.com]
> Sent: Wednesday, July 07, 2010 2:02 PM
> To: users@felix.apache.org
> Subject: RE: bundle cache version directories
>
> Hi all,
>
> I have a follow up question from this thread I started some time ago.
> Since then, I have been trying out the following property and value:
> org.osgi.framework.storage.clean=onFirstInit
>
> Which appears to work well, and removes extraneous directories and files
> from my bundle cache directory shortly after startup. Note that it
> doesn't matter whether these directories and files were originally created
> by Felix. If they are in the bundle cache directory, they are removed.
>
> I also tried calling refreshPackages(null) on the PackageAdmin service
> object at runtime. When I do this, the message "FrameworkEvent PACKAGES
> REFRESHED" is logged. It may be doing something, but the behavior is not
> the same as with the org.osgi.framework.storage.clean property.
> Extraneous directories and files are not removed.
>
> I was expecting the behavior to be the same between the two approaches.
> Can somebody please explain the distinction? Is there runtime access to
> the behavior that org.osgi.framework.storage.clean exhibits?
>
> In case there is some confusion, I am not worrying about precisely the
> same problem as in the original thread, but instead solving a problem
> where occasionally old bundle caches are present for bundles that are no
> longer in use.
>
> Thank you,
> Matt
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, June 03, 2010 12:00 PM
> To: users@felix.apache.org
> Subject: Re: bundle cache version directories
>
> On 6/3/10 14:01, Matt Tennant wrote:
> > That was a useful read, thank you. It leaves me with just one question:
> > what triggers a framework refresh? (other than a startup/shutdown)
> >
>
> Explicitly calling PackageAdmin.refreshPackages(), which is done by
> getting the PackageAdmin service or the Felix shell provides a "refresh"
> command.
>
> -> richard
>
> > From this point onward I will make a note of whether I ever see
> multiple
> > version directories at a point in time when I should not.
> >
> > Thanks!
> > Matt
> >
> > -----Original Message-----
> > From: Richard S. Hall [mailto:heavy@ungoverned.org]
> > Sent: Thursday, June 03, 2010 5:50 AM
> > To: users@felix.apache.org
> > Subject: Re: bundle cache version directories
> >
> > On 6/2/10 19:20, Matt Tennant wrote:
> >
> >> Hi all,
> >>
> >>
> >>
> >> I have a question about the "versionX.X" directories inside the Felix
> >> bundle cache. I am using Felix 2.0.0, and I often see something like
> >>
> > the
> >
> >> following in my bundle cache directory:
> >>
> >>
> >>
> >>
> >>
> >>> ls -l
> >>>
> >>>
> >> bundle0
> >>
> >> bundle1
> >>
> >> ...
> >>
> >>
> >>
> >>
> >>
> >>> cd bundle0
> >>>
> >>>
> >>
> >>
> >>> ls -l
> >>>
> >>>
> >> version0.1
> >>
> >> version0.0
> >>
> >> bundle.location
> >>
> >> bundle.startlevel
> >>
> >> bundle.lastmodified
> >>
> >> bundle.id
> >>
> >> bundle.state
> >>
> >>
> >>
> >>
> >>
> >>> ls -l version0.0
> >>>
> >>>
> >> bundle.jar
> >>
> >>
> >>
> >>> ls -l version0.1
> >>>
> >>>
> >> bundle.jar
> >>
> >>
> >>
> >> What I mean to be pointing out here are the two "bundle.jar" files in
> >>
> > two
> >
> >> different "versionX.X" directories in the cache area for one bundle.
> >>
> > What
> >
> >> is the reason that I might get more than one of these? How can I avoid
> >> that? I have limited space on the device our product runs on, and even
> >> the size of these jar files can make a difference.
> >>
> >>
> >>
> >> Note that I am using the autodeploy feature with actions
> >> "install,start,update". Sometimes the original bundle jars in the
> >> autodeploy directory change from one run to the next.
> >>
> >>
> > You might want to read:
> >
> >
> http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
> >
> > Typically, what you are seeing is the result of doing updates. However,
> > typically the extra JAR files should be deleted after a refresh.
> >
> > Starting with "install,start,update" causes the update, but generally
> > i'd assume you'd autorefresh during startup so you wouldn't see
> > additional JAR files. Perhaps you could verify that refreshing is
> > deleting the JAR files. If so, you could verify that they are
> > automatically getting deleted on startup.
> >
> > By and large, after your framework starts I'd expect there to be no
> > additional JAR files and after it stops I'd expect there to be no
> > additional JAR files too. At run time, it just depends on whether you've
> > updated and not refreshed yet.
> >
> > -> richard
> >
> >
> >>
> >> Thanks,
> >>
> >> Matt
> >>
> >>
> >>
> >>
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: bundle cache version directories
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/7/10 20:31, Matt Tennant wrote:
> Hi Richard,
>
> Thank you for your quick response, as usual.
>
> I hope you are right. I am going to keep that refreshPackages call in
> there after any uninstall and monitor it for awhile. When I try to test
> the prodecure myself, it doesn't seem to matter whether I call
> refreshPackages or not after an uninstall, the bundle's cache is gone.
> Since I cannot recreate the problem where multiple bundle caches are not
> cleaned up I don't know whether this will help when it happens again.
One related piece of information, the Felix framework will automatically
perform a refresh when you uninstall a bundle that no one is using, but
in general it is always safe and a good idea to perform a refresh
explicitly to manage your bundles.
-> richard
> Thanks,
> Matt
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Wednesday, July 07, 2010 3:20 PM
> To: users@felix.apache.org
> Subject: Re: bundle cache version directories
>
>
>
> On 7/7/10 6:12 PM, Matt Tennant wrote:
>> I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
>> doing. It turns out that it is deleting the entire bundle cache
> directory
>> and starting from scratch. I thought it was simply removing unused
> files
>> and directories, which is less useful to me. I guess I was doing some
>> wishful thinking.
>>
>> So I guess I should ask a new question. Is there support for what I
>> thought that option was doing? Basically, I want the caches for bundles
>> that are still in use to survive, but anything else, especially caches
> for
>> uninstalled bundles, to get removed.
> A refresh operation will do that.
>
> If you are not seeing this behavior, then either you are doing something
> wrong or you uncovered a bug.
>
> The correct procedure is to uninstall some bundles, call
> refreshPackages(), after which the uninstalled bundles should be removed
> from the cache.
>
> -> richard
>
>> Some background: I cannot just nuke the bundle cache directory because
>> some bundles have been previously installed from remote URLs, and I
> cannot
>> repeat that operation every time the framework starts up. Bundles
>> previously installed this way must be preserved. Also, a few times we
>> have seen bundle cache directories get extremely bloated with caches for
>> bundles that are no longer installed. On an embedded device this is
>> catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
>> problem, but it's hard to test for sure because the problem has not been
>> easily repeated. I have a workaround the looks for these directories
>> manually, but the workaround is very Felix-specific and I try to avoid
>> that sort of thing.
>>
>> Thanks for any help,
>> Matt
>>
>> -----Original Message-----
>> From: Matt Tennant [mailto:mtennant@4home.com]
>> Sent: Wednesday, July 07, 2010 2:02 PM
>> To: users@felix.apache.org
>> Subject: RE: bundle cache version directories
>>
>> Hi all,
>>
>> I have a follow up question from this thread I started some time ago.
>> Since then, I have been trying out the following property and value:
>> org.osgi.framework.storage.clean=onFirstInit
>>
>> Which appears to work well, and removes extraneous directories and files
>> from my bundle cache directory shortly after startup. Note that it
>> doesn't matter whether these directories and files were originally
> created
>> by Felix. If they are in the bundle cache directory, they are removed.
>>
>> I also tried calling refreshPackages(null) on the PackageAdmin service
>> object at runtime. When I do this, the message "FrameworkEvent PACKAGES
>> REFRESHED" is logged. It may be doing something, but the behavior is
> not
>> the same as with the org.osgi.framework.storage.clean property.
>> Extraneous directories and files are not removed.
>>
>> I was expecting the behavior to be the same between the two approaches.
>> Can somebody please explain the distinction? Is there runtime access to
>> the behavior that org.osgi.framework.storage.clean exhibits?
>>
>> In case there is some confusion, I am not worrying about precisely the
>> same problem as in the original thread, but instead solving a problem
>> where occasionally old bundle caches are present for bundles that are no
>> longer in use.
>>
>> Thank you,
>> Matt
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Thursday, June 03, 2010 12:00 PM
>> To: users@felix.apache.org
>> Subject: Re: bundle cache version directories
>>
>> On 6/3/10 14:01, Matt Tennant wrote:
>>> That was a useful read, thank you. It leaves me with just one
> question:
>>> what triggers a framework refresh? (other than a startup/shutdown)
>>>
>> Explicitly calling PackageAdmin.refreshPackages(), which is done by
>> getting the PackageAdmin service or the Felix shell provides a "refresh"
>> command.
>>
>> -> richard
>>
>>> From this point onward I will make a note of whether I ever see
>> multiple
>>> version directories at a point in time when I should not.
>>>
>>> Thanks!
>>> Matt
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Thursday, June 03, 2010 5:50 AM
>>> To: users@felix.apache.org
>>> Subject: Re: bundle cache version directories
>>>
>>> On 6/2/10 19:20, Matt Tennant wrote:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I have a question about the "versionX.X" directories inside the Felix
>>>> bundle cache. I am using Felix 2.0.0, and I often see something like
>>>>
>>> the
>>>
>>>> following in my bundle cache directory:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> ls -l
>>>>>
>>>>>
>>>> bundle0
>>>>
>>>> bundle1
>>>>
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> cd bundle0
>>>>>
>>>>>
>>>>> ls -l
>>>>>
>>>>>
>>>> version0.1
>>>>
>>>> version0.0
>>>>
>>>> bundle.location
>>>>
>>>> bundle.startlevel
>>>>
>>>> bundle.lastmodified
>>>>
>>>> bundle.id
>>>>
>>>> bundle.state
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> ls -l version0.0
>>>>>
>>>>>
>>>> bundle.jar
>>>>
>>>>
>>>>
>>>>> ls -l version0.1
>>>>>
>>>>>
>>>> bundle.jar
>>>>
>>>>
>>>>
>>>> What I mean to be pointing out here are the two "bundle.jar" files in
>>>>
>>> two
>>>
>>>> different "versionX.X" directories in the cache area for one bundle.
>>>>
>>> What
>>>
>>>> is the reason that I might get more than one of these? How can I
> avoid
>>>> that? I have limited space on the device our product runs on, and
> even
>>>> the size of these jar files can make a difference.
>>>>
>>>>
>>>>
>>>> Note that I am using the autodeploy feature with actions
>>>> "install,start,update". Sometimes the original bundle jars in the
>>>> autodeploy directory change from one run to the next.
>>>>
>>>>
>>> You might want to read:
>>>
>>>
>> http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>>> Typically, what you are seeing is the result of doing updates. However,
>>> typically the extra JAR files should be deleted after a refresh.
>>>
>>> Starting with "install,start,update" causes the update, but generally
>>> i'd assume you'd autorefresh during startup so you wouldn't see
>>> additional JAR files. Perhaps you could verify that refreshing is
>>> deleting the JAR files. If so, you could verify that they are
>>> automatically getting deleted on startup.
>>>
>>> By and large, after your framework starts I'd expect there to be no
>>> additional JAR files and after it stops I'd expect there to be no
>>> additional JAR files too. At run time, it just depends on whether
> you've
>>> updated and not refreshed yet.
>>>
>>> -> richard
>>>
>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: bundle cache version directories
Posted by Matt Tennant <mt...@4home.com>.
Hi Richard,
Thank you for your quick response, as usual.
I hope you are right. I am going to keep that refreshPackages call in
there after any uninstall and monitor it for awhile. When I try to test
the prodecure myself, it doesn't seem to matter whether I call
refreshPackages or not after an uninstall, the bundle's cache is gone.
Since I cannot recreate the problem where multiple bundle caches are not
cleaned up I don't know whether this will help when it happens again.
Thanks,
Matt
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Wednesday, July 07, 2010 3:20 PM
To: users@felix.apache.org
Subject: Re: bundle cache version directories
On 7/7/10 6:12 PM, Matt Tennant wrote:
> I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
> doing. It turns out that it is deleting the entire bundle cache
directory
> and starting from scratch. I thought it was simply removing unused
files
> and directories, which is less useful to me. I guess I was doing some
> wishful thinking.
>
> So I guess I should ask a new question. Is there support for what I
> thought that option was doing? Basically, I want the caches for bundles
> that are still in use to survive, but anything else, especially caches
for
> uninstalled bundles, to get removed.
A refresh operation will do that.
If you are not seeing this behavior, then either you are doing something
wrong or you uncovered a bug.
The correct procedure is to uninstall some bundles, call
refreshPackages(), after which the uninstalled bundles should be removed
from the cache.
-> richard
> Some background: I cannot just nuke the bundle cache directory because
> some bundles have been previously installed from remote URLs, and I
cannot
> repeat that operation every time the framework starts up. Bundles
> previously installed this way must be preserved. Also, a few times we
> have seen bundle cache directories get extremely bloated with caches for
> bundles that are no longer installed. On an embedded device this is
> catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
> problem, but it's hard to test for sure because the problem has not been
> easily repeated. I have a workaround the looks for these directories
> manually, but the workaround is very Felix-specific and I try to avoid
> that sort of thing.
>
> Thanks for any help,
> Matt
>
> -----Original Message-----
> From: Matt Tennant [mailto:mtennant@4home.com]
> Sent: Wednesday, July 07, 2010 2:02 PM
> To: users@felix.apache.org
> Subject: RE: bundle cache version directories
>
> Hi all,
>
> I have a follow up question from this thread I started some time ago.
> Since then, I have been trying out the following property and value:
> org.osgi.framework.storage.clean=onFirstInit
>
> Which appears to work well, and removes extraneous directories and files
> from my bundle cache directory shortly after startup. Note that it
> doesn't matter whether these directories and files were originally
created
> by Felix. If they are in the bundle cache directory, they are removed.
>
> I also tried calling refreshPackages(null) on the PackageAdmin service
> object at runtime. When I do this, the message "FrameworkEvent PACKAGES
> REFRESHED" is logged. It may be doing something, but the behavior is
not
> the same as with the org.osgi.framework.storage.clean property.
> Extraneous directories and files are not removed.
>
> I was expecting the behavior to be the same between the two approaches.
> Can somebody please explain the distinction? Is there runtime access to
> the behavior that org.osgi.framework.storage.clean exhibits?
>
> In case there is some confusion, I am not worrying about precisely the
> same problem as in the original thread, but instead solving a problem
> where occasionally old bundle caches are present for bundles that are no
> longer in use.
>
> Thank you,
> Matt
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, June 03, 2010 12:00 PM
> To: users@felix.apache.org
> Subject: Re: bundle cache version directories
>
> On 6/3/10 14:01, Matt Tennant wrote:
>> That was a useful read, thank you. It leaves me with just one
question:
>> what triggers a framework refresh? (other than a startup/shutdown)
>>
> Explicitly calling PackageAdmin.refreshPackages(), which is done by
> getting the PackageAdmin service or the Felix shell provides a "refresh"
> command.
>
> -> richard
>
>> From this point onward I will make a note of whether I ever see
> multiple
>> version directories at a point in time when I should not.
>>
>> Thanks!
>> Matt
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Thursday, June 03, 2010 5:50 AM
>> To: users@felix.apache.org
>> Subject: Re: bundle cache version directories
>>
>> On 6/2/10 19:20, Matt Tennant wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> I have a question about the "versionX.X" directories inside the Felix
>>> bundle cache. I am using Felix 2.0.0, and I often see something like
>>>
>> the
>>
>>> following in my bundle cache directory:
>>>
>>>
>>>
>>>
>>>
>>>> ls -l
>>>>
>>>>
>>> bundle0
>>>
>>> bundle1
>>>
>>> ...
>>>
>>>
>>>
>>>
>>>
>>>> cd bundle0
>>>>
>>>>
>>>
>>>> ls -l
>>>>
>>>>
>>> version0.1
>>>
>>> version0.0
>>>
>>> bundle.location
>>>
>>> bundle.startlevel
>>>
>>> bundle.lastmodified
>>>
>>> bundle.id
>>>
>>> bundle.state
>>>
>>>
>>>
>>>
>>>
>>>> ls -l version0.0
>>>>
>>>>
>>> bundle.jar
>>>
>>>
>>>
>>>> ls -l version0.1
>>>>
>>>>
>>> bundle.jar
>>>
>>>
>>>
>>> What I mean to be pointing out here are the two "bundle.jar" files in
>>>
>> two
>>
>>> different "versionX.X" directories in the cache area for one bundle.
>>>
>> What
>>
>>> is the reason that I might get more than one of these? How can I
avoid
>>> that? I have limited space on the device our product runs on, and
even
>>> the size of these jar files can make a difference.
>>>
>>>
>>>
>>> Note that I am using the autodeploy feature with actions
>>> "install,start,update". Sometimes the original bundle jars in the
>>> autodeploy directory change from one run to the next.
>>>
>>>
>> You might want to read:
>>
>>
> http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>> Typically, what you are seeing is the result of doing updates. However,
>> typically the extra JAR files should be deleted after a refresh.
>>
>> Starting with "install,start,update" causes the update, but generally
>> i'd assume you'd autorefresh during startup so you wouldn't see
>> additional JAR files. Perhaps you could verify that refreshing is
>> deleting the JAR files. If so, you could verify that they are
>> automatically getting deleted on startup.
>>
>> By and large, after your framework starts I'd expect there to be no
>> additional JAR files and after it stops I'd expect there to be no
>> additional JAR files too. At run time, it just depends on whether
you've
>> updated and not refreshed yet.
>>
>> -> richard
>>
>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bundle cache version directories
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/7/10 6:12 PM, Matt Tennant wrote:
> I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
> doing. It turns out that it is deleting the entire bundle cache directory
> and starting from scratch. I thought it was simply removing unused files
> and directories, which is less useful to me. I guess I was doing some
> wishful thinking.
>
> So I guess I should ask a new question. Is there support for what I
> thought that option was doing? Basically, I want the caches for bundles
> that are still in use to survive, but anything else, especially caches for
> uninstalled bundles, to get removed.
A refresh operation will do that.
If you are not seeing this behavior, then either you are doing something
wrong or you uncovered a bug.
The correct procedure is to uninstall some bundles, call
refreshPackages(), after which the uninstalled bundles should be removed
from the cache.
-> richard
> Some background: I cannot just nuke the bundle cache directory because
> some bundles have been previously installed from remote URLs, and I cannot
> repeat that operation every time the framework starts up. Bundles
> previously installed this way must be preserved. Also, a few times we
> have seen bundle cache directories get extremely bloated with caches for
> bundles that are no longer installed. On an embedded device this is
> catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
> problem, but it's hard to test for sure because the problem has not been
> easily repeated. I have a workaround the looks for these directories
> manually, but the workaround is very Felix-specific and I try to avoid
> that sort of thing.
>
> Thanks for any help,
> Matt
>
> -----Original Message-----
> From: Matt Tennant [mailto:mtennant@4home.com]
> Sent: Wednesday, July 07, 2010 2:02 PM
> To: users@felix.apache.org
> Subject: RE: bundle cache version directories
>
> Hi all,
>
> I have a follow up question from this thread I started some time ago.
> Since then, I have been trying out the following property and value:
> org.osgi.framework.storage.clean=onFirstInit
>
> Which appears to work well, and removes extraneous directories and files
> from my bundle cache directory shortly after startup. Note that it
> doesn't matter whether these directories and files were originally created
> by Felix. If they are in the bundle cache directory, they are removed.
>
> I also tried calling refreshPackages(null) on the PackageAdmin service
> object at runtime. When I do this, the message "FrameworkEvent PACKAGES
> REFRESHED" is logged. It may be doing something, but the behavior is not
> the same as with the org.osgi.framework.storage.clean property.
> Extraneous directories and files are not removed.
>
> I was expecting the behavior to be the same between the two approaches.
> Can somebody please explain the distinction? Is there runtime access to
> the behavior that org.osgi.framework.storage.clean exhibits?
>
> In case there is some confusion, I am not worrying about precisely the
> same problem as in the original thread, but instead solving a problem
> where occasionally old bundle caches are present for bundles that are no
> longer in use.
>
> Thank you,
> Matt
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, June 03, 2010 12:00 PM
> To: users@felix.apache.org
> Subject: Re: bundle cache version directories
>
> On 6/3/10 14:01, Matt Tennant wrote:
>> That was a useful read, thank you. It leaves me with just one question:
>> what triggers a framework refresh? (other than a startup/shutdown)
>>
> Explicitly calling PackageAdmin.refreshPackages(), which is done by
> getting the PackageAdmin service or the Felix shell provides a "refresh"
> command.
>
> -> richard
>
>> From this point onward I will make a note of whether I ever see
> multiple
>> version directories at a point in time when I should not.
>>
>> Thanks!
>> Matt
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Thursday, June 03, 2010 5:50 AM
>> To: users@felix.apache.org
>> Subject: Re: bundle cache version directories
>>
>> On 6/2/10 19:20, Matt Tennant wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> I have a question about the "versionX.X" directories inside the Felix
>>> bundle cache. I am using Felix 2.0.0, and I often see something like
>>>
>> the
>>
>>> following in my bundle cache directory:
>>>
>>>
>>>
>>>
>>>
>>>> ls -l
>>>>
>>>>
>>> bundle0
>>>
>>> bundle1
>>>
>>> ...
>>>
>>>
>>>
>>>
>>>
>>>> cd bundle0
>>>>
>>>>
>>>
>>>> ls -l
>>>>
>>>>
>>> version0.1
>>>
>>> version0.0
>>>
>>> bundle.location
>>>
>>> bundle.startlevel
>>>
>>> bundle.lastmodified
>>>
>>> bundle.id
>>>
>>> bundle.state
>>>
>>>
>>>
>>>
>>>
>>>> ls -l version0.0
>>>>
>>>>
>>> bundle.jar
>>>
>>>
>>>
>>>> ls -l version0.1
>>>>
>>>>
>>> bundle.jar
>>>
>>>
>>>
>>> What I mean to be pointing out here are the two "bundle.jar" files in
>>>
>> two
>>
>>> different "versionX.X" directories in the cache area for one bundle.
>>>
>> What
>>
>>> is the reason that I might get more than one of these? How can I avoid
>>> that? I have limited space on the device our product runs on, and even
>>> the size of these jar files can make a difference.
>>>
>>>
>>>
>>> Note that I am using the autodeploy feature with actions
>>> "install,start,update". Sometimes the original bundle jars in the
>>> autodeploy directory change from one run to the next.
>>>
>>>
>> You might want to read:
>>
>>
> http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>> Typically, what you are seeing is the result of doing updates. However,
>> typically the extra JAR files should be deleted after a refresh.
>>
>> Starting with "install,start,update" causes the update, but generally
>> i'd assume you'd autorefresh during startup so you wouldn't see
>> additional JAR files. Perhaps you could verify that refreshing is
>> deleting the JAR files. If so, you could verify that they are
>> automatically getting deleted on startup.
>>
>> By and large, after your framework starts I'd expect there to be no
>> additional JAR files and after it stops I'd expect there to be no
>> additional JAR files too. At run time, it just depends on whether you've
>> updated and not refreshed yet.
>>
>> -> richard
>>
>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: bundle cache version directories
Posted by Matt Tennant <mt...@4home.com>.
I was wrong about what org.osgi.framework.storage.clean=onFirstInit was
doing. It turns out that it is deleting the entire bundle cache directory
and starting from scratch. I thought it was simply removing unused files
and directories, which is less useful to me. I guess I was doing some
wishful thinking.
So I guess I should ask a new question. Is there support for what I
thought that option was doing? Basically, I want the caches for bundles
that are still in use to survive, but anything else, especially caches for
uninstalled bundles, to get removed.
Some background: I cannot just nuke the bundle cache directory because
some bundles have been previously installed from remote URLs, and I cannot
repeat that operation every time the framework starts up. Bundles
previously installed this way must be preserved. Also, a few times we
have seen bundle cache directories get extremely bloated with caches for
bundles that are no longer installed. On an embedded device this is
catastrophic. Perhaps PackageAdmin.refreshPackages will solve this
problem, but it's hard to test for sure because the problem has not been
easily repeated. I have a workaround the looks for these directories
manually, but the workaround is very Felix-specific and I try to avoid
that sort of thing.
Thanks for any help,
Matt
-----Original Message-----
From: Matt Tennant [mailto:mtennant@4home.com]
Sent: Wednesday, July 07, 2010 2:02 PM
To: users@felix.apache.org
Subject: RE: bundle cache version directories
Hi all,
I have a follow up question from this thread I started some time ago.
Since then, I have been trying out the following property and value:
org.osgi.framework.storage.clean=onFirstInit
Which appears to work well, and removes extraneous directories and files
from my bundle cache directory shortly after startup. Note that it
doesn't matter whether these directories and files were originally created
by Felix. If they are in the bundle cache directory, they are removed.
I also tried calling refreshPackages(null) on the PackageAdmin service
object at runtime. When I do this, the message "FrameworkEvent PACKAGES
REFRESHED" is logged. It may be doing something, but the behavior is not
the same as with the org.osgi.framework.storage.clean property.
Extraneous directories and files are not removed.
I was expecting the behavior to be the same between the two approaches.
Can somebody please explain the distinction? Is there runtime access to
the behavior that org.osgi.framework.storage.clean exhibits?
In case there is some confusion, I am not worrying about precisely the
same problem as in the original thread, but instead solving a problem
where occasionally old bundle caches are present for bundles that are no
longer in use.
Thank you,
Matt
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Thursday, June 03, 2010 12:00 PM
To: users@felix.apache.org
Subject: Re: bundle cache version directories
On 6/3/10 14:01, Matt Tennant wrote:
> That was a useful read, thank you. It leaves me with just one question:
> what triggers a framework refresh? (other than a startup/shutdown)
>
Explicitly calling PackageAdmin.refreshPackages(), which is done by
getting the PackageAdmin service or the Felix shell provides a "refresh"
command.
-> richard
> From this point onward I will make a note of whether I ever see
multiple
> version directories at a point in time when I should not.
>
> Thanks!
> Matt
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, June 03, 2010 5:50 AM
> To: users@felix.apache.org
> Subject: Re: bundle cache version directories
>
> On 6/2/10 19:20, Matt Tennant wrote:
>
>> Hi all,
>>
>>
>>
>> I have a question about the "versionX.X" directories inside the Felix
>> bundle cache. I am using Felix 2.0.0, and I often see something like
>>
> the
>
>> following in my bundle cache directory:
>>
>>
>>
>>
>>
>>> ls -l
>>>
>>>
>> bundle0
>>
>> bundle1
>>
>> ...
>>
>>
>>
>>
>>
>>> cd bundle0
>>>
>>>
>>
>>
>>> ls -l
>>>
>>>
>> version0.1
>>
>> version0.0
>>
>> bundle.location
>>
>> bundle.startlevel
>>
>> bundle.lastmodified
>>
>> bundle.id
>>
>> bundle.state
>>
>>
>>
>>
>>
>>> ls -l version0.0
>>>
>>>
>> bundle.jar
>>
>>
>>
>>> ls -l version0.1
>>>
>>>
>> bundle.jar
>>
>>
>>
>> What I mean to be pointing out here are the two "bundle.jar" files in
>>
> two
>
>> different "versionX.X" directories in the cache area for one bundle.
>>
> What
>
>> is the reason that I might get more than one of these? How can I avoid
>> that? I have limited space on the device our product runs on, and even
>> the size of these jar files can make a difference.
>>
>>
>>
>> Note that I am using the autodeploy feature with actions
>> "install,start,update". Sometimes the original bundle jars in the
>> autodeploy directory change from one run to the next.
>>
>>
> You might want to read:
>
>
http://felix.apache.org/site/apache-felix-framework-bundle-cache.html
>
> Typically, what you are seeing is the result of doing updates. However,
> typically the extra JAR files should be deleted after a refresh.
>
> Starting with "install,start,update" causes the update, but generally
> i'd assume you'd autorefresh during startup so you wouldn't see
> additional JAR files. Perhaps you could verify that refreshing is
> deleting the JAR files. If so, you could verify that they are
> automatically getting deleted on startup.
>
> By and large, after your framework starts I'd expect there to be no
> additional JAR files and after it stops I'd expect there to be no
> additional JAR files too. At run time, it just depends on whether you've
> updated and not refreshed yet.
>
> -> richard
>
>
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org