On 12/6/10 15:26, Martin Petzold wrote:
This is indeed my main focus, to have it working on the service layer.
I still would like to have the option to move components from one to
another node via uninstalling and installing them (e.g. for load
balancing or virtual worlds with dynamic responsibility of component
processing).
This seems like a type versus instance question. Just because you deploy
a type on one node, doesn't necessarily mean you have an instance
there...that depends on your configuration. However, your approach will
work, so do what you think is best. I'm just not sure the performance
strain will be worth it.
-> richard
Am 06.12.2010 21:09, schrieb Richard S. Hall:
On 12/6/10 14:33, Martin Petzold wrote:
Thanks for any feedback! This is already possible, it's up to the
modeler, but you then lose some dynamism. The modeling formalism is
based on a class per component (this is being mapped to a service
then).
If component interaction happens via service, then you shouldn't need
to lose any dynamism, since service are more lightweight dynamic than
bundles. Just enable/disable the component.
-> richard
Am 06.12.2010 20:19, schrieb Richard S. Hall:
Seems like you'd be better off breaking the
one-component-per-bundle model and instead map many components into
a single bundle.
-> richard
On 12/6/10 14:02, Martin Petzold wrote:
Hi Simon.
For my thesis I'm working on a dynamic distributed simulation
architecture based on OSGi and with Remote Services (more
scientific than business use case of course). Every component of
my model is mapped to an OSGi component (bundle and a service), so
it's easy to develop and extend the simulation (also while
simulation time), work on shared models and of course have
integration in Eclipse (if desired).
Distributed simulation is about simulating big models (analytical)
and also real-time models (such as virtual environments, e.g.
second life). So I would like to have a feeling of the number of
components which can be simulated per simulation node. Performance
is not my key concern at the moment but I will of course do some
performance and converging tests too. I will have generated models
of different size an will let them run on one to X nodes (so in
the first case to whole model is in one OSGi framework). I can
post my result about performance once I've done everything. The
simulation does seem to work quite nice already (model with two
components ;-)), still some problems with distributed connection
and eventing though.
Am 06.12.2010 19:28, schrieb Simon J Archer:
Martin
Maybe you could share with us the scenario that you're addressing
that requires 65000 bundles. Just because you can does not mean
that you should. :-)
Thanks
Simon
From: Martin Petzold <mpetz...@gmx.net>
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Date: 12/06/2010 11:07 AM
Subject: Re: [osgi-dev] Maximum number of bundles and
services in one OSGi framework
Sent by: osgi-dev-boun...@mail.osgi.org
------------------------------------------------------------------------
Thanks for all feeback!
I'm going to try up to 65000 with heavy load soon, lets see if I get
them installed and running...
Am 06.12.2010 16:31, schrieb Jeff McAffer:
> Commercial products with 5000+ bundles have been shipping for
some years on Equinox. Dunno about service counts but there are
no real limits in the spec.
>
> Jeff
>
> On 2010-12-05, at 5:22 PM, Martin Petzold wrote:
>
>> Hi folks,
>>
>> what is the maximum number of bundles and services I can
install/register in one OSGi framework? What is the maximum
amount of remote services in a service environment, probably =
max. of in one OSGi framework? Is the limitation on some type of
identifier or is it the number of threads the JVM can provide or
something different? Of course memory in the end...
>>
>> How many bundles and services have you already had running in
one OSGi framework?
>>
>> Thanks,
>>
>> Martin
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Martin Petzold
Martinsfeld 14
D-50676 Köln
Deutschland
Telefon: +49 (0)221 / 2595961
Mobil: +49 (0)179 / 9220154
Blog: www.zetablog.de
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
