RMI client to multiple servers

[naor]

Hi,

I'm trying to replace my EJB calls (done through spring) with RMI.
My service is being exported on multiple servers in a cluster.
in the example taken from SpringInAction book the client references to a single host:

<bean id="paymentService"
class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
<property name="serviceUrl">
<value>rmi&#58;//$&#123;paymenthost&#125;/PayService</value>
</property>
<property name="serviceInterface">
<value>com.springinaction.payment.PaymentService</value>
</property>
</bean>

Is there a way to specify a list of hosts?
Or should I implement my own solution for round-robin calls?

Thanks,

NY

[derek]

I'm also interested in any comments on this post.

Not only with regard to RMI clients but also SOAP clients using multiple servers.

As far as I can see, the proxies provided by Spring for creating such clients only take one server address.

Thus if one wants loadbalancing or failover for the servers, this has to be implemented externally through dns round robin or a load balancing service of some sort.

Is this the approach that is generally used?

In the past I've written my own proxies to take multiple server addresses.

Interested in any comments / experiences.

[Alarmnummer]

Mabe a new bean could be created that accepts a list with normal references (those references could be pointing to remote objects created by a RmiProxyFactoryBean for example) and some kind of selection strategy.


Example:

<bean id="paymentService1"
          class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
    <property name="serviceUrl">
          <value>rmi&#58;//$&#123;paymenthost&#125;/PayService</value>
    </property>
    <property name="serviceInterface">
          <value>com.springinaction.payment.PaymentService</value>
    </property>
</bean>

<bean id="paymentService2"
   class="org.springframework.remoting.other.HessianProxyFactoryBean">
   <property name="serviceUrl">
        <value>hessian&#58;//$&#123;paymenthost&#125;/PayService</value>
   </property>
   <property name="serviceInterface">
        <value>com.springinaction.payment.PaymentService</value>
    </property>
</bean>

<bean 	id="paymentService"
		class="LoadBalancingFactoryBean">
	
	<property name="serviceList">
		<list>
			<bean ref="paymentService1"/>
			<bean ref="paymentService2"/>			
		</list>
	</property-arg>	
	
	<property name="selectionStrategy">
		<bean class="RoundRobin"/>
	</property>

	<property name="serviceInterface">
		<value>com.springinaction.payment.PaymentService</value>
	</property>
</bean>

It wouldn`t be a problem to add failover to the LoadBalancingFactoryBean.

[derek]

That sounds like a good design.

Still interested to hear how others are doing this currently.

[Alarmnummer]

That sounds like a good design.

Still interested to hear how others are doing this currently.

I have created a JIRA request:
http://opensource2.atlassian.com/pro...rowse/SPR-1350

[derek]

Good. I've added my vote to that.

[naor]

thanks for the reply.

I will add my vote too

[derek]

Thought a bit more about that design. It is certainly a nice clean way to add load balancing or failover functionality. And would be easy to implement it with regard to failover. However, thinking about a decent load balancing implementation raises a few difficulties.

A simple round robin solution with a pool of service beans is easy enough.

Service failure can be handled easily too. If one of the service beans fails (i.e. throws a connection related exception) it could be removed from the pool.

However a decent load balancing solution should also be able to detect if one of its service beans recovers and can be returned to the pool without manual intervention otherwise it may eventuall run out of active service beans.

Don't see how this can be done if the LoadBalancingBean only knows about the service interface.

[dvoytenko]

A simple round robin solution with a pool of service beans is easy enough.

I'm not quite sure load-balancing would be so transparent as a simple object pool. It might require special API for implementing "sticky" sessions (or something like EJBHandle).

[Alarmnummer]

A simple round robin solution with a pool of service beans is easy enough.

I'm not quite sure load-balancing would be so transparent as a simple object pool.

It depends if the services are statefull or stateless. Most services I create are stateless (all state can be found in the database). But for statefull services the current solution wouldn`t be enough.