Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] remote services, load balancing

Hi Wim,

I suppose that you could use service ranking to achieve load balancing, but that would have some serious disadvantages. What I mean by that is that using service ranking for 'poor man's' load balancing would mean that:

1) The consumer would have to call getServiceReferences on their own to get/use a new service reference (with the current highest ranking). That adds a good deal of complexity on the client side (managing the service reference yourself, instead of having ds or servicetracker do it). 2) With such a scheme the 'load balancing' would only be done at the service level. It's often convenient to have load balancing be done at the *method* level (for the service interface)...and that's one of the advantages of what's described here:

http://wiki.eclipse.org/Load_Balancing_Remote_Services

A single proxy, when used by a client (transparently...i.e. the client can just call methods on the client proxy), the *individual method calls* are load balanced among n implementers of that service. Thus the client doesn't have to get a new service reference, and can just call the methods on that service reference multiple times...and those individual method request/responses will be load balanced among the n servers.

So I would say that yes, you can do poor man's load balancing as you described using service ranking, but it makes things fairly complex for the client...and doesn't provide a high degree of resolution...i.e. it's desirable to be able to load balance a single service/service reference (as the ECF load balancing does)...for simplicity and flexibility.

Scott


Wim Jongman wrote:
Is it possible for a service to change its SERVICE_RANKING after a service request is received by changing its ServiceRegistration object and changing this back again after the request has been fulfilled? To have some poor mans load balancing?


as per OSGi core: 5.2.7 Locating Services
client: Service = getServiceReferences("heavy.used.service");
Service.doWork();


as per OSGi core: *5.2.3 Registering Services*
server:
doWork(){

myServiceRegistration.setProperty(SERVICE_RANKING, LOW);
workworkwork
myServiceRegistration.setProperty(SERVICE_RANKING, HIGH);

http://www.osgi.org/javadoc/r2/org/osgi/framework/Constants.html#SERVICE_RANKING

Regards,

Wim



On Mon, Apr 26, 2010 at 5:08 PM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>> wrote:

    Hi Greg,

    Greg House wrote:

        Hello,

        I am moving the discussion
        (http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121
        <http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121>
        <http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121
        <http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121>>)
        to the mailing list as requested by Scott.


        Sorry if this e-mail is too long. I will explain the use-case
        I am trying to implement.

        Consider two or more OSGi platforms. Each platform exports
        (remote) services that the other platforms can use.
        At any time a new platform can appear (or disappear) and the
        other platforms should be able to see and use the new services
        without any additional
        configuration or restart.
        Because some of the services are expensive and time-consuming
        operations I want to be able to deploy them on
        several machines and the requests to these services to be
        load-balanced. In addition, I want to be transparent for a
        consumer
        if a local or a remote service is used. I don't want in my
        code to import any OSGi packages.

        For the platform and remote services implementations I am
        using Equinox and ECF.

        Now I know that if we remove the load-balancing requirement
        all this can be implemented with (remote) declarative services.
        Moreover, the distribution and discovery providers can be
        independently selected.

        However, the OSGI specification does not say anything about
        load-balancing, so one has to use some “nonstandard” approach and
        stick to specific distribution and discovery providers (and
        external components) – is my understanding correct?


    Yes.


        The ECF has a solution to load-balance remote-services with
        JMS/ActiveMQ.
        For my use-cases it is OK to use ECF ActiveMQ provider and
        maintain separate ActiveMQ installations. However, is it
        possible the
        usage of services to be transparent for the consumers? The
        service providers define the properties (local, remote,
        load-balanced)
        of their implementation and the consumers just use the services?


    Yes, this is correct.  The load-balanced service usage can be
    transparent for the consumers.




        I tried to convert the
        org.eclipse.ecf.examples.loadbalancing.* examples to
        declarative services and to remove all ECF references from the
        code
        but with no success.


    What went wrong?   I don't immediately see a reason why this
    wouldn't work...for the loadbalancing consumer/client.



        The conversion of
        org.eclipse.ecf.examples.loadbalancing.server to declarative
        services is straightforward.

        About org.eclipse.ecf.examples.loadbalancing.servicehost I
        created the following OSFI-INF/component.xml:

        <?xml version="1.0" encoding="UTF-8"?>

          <implementation class="null" />
          <property name="service.exported.interfaces" type="String"
        value="*"/>
          <property name="service.exported.configs" type="String"
        value="ecf.jms.activemq.tcp.manager.lb.svchost"/>
          <property name="org.eclipse.ecf.containerFactoryArgs">
              tcp://192.168.1.1:61616/exampleQueue
        <http://192.168.1.1:61616/exampleQueue>
              tcp://192.168.1.1:61616/exampleTopic
        <http://192.168.1.1:61616/exampleTopic>
          </property>
          <property name="ecf.rsvc.proxy" type="String" value="true"/>
           <service>
             <provide
        interface="org.eclipse.ecf.examples.loadbalancing.IDataProcessor"/>
          </service>
          <reference cardinality="1..1"
        interface="org.eclipse.ecf.core.IContainerFactory"
        name="IContainerFactory" policy="static"/>
        </scr:component>

        Should I use the service.exported.interfaces property? Is
        <implementation class="null" /> correct?


    I would have to check the ds spec, but no, I don't think that
    'null' is allowable for the implementation class.



        The main problem I have is with
        org.eclipse.ecf.examples.loadbalancing.consumer.
        I created the following OSGI-INF/component.xml file:

        <?xml version="1.0" encoding="UTF-8"?>

          <implementation
        class="org.eclipse.ecf.internal.examples.loadbalancing.consumer.DataProcessorConsumerApplicationDS"/>
          <reference bind="doTests" cardinality="0..n"
        interface="org.eclipse.ecf.examples.loadbalancing.IDataProcessor"
        name="IDataProcessor" policy="dynamic"/>
        </scr:component>

        Is this somehow related to DefaultProxyContainerFinder and
        should I specify “ecf.jms.activemq.tcp.client” in the config file?


    I first have to ask whether you  are using the latest from HEAD or
    ECF 3.2.  The reason I have to ask is that *since* 3.2 release the
    policy for handling automatic creation of containers in
    DefaultProxyContainerFinder has changed as per this bug:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979

    Now (in HEAD/3.3/Helios), the default is to automatically create a
    container instance when discovered.

    *BUT*...even if you are using HEAD....I think that there could be
    a bug in the ActiveMQ/JMS provider.  Specifically, when containers
    are discovered, and the DefaultProxyContainerFinder is consulted
    to find a suitable container, part of what the
    DefaultProxyContainerFinder does (using the auto create option
    that was changed in 303979) is that it gets the meta-data from the
    discovery and looks for a *compatible* container type.  By
    'looks', I mean that it calls this method on container instantiatiors:

    org.eclipse.ecf.core.provider.IRemoteServiceContainerInstantiator.getImportedConfigs(ContainerTypeDescription,
    String[])

    And if the provider on the consumer responds with a non-null
    String array, then it has a match.

    But it is quite possible that the JMS/ActiveMQ provider
    implementation of the getImportedConfigs method does not match
    with the load balancing container types (as these are 'special'),
    returns null, and the client container is never created/found by
    the DefaultProxyContainerFinder on the consumer.   Does this fit
    with what you are seeing?   BTW...what discovery mechanism are you
    using?  And do you have evidence that it is working properly on
    your net?

    I will be happy to look into this later today/Monday and fix it if
    necessary, but would it be possible to get your declarative
    services versions of the load balancing example so that I can
    test?  Would you possibly be willing to contribute these projects
    as ECF examples?


        How is "cardinality" handled in the case of load-balanced service?


    The cardinality is handled as with a 'normal' declarative
    service...i.e. the cardinality will determine whether the
    component is activated if the given reference is present (1...n)
    or not (0...n).



        I would appreciate any help or directions how to proceed.


    I think the bug with the JMS/ActiveMQ provider I described above
    *may* be the issue.  If you can help me diagnose and test we
    should get it going in short order.


        More important, is my use-case achievable with Equinox and ECF?


    Yes, it is.

    Scott


    _______________________________________________
    ecf-dev mailing list
    ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/ecf-dev


------------------------------------------------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



Back to the top