Will do! BJ "learned" me some things in a private thread on the subject.
The topic is not imminently critical because I've managed to create a pretty good wrapper (around ServiceTracker) that will suite our needs. I'll certainly let you know if I actually do anything as I feel there is still room for it. - Ray On Mon, Jan 13, 2014 at 9:55 AM, Thomas Watson <[email protected]> wrote: > Are you talking about synchronization in the ServiceTracker implementation > itself? If so I expect that to be identical across all frameworks since > the ServiceTracker is an implementation provided by the osgi companion code > directly, not the the various framework/service implementations. > > I seem to recall discussions in the past in this area but thought we > avoided doing anything for compatibility reasons. I suggest you open a bug > and possibly start a branch if you have some implementation improvements to > propose. > > Tom > > > > [image: Inactive hide details for Raymond Auge ---01/09/2014 10:17:44 > AM---Recently I've performed some JMH benchmarking on the usecase]Raymond > Auge ---01/09/2014 10:17:44 AM---Recently I've performed some JMH > benchmarking on the usecases for retireving collections of services > > From: Raymond Auge <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 01/09/2014 10:17 AM > Subject: [osgi-dev] heavy synchronization of ServiceTracker impls > Sent by: [email protected] > ------------------------------ > > > > Recently I've performed some JMH benchmarking on the usecases for > retireving collections of services. > > I discovered that raw usage of the ServiceTracker is in fact very slow for > most cases due to heavy synchronization (both equinox and felix seem to > have similar synchronization, although all my tests were actually against > equinox). > > Has this ever been discussed or reviewed? > > It seems that since this is such a core function any improvement here > would greatly affect/improve performance overall (not that it's really > bad... except under significant concurrency). > > i.e. lock free impl. > > Thoughts? > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
<<graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
