Remoting version of CafeDemo

[alca]

Hi,

I have been trying to make a remoting version of DafeDemo, using RMI for the transport.

I put the Barista in one module called the "server" and the rest in another module called the "client", except for Drink and DrinkType that goes in a "common" module.

Here is the configuration for the server:

  <integration:message-bus/>

  <integration:channel id="coldDrinks"/>
  <integration:channel id="hotDrinks"/>

  <integration:rmi-gateway id="rmiSourceColdDrinks" request-channel="coldDrinks"/>
  <integration:rmi-gateway id="rmiSourceHotDrinks" request-channel="hotDrinks"/>

  <integration:service-activator input-channel="coldDrinks" ref="barista" method="prepareColdDrink"/>
  <integration:service-activator input-channel="hotDrinks" ref="barista" method="prepareHotDrink"/>

  <bean name="barista" class="integration.samples.cafe.server.Barista"/>

and her is the configuration for the client:

  <message-bus/>
  
  <channel id="orders"/>
  <channel id="drinks"/>
  <channel id="coldDrinks"/>
  <channel id="hotDrinks"/>
    
  <rmi-handler id="rmiTargetColdDrinks" remote-channel="coldDrinks" host="localhost" />   
  <rmi-handler id="rmiTargetHotDrinks" remote-channel="hotDrinks" host="localhost"/>
             
  <beans:bean id="drinkRouter" class="integration.samples.cafe.client.DrinkRouter"/>
  <router input-channel="drinks" ref="drinkRouter" method="resolveDrinkChannel" />

  <beans:bean id="orderSplitter" class="integration.samples.cafe.client.OrderSplitter"/>
  <splitter input-channel="orders" output-channel="drinks" ref="orderSplitter" method="split"/>

  <service-activator input-channel="coldDrinks" ref="rmiTargetColdDrinks"/>
  <service-activator input-channel="hotDrinks" ref="rmiTargetHotDrinks"/>

  <beans:bean id="cafe" class="integration.samples.cafe.client.Cafe">
    <beans:property name="orderChannel" ref="orders"/>
  </beans:bean>

and here is the display from the server:

INFO: message bus started
message-bus-2 prepared cold drink #1: iced 3 shot MOCHA
message-bus-1 prepared hot drink #1: hot 2 shot LATTE

Then, the server seems to be sleeping, while the client has splitted and routed all messages. Only if I stop the server, the client will try sending the other messages and get an error since the server is down.

Does anyone knows why the server is blocking on each channel and how to avoid this?

Thanks!

[Mark Fisher]

Can you try setting the 'expect-reply' value to false on those RmiGateways?:

<integration:rmi-gateway id="rmiSourceColdDrinks"
                         request-channel="coldDrinks"
                         expect-reply="false"/>

<integration:rmi-gateway id="rmiSourceHotDrinks"
                         request-channel="hotDrinks"
                         expect-reply="false"/>

The initial requester thread is waiting for the reply, but the Barista has a void return (only prints out a message).

[alca]

Hi Mark,

Thanks for your answer (and sorry for cross-posting). It works fine with this configuration.

I missed the info because I dit not realize that <xsd:extension base="gatewayType"> means that the listed attributes are to be added to the base type.

[Mark Fisher]

Perhaps we should consider defining 'expect-reply' as a required attribute in the XSD. Even though it is a simple boolean, this might help to clear up the confusion, and arguably, there is no strong default value. What do you think?

[alca]

This is an interesting question. A "true" default value makes sense when the call is returning something. But with a void type, a "false" default value seems to make sense. However, I can imagine examples where we would want a void reply (to make the call synchronous) or where we would want to ignore a returned value (although I would probaly not advocate this kind of use case).

In fact, I do not know Spring-Integration enough at that time to say if a default value is a good thing for this property. It seems that having no default value would probably help in learning the way it works by making the value explicit to the programmer.

Beside this, what would probably be the more usefull is a reference of all elements and properties with an explanation of the way they should be used, but I understand it is a big job with a low priority. Reading the XSDs does the job, as long as the reader understands it, which was not my case for this problem. But because of this problem, and with your help, I have learnt not only how rmi-gateway works but also how xsd:extension (and BTW xsd:restiction) works. So, for me, it's perfect like this.

Pierre-Yves

[iwein]

This is an interesting question. A "true" default value makes sense when the call is returning something. But with a void type, a "false" default value seems to make sense. However, I can imagine examples where we would want a void reply (to make the call synchronous) or where we would want to ignore a returned value (although I would probaly not advocate this kind of use case).

In fact, I do not know Spring-Integration enough at that time to say if a default value is a good thing for this property. It seems that having no default value would probably help in learning the way it works by making the value explicit to the programmer.

Beside this, what would probably be the more usefull is a reference of all elements and properties with an explanation of the way they should be used, but I understand it is a big job with a low priority. Reading the XSDs does the job, as long as the reader understands it, which was not my case for this problem. But because of this problem, and with your help, I have learnt not only how rmi-gateway works but also how xsd:extension (and BTW xsd:restiction) works. So, for me, it's perfect like this.

Pierre-Yves

I think you could better learn the xsd fine with Ctrl-Space in eclipse (that would show you the attribute without you having to parse the xsd in your head), the SpringSource Tool Suite does this out of the box, but with a vanilla Eclipse you have to add wtp I think. Reading xsd might be a useful exercise, but it is definitely time consuming.

As for the defaults, I am in love with sensible defaults. What's wrong here with SI's behavior is that:

1. it assumes you want a reply while it doesn't create a reply out of void
2. it doesn't time out (with a descriptive error)

Especially the first point bugs me because SI could have known that it wasn't going to work, right? (Figuratively speaking of course)

Your response makes me think there is a more elegant set of defaults that would resolve the problem than just making the attribute required, although that would work better than what we have now.