I'll build it that way. Thanks! Don
On Tue, Oct 5, 2010 at 3:04 PM, Richard S. Hall <[email protected]> wrote: > On 10/5/10 14:58, Donald Whytock wrote: >> >> I'm using the objectClass along with another property, yes. Currently >> the bundles generate services of a particular class and add a name >> property; the instances look for services of that type and compare the >> name property to a table of names they look for. If I did it the >> other way around, the names the instances were looking for would >> probably be lumped together into a single property -- >> ||name1|name2|name3|| for instance -- with the bundles searching for >> instance services where namelist=*|namex|* >> >> So if services are indexed on objectClass, and I do an and-filter on >> objectClass and another property value, would the filter evaluate the >> objectClass of a changing service before looking at the property? > > It isn't smart, it evaluates them in the order you write them...so you > should make sure to write your filter with objectClass comparison first. > > -> richard > >> That would suggest I should have fewer, more-stable services and lots >> of servicetrackers tied to them, as opposed to lots of less-stable >> services that a handful of servicetrackers would be reacting to more >> often. >> >> On Tue, Oct 5, 2010 at 2:29 PM, Richard S. Hall<[email protected]> >> wrote: >>> >>> On 10/5/10 13:26, Donald Whytock wrote: >>>> >>>> Hi all... >>>> >>>> I have an efficiency question. I have a bundle kicking off a small >>>> number of instances (typically one but could be more) interacting with >>>> a larger number of bundles. At the moment I have the large group >>>> kicking off services with names that the small group of instances >>>> tracks. I'm considering more of a whiteboard pattern with the >>>> instances launching services specifying the names of the bundles >>>> sought, and the bundles tracking the services. Either way, the >>>> instances will need to track the states of the bundles. >>>> >>>> So which is more efficient? A large number of servicetrackers >>>> tracking a small number of services? Or a small number of >>>> servicetrackers tracking a large number of services? >>> >>> Not sure. Someone has to do the filtering and delivery, you are just >>> changing where it happens, it seems. >>> >>> If you were doing service queries based purely on objectClass, then it >>> would >>> probably be quicker to let the framework do the event filtering and >>> delivery, since it indexes this value. However, it sounds like you are >>> using >>> some other "name" service property to do your filtering, so it probably >>> doesn't matter much. >>> >>> The indexing mechanism the framework uses is actually generic, so >>> technically it is possible to have it index other service properties. I >>> had >>> thought about making a configuration property for this purpose, but it >>> hasn't been a priority. >>> >>> If this is something that sounds interesting to you, you could open up a >>> JIRA issue for it. You could experiment with it by simply modifying the >>> constructor of the org.apache.felix.framework.ServiceRegistry class to >>> hard >>> code the name of the service property you want indexed. >>> >>> -> richard >>> >>>> Don >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
