Thanks,
Matt
-----Original Message-----
From: Richard S. Hall [mailto:he...@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:mtenn...@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:he...@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:he...@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-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
