I agree that a modern OSGI managed application should have little to no references to OSGI at all. The DI options available in Blueprint, IPOJO, PAX-CDI, etc. make this possible.
However, you can get too obsessed with this purity and find yourself employing dynamic service proxies to respond to service changes in objects (and collections of objects) not managed by the DI container. This would be a mistake. These proxies should never be employed in a system requiring very high performance. Instead your application code needs to support the concepts of service availability and change natively. -Nick Baker On 3/14/14, 11:12 AM, "Jeremy Jongsma" <jer...@barchart.com> wrote: >We process high-volume real time market data feeds exclusively on Karaf >application servers. As others have said, once the app is running >Karaf/OSGI gets out of your way, there is no performance or scalability >penalty, it's all your code. In most cases OSGI only comes into play when >things are starting up or updating. In our case we don't do hot updates, >OSGI is strictly used for DI and version enforcement. > > >On Fri, Mar 14, 2014 at 9:29 AM, Raymond Auge ><raymond.a...@liferay.com>wrote: > >> I actually went through this same thought process within the past two >>years >> as I really didn't understand OSGi service registry at first (even when >>I >> thought I did). >> >> As Neil stated, osgi is orthogonal to your application. >> >> Speaking plainly about that, the primary lesson I learned was that if >>the >> service registry is directly in-line with your business logic, you are >>very >> likely using the service registry incorrectly. >> >> You would never directly perform lookups in the main execution path of >>your >> application. Think of OSGI as an "runtime DI agent/manager" rather than >>as >> the "framework" you are building your application with, operating in >> parallel (not literally) with your application, but never in the main >> execution path. >> >> - Ray >> >> >> >> >> On Fri, Mar 14, 2014 at 9:46 AM, Neil Bartlett <njbartl...@gmail.com> >> wrote: >> >> > Indeed, OSGi can improve the performance of classloading because it >> > reduces the search space. >> > >> > Looking up service references can add a small overhead. However this >>is >> > usually done very infrequently, with the result being cached until the >> > framework notifies us of a change. >> > >> > Regards, Neil >> > >> > -- >> > Neil Bartlett >> > Sent from a phone >> > >> > >> > On Friday, 14 March 2014 at 13:43, Dharmender Goyal wrote: >> > >> > > Partially yes, my code logic will be a major factor. >> > > What I want to know is any framework overhead - perhaps related to >> > repository reference lookups, class loading etc. I will run a >>performance >> > and soak test cycle but can benefit from prior experience of fellow >> users. >> > > >> > > Thanks >> > > >> > > >> > > On Friday, March 14, 2014 9:28 AM, Neil Bartlett >><njbartl...@gmail.com >> > >> > wrote: >> > > All of these concerns -- performance, security, etc -- are pretty >>much >> > orthogonal to OSGi. That is, it depends entirely on the code you run >> inside >> > OSGi rather than on OSGi itself. >> > > >> > > Regards, >> > > Neil >> > > >> > > >> > > On Fri, Mar 14, 2014 at 12:14 PM, Dharmender Goyal <dgo...@yahoo.com >> (mailto: >> > dgo...@yahoo.com)> wrote: >> > > > Hello >> > > > I am evaluating use of OSGI bundle based design to replace an >> existing >> > high volume, multi-user (1000+) J2EE implementation. My prototypes >>are >> > working but want to know of any potential issues with deadlocks, >> > performance, security, scalability etc. >> > > > Is there anyone using OSGI bundles for large scale >>implementations, >> > possibly with JBoss, WAS or Tomcat? Any suggestions? >> > > > >> > > > Thanks >> > > > >> > > > Dharmender Goyal >> > > > dgo...@yahoo.com (mailto:dgo...@yahoo.com) >> > > >> > > >> > >> > >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect >> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
