Skip to content
This repository has been archived by the owner on Jul 10, 2024. It is now read-only.

GridWeaver

Philipp Haussleiter edited this page Nov 25, 2015 · 1 revision

Grid Weaver

The weaver is code that hooks into the OSGi framework implementation to modify service implementations in order to make them griddy. That is, it injects aspects into classes you would like to execute not just locally, but also remotely.

The actual weaving is done at classloading time. More about that ClassloadingAspectweaving.

To control, which methods are actually modified, you must set the system property org.bundlebee.weaver.instrumentedmethods to a semicolon separated list of regular expressions describing method signatures.
E.g., to instrument all methods in TestBundleImpl use this when starting the VM:


-Dorg.bundlebee.weaver.instrumentedmethods=org\\.bundlebee\\.testbundle\\.impl\\.TestBundleImpl\\..*

Note that for Equinox, you should simply add a line to the config.ini file like this (same is true for the dispatch strategy):

org.bundlebee.weaver.instrumentedmethods=org\\.bundlebee\\.testbundle\\.impl\\.TestBundleImpl\\..*

But what does the aspect do?

Well, first of all it asks which GridManager/node the method call should be sent to. The answer to this question is either a URL, if it should be executed remotely, or null/ServiceCallAspect.LOCAL_URI, if it should be executed locally.
If the call should be executed remotely, the corresponding manager is asked to execute it. Should the remote call fail for technical reasons, we fall back to the local implementation.

In either case, we time all calls that succeed without throwing an exception, assuming that exceptions are indeed exceptional and do not represent the true execution time for a successful call accurately. Per URL execution times are available from ServiceCallStats.

So how do we come up with the GridManager/node URL?

There really isn’t a RightWay�. But the GridRegistry and ServiceCallStats give us some hints that we can exploit in an appropriate algorithm.

The registry, e.g. lets us find out on what nodes in the grid the required bundle is already running or already installed. Thanks to the GridWatchdog we can also lookup what the memory situation is on different nodes.

To allow choosing an appropriate strategy, you can set it using the system property org.bundlebee.weaver.servicecalldispatchstrategy. Point it to the name of a class that implements org.bundlebee.weaver.ServiceCallDispatchStrategy. (note, that the interface might need to be moved to a different package)

Clone this wiki locally