On 4/23/10 16:05, Pierre De Rop wrote:
Hello Richard,
Recently, we discovered a performance issue during the start up of our
application server (we are using the recent 2.0.5 felix version).
So, after investigating, I found that so far, we were uselessly starting the
org.osgi.core.jar bundle.
Indeed, the framework already exports the packages that are exported by
org.osgi.core (except security packages).
So, after removing the org.osgi.core bundle, it turned out that the start up
performance issue just disappeared.
Now, looking at your mail, I gave a try to the latest felix from trunk + the
org.osgi.core.jar bundle, as before.
And the good news is that I don't have the start up performance problem
anymore (with the org.osgi.core bundle).
however, now, I have this warning:
RE: org.apache.felix.framework.resolver.ResolveException: Constraint
violation for package 'javax.xml.bind' when resolving module 201.0 between
existing imported constraint 0.javax.xml.bind BLAMED ON [[201.0] package;
(&(package=javax.xml.bind)(bundle-symbolic-name=system.bundle))] and uses
constraint 22.0.javax.xml.bind BLAMED ON [[201.0] package; (package=
com.alcatel_lucent.as.geored.site.info), [203.0] package;
(package=javax.xml.bind)]
So, I am now trying to investigate, in order to check if the new felix-trunk
has found an error from our side, which we did not notice so far ...
But can you please explain me what this warning means ?
Is it a DEBUG message ? or a WARN message ?
If your bundles appear to be resolved correctly when doing "ps", then
everything is probably ok.
The resolver still needs some cleaning up. Right now for debug purposes
I am reporting intermediate resolve exceptions (e.g., such as when I
encounter a constraint violation). It is not clear if I should log these
at all, so I will have to think about that in the final code, but for
now you will see them. I understand it is a little confusing since it
may look like your bundle didn't resolve successfully, but as long as
its state is RESOLVED or ACTIVE, then the error log was just an
intermediate result.
So, hopefully the result is correct and it is not taking it a long time
to calculate it. :-)
-> richard
thanks;
/pierre
On Fri, Apr 23, 2010 at 9:07 PM, Richard S. Hall<he...@ungoverned.org>wrote:
Hello,
Just a word to say I just committed some significant changes to the
framework resolver, almost another rewrite. :-(
This became necessary over the last month when I came upon a scenario that
was creating difficulties for the previous prototype resolver which resulted
first from some bugs and then once these bugs were fixed there were
performance issues.
This latest resolver algorithm is conceptually very similar, so it is not a
complete rewrite, but the changes were fairly substantial. I am optimistic,
as always. All known scenarios now appear to be working and resolving fairly
quickly and the code passes the R4.2 CT. I'll keep my fingers crossed that
this will be the last major change needed to the core algorithm.
I deployed new snapshots. Let me know if you start experiencing any
issues...I do know that handling of conflicting fragments is a little
different...among other things I am sure.
-> richard
