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? 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]
