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. 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. 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. 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? 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 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.
