You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Dharmender Goyal <dg...@yahoo.com> on 2014/03/14 13:14:06 UTC
Anyone using OSGI bundles for high volume OLTP applications
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
dgoyal@yahoo.com
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Dawid Loubser <da...@travellinck.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Dharmender,
This is probably a bit off-topic for the Felix mailing list, per se, but
let me give a quick response.
We run a pretty large, highly-concurrent supplier integration
infrastructure using OSGi. Many concurrent processes interacting with
all sorts of supplier systems over HTTP/SOAP, and lots of internal data
transformation, filtering, etc.
This runs in JBoss 7, as the back-end to a Java EE front-end / EJB + JPA
for storage.
We used to run a JBI-based ESB (Apache Servicemix), where all internal
communication was via XML. The performance and flexibility increase
moving to pure OSGi has been incredible.
OSGi, unlike Java EE, does not manage threads for you at all. It's up to
you to decide how the concurrency will work - and in general, you have
to write all your OSGi services in a thread-safe manner.
Our JBoss front-end just bombards our OSGi system with as many
concurrent calls as needed, and because all our OSGi services are
stateless and thread-safe, it all just works.
We manage our own concurrency (for example, limit number of concurrent
calls to a particular supplier) by using Java Executors with fixed
thread pool sizes, etc - in each OSGi service that needs this.
Off the bat, there are certain things that Java EE gives you that makes
your life much easier than with OSGi, but for other problems, the
modularity, classloading, and hot-pluggability on a per-component level
of OSGi is best.
I think we could only give you good advice if you tell us a bit about
the type of system you are building. For example, OSGi excells at short,
synchronous processes. If you need long-running processes with a lot of
asynchronicity, where you never want to lose process state, Java EE does
quite a bit better. This is why we have a hybrid. Most good Java EE
servers (JBoss/Wildfly, Glassfish) allow you to build nicely-integrated
OSGi + EE systems.
have fun,
Dawid Loubser
On 14/03/2014 14:14, Dharmender Goyal 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
> dgoyal@yahoo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlMi+3oACgkQRCSAiuVqs4PvAAD/ZefvUyy42piZGAFvIbmGZ94O
8I5DauXM8TDdXo+xWIcBALCVX6JptYo4riWIHiUmH9Y3Zc60Ebbx6NVuKaNmbpjc
=Ma0E
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Raymond Auge <ra...@liferay.com>.
On Fri, Mar 14, 2014 at 11:39 AM, Nick Baker <nb...@pentaho.com> wrote:
> 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.
>
Absolutely agree!
And I think really understanding the whiteboard pattern is essential for
this and it needs to be baked into your design. It's really the primary, if
not the only, way the registry should integrate with your application.
- Ray
>
> -Nick Baker
>
> On 3/14/14, 11:12 AM, "Jeremy Jongsma" <je...@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
> ><ra...@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 <nj...@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
> >><njbartlett@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 <
> dgoyal@yahoo.com
> >> (mailto:
> >> > dgoyal@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
> >> > > > dgoyal@yahoo.com (mailto:dgoyal@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Nick Baker <nb...@pentaho.com>.
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" <je...@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
><ra...@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 <nj...@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
>><njbartlett@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 <dgoyal@yahoo.com
>> (mailto:
>> > dgoyal@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
>> > > > dgoyal@yahoo.com (mailto:dgoyal@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Jeremy Jongsma <je...@barchart.com>.
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 <ra...@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 <nj...@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 <njbartlett@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 <dgoyal@yahoo.com
> (mailto:
> > dgoyal@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
> > > > dgoyal@yahoo.com (mailto:dgoyal@yahoo.com)
> > >
> > >
> >
> >
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Peter Kriens <pe...@aqute.biz>.
The key aspect what is discussed here is cohesion. The trick of good software design is that one unit of code has a single responsibility. If I write middleware, OSGi is my best friend. If I write a tax return handling application, OSGi should be not even smellable. So Ray, you're very right from the perspective of a business code developer but OSGi is definitely in your process path when you write support bundles for those business developers.
Again, this is the standard 1970's software mantra: High cohesion, low coupling. Know what the unit's responsibility is and fight the tendency to just add this little extra thing because you do not want to create another unit.
Kind regards,
Peter Kriens
On 14 mrt. 2014, at 15:29, Raymond Auge <ra...@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 <nj...@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 <nj...@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 <dgoyal@yahoo.com(mailto:
>> dgoyal@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
>>>> dgoyal@yahoo.com (mailto:dgoyal@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Raymond Auge <ra...@liferay.com>.
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 <nj...@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 <nj...@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 <dgoyal@yahoo.com(mailto:
> dgoyal@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
> > > dgoyal@yahoo.com (mailto:dgoyal@yahoo.com)
> >
> >
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Neil Bartlett <nj...@gmail.com>.
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 <nj...@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 <dgoyal@yahoo.com (mailto:dgoyal@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
> > dgoyal@yahoo.com (mailto:dgoyal@yahoo.com)
>
>
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Dharmender Goyal <dg...@yahoo.com>.
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 <nj...@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 <dg...@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
>dgoyal@yahoo.com
Re: Anyone using OSGI bundles for high volume OLTP applications
Posted by Neil Bartlett <nj...@gmail.com>.
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 <dg...@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
> dgoyal@yahoo.com