Hi,
I just ran into the famous deadlock with Java 6 where the same class is being
loaded from two different bundles (also see FELIX-3953). This happened on a
startup of a CQ instance.
I'll add more analysis details but my question is: what is the suggested best
practice to handle this issue?
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 lar
-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 wit
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 wrote:
> Hello
> I am evaluating use of OSGI bund
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
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
--
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
s
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 star
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 se
On Fri, Mar 14, 2014 at 11:39 AM, Nick Baker 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 f
10 matches
Mail list logo
