I tried giving the cluster adequate time to configure itself--I started
everything up, then went to dinner before actually hitting the button
that sends the message. No luck. You see, I think that the instances see
each other because...
* They are on the same machine (in fact, both the client and the
service containers are currently running in Eclipse for
convenience-sake).
* The client container, when run by itself, gives a warning when the
message is sent indicating that it knows nothing about the service.
* When the service container starts up, I see activity in the log
file for the client indicating that it knows about the service
container.
* Once the service container starts up, the client container quits
giving warnings about not knowing the service. From all
indications on the client-side, the message was successfully sent
(even though the service never receives the message).
I appreciate that I *could* use JmsFlow, but is there no way that I can
get cluster flow to work with version 1.0.1? I'm quite certain that
there's some configuration that I'm missing that would make the magic
happen, but I just don't know what it is (I'll be examining the SM
unit-tests today to see if I can discover any clues).
While we're somewhat on the subject, what is the timeline for an
official release (or even a milestone release) of version 1.1 that has
JmsFlow built-in? I don't mind using SNAPSHOT JARs or building it myself
from Subversion, but I'd rather not if I don't have to.
Rob Davies wrote:
Hi Craig,
There is a couple of issues that this could be - the cluster doesn't
have enough time to configure itself before you're test starts
(limited a bit by ActiveCluster in this regard) or the instances
aren't able to discover each other (multicast is used for this).
I'm thinking of depreciating ActiveCluster for version 2 because it's
functionality can be replaced entirely by the JmsFlow.
cheers,
Rob
On 24 Oct 2005, at 04:41, Craig Walls wrote:
I've got a simple ServiceMix example that I'm using as a
demonstration of using Spring with ServiceMix. It works wonderfully
when using ST flows (and I've had some success with SEDA flows).
Here's what the configuration looks like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<container id="jbi">
<components>
<component id="billing"
service="bar"
class="com.habuma.telco.sm.components.BillingServiceImpl">
<property name="frame">
<bean class="com.habuma.telco.sm.ComponentFrame">
<constructor-arg value="BILLING"/>
</bean>
</property>
</component>
</components>
</container>
<bean id="smClient"
class="org.servicemix.client.DefaultServiceMixClient">
<constructor-arg ref="jbi"/>
</bean>
<bean id="clientUI"
class="com.habuma.servicemix.ClientUI">
<property name="serviceMixClient" ref="smClient" />
</bean>
</beans>
There's a lot of extra stuff going on here so that each service (and
the client) has a JFrame so that I can visually follow what's going
on. But in summary, the BillingServiceImpl extends ComponentSupport
and the "clientUI" uses the "smClient" bean to send messages to the
"billing" component. This works like a champ.
But for grins I decided to give cluster flows a spin. Here are my
two new configuration files (one for the client and one for another
container that contains the billing service):
=============== CLIENT CONFIGURATION===============
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<container id="jbi">
<!-- MAGIC TO MAKE THE CONTAINER PART OF A CLUSTER -->
<property name="flowName" value="cluster"/>
<property name="name" value="client"/>
</container>
<bean id="smClient"
class="org.servicemix.client.DefaultServiceMixClient">
<constructor-arg ref="jbi"/>
</bean>
<bean id="clientUI"
class="com.habuma.servicemix.ClientUI">
<property name="serviceMixClient" ref="smClient" />
</bean>
</beans>
======= SERVICE CONTAINER CONFIGURATION======
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<container id="jbi">
<!-- MAGIC TO MAKE THE CONTAINER PART OF A CLUSTER -->
<property name="flowName" value="cluster"/>
<property name="name" value="services"/>
<components>
<component id="billing"
service="bar"
class="com.habuma.telco.sm.components.BillingServiceImpl">
<property name="frame">
<bean class="com.habuma.telco.sm.ComponentFrame">
<constructor-arg value="BILLING"/>
</bean>
</property>
</component>
</components>
</container>
</beans>
I know that this *SORTA* works because: (1) When I fire up the
client by itself I get an appropriate error when sending the message
indicating that the "billing" service isn't found. (2) When I fire
up the service container, the client log file goes through a flurry
of activity indicating that the client is being alerted to the
existence of the "billing" service. (3) When both the client and the
service containers are running, the client can successfully send
messages...at least from the client's perspective it's successful.
But the "billing" service never receives the message. The only thing
of interest in the log files is a message on both ends saying
"WARNING: No remote broker name available!". This message appears
during the flurry of activity when the two containers sync up.
So, what am I possibly doing wrong? Is there something I'm missing
to specify the remote broker name? Any help will be greatly
appreciated. If I've not provided enough info, please let me know
and I'll send whatever you need to help figure this one out.
