karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Feature Service PHYSIKOdata bundle startup order
Date Fri, 28 Sep 2012 09:31:08 GMT
Hi Andreas,

hash maps should be generally O(1) while tree maps should be O(log n).
I don't think though the speed is the big issue. The thing I really 
would like to improve is the testability.

I wonder if we could use just the bundle id in the maps instead of the 
full bundle object. That should make it even easier to test.

Christian

On 09/28/2012 10:04 AM, Andreas Pieber wrote:
> I'm not really happy with the hash map there. Does any one know the big O
> of tree set vs hash set? Curious if the insert is really that much faster.
> Besides, right now the algorithm keeps the base order and ONLY reschedule
> bundles with a different start lvl. A hash set with only the sorting
> afterwards will destroy the base order. So rather +1 to keep the tree set.
>
> Kind regards,
> Andreas
> On Sep 28, 2012 9:45 AM, "Christian Schneider" <chris@die-schneider.net>
> wrote:
>
>> I also agree that backporting the new behaviour and setting the old as
>> default makes sense.
>> I am also fine with setting the new behaviour as default on trunk. I think
>> on trunk we do not even need a switch.
>>
>> Btw. I would like to replace the TreeSet with a HashSet on trunk again as
>> we do not need the order there anymore.
>> This is probably faster and makes testing a bit simpler again.
>>
>> Christian
>>
>> On 09/28/2012 05:43 AM, Andreas Pieber wrote:
>>
>>> Hey Freeman,
>>>
>>> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <freeman.fang@gmail.com>
>>> wrote:
>>>
>>>> It's a good idea.
>>>>
>>> Thanks :-)
>>>
>>>   And how about we introduce an property for FeaturesServiceImpl, and in
>>>> etc/org.apache.karaf.features.**cfg we get chance to configure this
>>>> property so that we can keep behavior as is or use the new behavior you
>>>> introduced here, just in case some user somehow still wanna use current
>>>> behavior.
>>>>
>>> Definitely +1 here; I can add this before pushing the changes. Since
>>> the change is quite limited this should be quite simple.
>>>
>>>   And  I suggest the default behavior is keep as is.
>>> Well, that's a point I want to discuss. I'm not sure if the current
>>> default behavior is what really meets the expectations. For example,
>>> if you give the cxf or amq feature.xml files a shot there are quite a
>>> lot of startlvl annotations for bundles. I think that it still work
>>> with the current behavior is more luck than anything else :-) In
>>> addition the new behavior will not affect most of the current
>>> applications. More over I think it's the "more sane" behavior to
>>> consider the startlvl per default and use the old one as a fallback
>>> behavior if it doesn't work out for you in any specific reason.
>>>
>>> What would make sense for me is backporting the change to 2.3 (or 2.4)
>>> and use the old behavior there per default; but for the master I think
>>> we could risk this slight change of the default behavior.
>>>
>>> Does this makes sense to you?
>>>
>>>   I think the features/core/src/main/**resources/OSGI-INF/blueprint/**gshell-features.xml
>>>> need be updated accordingly.
>>>>
>>> For the new property I need to introduce you mean?
>>>
>>>   My 2 cents
>>> Warmly welcomed, as always; thanks!
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>   Best Regards
>>>> Freeman
>>>> -------------
>>>> Freeman Fang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>> Web: http://fusesource.com | http://www.redhat.com/
>>>> Twitter: freemanfang
>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>> http://blog.sina.com.cn/u/**1473905042<http://blog.sina.com.cn/u/1473905042>
>>>> weibo: http://weibo.com/u/1473905042
>>>>
>>>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>>>
>>>>   Hey guys,
>>>>> First of all, just to bring everyone at the same lvl: If we install
>>>>> features all bundles in the feature(s) are installed and then started
>>>>> one after the other, in the order as they had been defined in the
>>>>> features.
>>>>>
>>>>> While in theory it should not happen there are situations where we (in
>>>>> our software) depend that those features are started at least per
>>>>> feature in the order in which they had been added. If I understand the
>>>>> CXF feature structure correctly it's also required for them.  By a bug
>>>>> last week on the trunk I discovered this explicit requirement for our
>>>>> software. Starting by this discovery we've started a discussion if it
>>>>> wouldn't be better if we consider the startLvl during the feature
>>>>> startup. So, I hacked up a solution and tested it with several
>>>>> different softwares I've access to and it seamed to work pretty well.
>>>>>
>>>>> I've attached the patch to [1] and would really like to hear what you
>>>>> think about it.
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> [1] https://issues.apache.org/**jira/browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878>
>>>>>


Mime
View raw message