So you're saying that I should give it more time to get things set up? How long should I wait?
What can I do (if anything) to use JmsFlow instead of ActiveCluster now without waiting for version 2? > 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.
