On 2/16/2016 9:20 AM, Johannes Utzig wrote:
Thank you for your swift response.
I see what you mean. I think r-OSGi (at least combined with zookeeper
discovery) isn't really meant to run between two instances on the same
machine.
Yes, that's correct.
However, since r-OSGi ended up killing my karaf instance quite a few times I
think this is probably not a transport we'd want to employ right now.
Instead I switched to ecf.generic.server which works out of the box.
I ran our simple benchmark which calls a remote service 1000 times with 5
parallel threads and compares the execution time with RMI (each call sends
and receives a string array).
ecf.generic.server seems to be roughly 10 times slower than RMI, but the
strange part is, with each invocation it becomes slower. Please see the test
output below:
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 6838 milliseconds. Parallel level is
5
Test parallel RMI completed in 829 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 6188 milliseconds. Parallel level is
5
Test parallel RMI completed in 649 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 8024 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 10415 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 12628 milliseconds. Parallel level is
5
Test parallel RMI completed in 176 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 14125 milliseconds. Parallel level is
5
Test parallel RMI completed in 184 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 16330 milliseconds. Parallel level is
5
Test parallel RMI completed in 191 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 18014 milliseconds. Parallel level is
5
Test parallel RMI completed in 189 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 21011 milliseconds. Parallel level is
5
Test parallel RMI completed in 186 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 22741 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
This persists until I restart the karaf instance that provides the service.
Would it be possible for you to make this test/benchmark code
available? We haven't seen this pattern before, and I would like to
use it to determine what is going on.
We are looking for perfomance similar to RMI and the fabric implementation
was able to provide that.
Now to my understanding we could implement a distribution provider based on
the fabric code that could be used by ECF.
Yes, that's right.
Unfortunately, I am a bit unsure on how to do this. I looked at
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
and a lot of additional documentation but so far I am still a bit unsure on
how to proceed or which is the minimal set of dependencies I would need.
I also noticed that the ECF artifacts on maven central are very outdated, so
I probably cannot use them to compile against. Are there plans to publish
up-to-date artifacts to central for easier consumption?
We routinely make a maven repository available as part of our releases
[1]. The primary reason why we don't put these on maven central is that
we are currently not able to include the dependencies that we have on 3
equinox 'extra' bundles. FWIW we would very much like to get this
worked out an publish regularly to maven central but the equinox deps
make this complicated.
Would this serve as a mimimal example on how to implement a new TCP based
distribution provider, or should I use a different implementation as a
template?
https://github.com/eclipse/ecf/tree/master/providers/bundles/org.eclipse.ecf.provider.r_osgi/src/org/eclipse/ecf/internal/provider/r_osgi
We have recently created a distribution provider API [2] (see toward
end) in order to make it easier to create custom providers and register
them via the whiteboard pattern. There is dependency information
about the bundle containing this API (org.eclipse.ecf.remoteservice) on
this new documentation page [3].
As for existing providers as examples, I would suggest looking at the
providers that have recently been created using this new distribution
provider API [4].
I am in the process of creating a tutorial about the use of this new
distribution provider API. If you would like, I will assist you in
creating this new provider (we can host at ECF's github site if you
like: https://github.com/ECF ) and I can use it as a way to complete
this tutorial.
Scott
[1] https://www.eclipse.org/ecf/downloads.php
[2] https://www.eclipse.org/ecf/NewAndNoteworthy_3.12.1.html
[3] http://wiki.eclipse.org/Distribution_Providers
[4] https://github.com/ECF/JaxRSProviders
https://github.com/ECF/HazelcastProvider
https://github.com/ECF/Mqtt-Provider
Best regards,
Johannes
--
View this message in context:
http://karaf.922171.n3.nabble.com/Proposal-Lightweight-standalone-remote-OSGi-implementation-for-karaf-cellar-tp4045343p4045394.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
