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]
