I am using Mule as ESB solution. I have a queue, from where i am getting messages and trying to make http request to service that is failing all the time.
I have configured the RedeliveryPolicy on ActiveMQ like this:
<spring:bean id="retryRedeliveryPolicy" class="org.apache.activemq.RedeliveryPolicy"
name="retryRedeliveryPolicy">
<spring:property name="maximumRedeliveries" value="76" />
<spring:property name="initialRedeliveryDelay" value="300000" />
<spring:property name="maximumRedeliveryDelay" value="3600000" />
<spring:property name="useExponentialBackOff" value="true" />
<spring:property name="backOffMultiplier" value="2" />
<spring:property name="queue" value="*" />
</spring:bean>
It retries after 5min. then 10min ,20,40,60,60,60... For about ~ 3days
The problem is, that Retry logic is non persistent.
Lets say, message was retrying for 2 days. And i have deployed new version of mule app, or restarted server... In this case, retry logic will start all over again from 5min, 10min.... Because retry state is kept in RAM memory by the Client.
Hot to make RedeliveryPolicy persistent? It must keep retrying for 1 more day after i will restart the server after 2 days.
One solution i think might be to set timeToLive for 72 hours for message. But even then after restarting server. It will not retry every hour from start. It will start from 5min...
You can use the JMSXDeliveryCount property of the JMS message to check how many times it has been retried already. The retry time interval logic should rely on the JMSXDeliveryCount variable.
message.getIntProperty("JMSXDeliveryCount ")
http://activemq.apache.org/activemq-message-properties.html
ActiveMQ has a way to do persistent redelivery, but it's not built in using the RedeliveryPolicy on the ConnectionFactory, which is intended for short periods of redelivery before failing.
Persistent redelivery can be built using the the ActiveMQ scheduler and delayed messages however. A bit manual, but doable. Make sure you turn on schedulerSupport="true" in ActiveMQ before trying this.
A JMS property: "delivery" keeps track of number of retries and if things go wrong a catch exception strategy redelivers the message a number of times with a delay. The actual delay is handled by ActiveMQ, so this flow can handle delays of hours, days etc and withstand restarts of both ActiveMQ and Mule.
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting"
xmlns:jms="http://www.mulesoft.org/schema/mule/jms" xmlns:metadata="http://www.mulesoft.org/schema/mule/metadata"
xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd
http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd">
<spring:beans>
<spring:bean name="redeliveryPolicy" class="org.apache.activemq.RedeliveryPolicy">
<spring:property name="maximumRedeliveries" value="0" />
</spring:bean>
<spring:bean name="cf"
class="org.apache.activemq.ActiveMQConnectionFactory">
<spring:property name="brokerURL" value="tcp://localhost:61616" />
<spring:property name="redeliveryPolicy" ref="redeliveryPolicy" />
</spring:bean>
</spring:beans>
<jms:activemq-connector name="Active_MQ"
specification="1.1" brokerURL="tcp://localhost:61616"
validateConnections="true" doc:name="Active MQ" numberOfConsumers="1"
maxRedelivery="-1" connectionFactory-ref="cf" />
<flow name="testFlow">
<jms:inbound-endpoint queue="IN" connector-ref="Active_MQ"
doc:name="JMS">
<jms:transaction action="ALWAYS_BEGIN" />
</jms:inbound-endpoint>
<set-property propertyName="delivery"
value="#[message.inboundProperties['delivery'] or 0]" doc:name="Property" />
<scripting:component doc:name="Throw Error">
<scripting:script engine="Groovy"><![CDATA[throw new java.lang.RuntimeException("Error in processing")]]></scripting:script>
</scripting:component>
<choice-exception-strategy doc:name="Choice Exception Strategy">
<catch-exception-strategy doc:name="Catch Exception Strategy"
when="#[message.outboundProperties['delivery'] < 5]">
<logger level="ERROR"
message="Retry once more count #[message.outboundProperties['delivery']]"
doc:name="Logger" />
<set-property propertyName="AMQ_SCHEDULED_DELAY" value="3000"
doc:name="Property" />
<set-property propertyName="delivery"
value="#[message.outboundProperties['delivery'] + 1]" doc:name="Property" />
<jms:outbound-endpoint queue="IN"
connector-ref="Active_MQ" doc:name="JMS">
<jms:transaction action="ALWAYS_JOIN" />
</jms:outbound-endpoint>
</catch-exception-strategy>
<rollback-exception-strategy doc:name="Rollback Exception Strategy">
<logger level="ERROR" message="Giving up retry. Do whatever needed here." doc:name="Logger" />
</rollback-exception-strategy>
</choice-exception-strategy>
</flow>
</mule>
This is no way to make the RedeliveryPolicy persistent - it's controlled by the connection factory and the factory will get reset when you restart the server. The way you have it configured, it will carry on with the behaviour you see, as you have useExponentialBackOff set to true. You could set this to false to get the delay to be a regular amount, but that is the only change to make.
I think you have the right idea with setting the message TTL, at least this will remove the message after the specified time. The JMSXDeliveryCount is great, but it will remove after a number attempts, not a defined time period, if you increase the delay between the retries.
Related
Is it possible to send messages with SimpMessageSendingOperations from a RabbitMQ listener bean?
I have the following listener class:
public class MyJobListener {
#Autowired
public SimpMessageSendingOperations messagingTemplate;
public void handleJob(JobMessage jobMessage) {
doWork(jobMessage);
messagingTemplate.convertAndSend("/topic/greetings", "TEST");
}
}
My Rabbit config file is:
<!-- RabbitMQ configuration -->
<rabbit:connection-factory id="connectionFactory" host="${rabbitmq.connection.host}" port="${rabbitmq.connection.port}" />
<rabbit:admin connection-factory="connectionFactory" />
<rabbit:template id="amqpTemplate" connection-factory="connectionFactory" />
<!-- Queues -->
<rabbit:queue id="myQueue" name="myQueue" />
<!-- Listeners -->
<bean id="myListener01" class="com.xxx.MyJobListener" />
<bean id="myListener02" class="com.xxx.MyJobListener" />
<bean id="myListener03" class="com.xxx.MyJobListener" />
<bean id="myListener04" class="com.xxx.MyJobListener" />
<rabbit:listener-container connection-factory="connectionFactory" >
<rabbit:listener ref="myListener01" method="handleJob" queue-names="myQueue" />
<rabbit:listener ref="myListener02" method="handleJob" queue-names="myQueue" />
<rabbit:listener ref="myListener03" method="handleJob" queue-names="myQueue" />
<rabbit:listener ref="myListener04" method="handleJob" queue-names="myQueue" />
</rabbit:listener-container>
<!-- Bindings -->
<rabbit:direct-exchange name="directexchange" >
<rabbit:bindings>
<rabbit:binding queue="myQueue"/>
</rabbit:bindings>
</rabbit:direct-exchange>
When message is expected to be sent (messagingTemplate.convertAndSend("/topic/greetings", "TEST")) nothing happens, but if I do the same thing but in a #Controller everything works fine (message is sent through websocket to the browser)
I need to do this to send a notification to the user when the job is finished.
After many tests I changed my rabbit configuration file, leaving only one listener:
<!-- Listeners -->
<bean id="myListener01" class="com.xxx.MyJobListener" />
<rabbit:listener-container connection-factory="connectionFactory" error-handler="queueErrorHandler" >
<rabbit:listener ref="myListener01" method="handleJob" queue-names="myQueue" />
</rabbit:listener-container>
and now it works almost randomly. It's strange, but each 2 calls it works. I mean, two times yes, two times not, two times yes, two times not... and so... It's very strange. I think there is something with the rabbit config...
Definitely is Spring Security configuration. If I disable Spring Security everything works fine. I will find out what it is, and then I'll post the answer here.
I was able to solve it.
The problem was not Spring Security, the problem was I was declarating twice the websocket message broker:
<websocket:message-broker application-destination-prefix="/app" >
<websocket:stomp-endpoint path="/websocket" >
<websocket:sockjs />
</websocket:stomp-endpoint>
<websocket:simple-broker prefix="/topic,/user" />
</websocket:message-broker>
These lines resides in my websocket.xml, and this file was imported more than one time because of an "ugly" import sentences distributions along my .xml spring files.
After ordering these imports and ensuring the bean is only created once everything works fine.
May this helps!
I hava following spring xml configuration
<bean id="connectionFactory"
class="org.springframework.amqp.rabbit.connection.CachingConnectionFactory">
<constructor-arg value="xxxxxxxx"/>
<property name="username" value="xxxxx"/>
<property name="password" value="xxxxx"/>
<property name="channelCacheSize" value="25"/>
<property name="virtualHost" value="/"/>
<property name="port" value="3453"/>
</bean>
<rabbit:template id="tutorialTemplate" connection-factory="connectionFactory"/>
<!-- 1st queue -->
<rabbit:queue id="veliteQueue" name="ES_queue" durable="true" auto-delete="false" exclusive="false"/>
<rabbit:direct-exchange id="myExchange" durable="true" name="ES_exchange">
<rabbit:bindings>
<rabbit:binding queue="veliteQueue" key="logstash"></rabbit:binding>
</rabbit:bindings>
</rabbit:direct-exchange>
<!-- 2nd Queue -->
<rabbit:queue id="veliteQueue1" name="ES_queue_Temp" durable="true" auto-delete="false" exclusive="false"/>
<rabbit:direct-exchange id="myExchange1" durable="true" name="ES_exchange_temp">
<rabbit:bindings>
<rabbit:binding queue="ES_queue_Temp" key="logstash_temp"></rabbit:binding>
</rabbit:bindings>
</rabbit:direct-exchange>
<!-- 2 Listeners for 2 queue's mentioned above -->
<bean id="aListener" class="com.vzw.es.cosumer.SpringMessageListener" autowire="byName"/>
<bean id="aListener1" class="com.vzw.es.cosumer.SpringMessageListener1" autowire="byName"/>
<rabbit:listener-container id="myListenerContainer" connection-factory="connectionFactory" acknowledge="auto" prefetch="750" concurrency="1">
<rabbit:listener ref="aListener" queues="veliteQueue"/>
<rabbit:listener ref="aListener1" queues="veliteQueue1"/>
</rabbit:listener-container>
Now in my Java code I have 2 Listener classes: com.vzw.es.cosumer.SpringMessageListener and com.vzw.es.cosumer.SpringMessageListener1. Now When I am running my main class only 1 listener's onMessage method is getting invoked i.e. SpringMessageListener1, I did check from RabbitMQ prespective and bothe queues have enough messages to consume.
Also when I comment out the 2nd queue and its listener from xml SpringMessageListener works perfectly.
It's a bug in the container parser, each listener gets its own container (the namespace is just a convenient way to specify common attributes). If you remove the id="myListenerContainer", it will work - because each container gets a (different) generated name. With the id specified, both beans get the same name, and the last definition replaces the first.
Alternatively, declare two separate container elements, with different IDs, and each having just one listener.
Thanks for finding this.
Please open a JIRA issue
EDIT: This issue was resolved in version 1.2.1.
Issue: We have 2 or 3 instances of an application. Each instance has a producer and a consumer. We have to schedule some process and for this we use common spring scheduler. This scheduler produces messages and throws them to a "Broker" (RabbitMQ). In our case we process the same data 2 or 3 times because each instance throws the message. How would you block the producer of instances until first producer will throw a message?
Configuration:
<!-- RabbitMQ configuration -->
<rabbit:connection-factory
id="connection" host="${rabbit.host}" port="${rabbit.port}" username="${rabbit.username}" password="${rabbit.password}"
channel-cache-size="${rabbit.publisherCacheSize}" virtual-host="${rabbit.virtualHost}" />
<!-- Declare executor pool for worker threads -->
<!-- Ensure that the pool-size is greater than the sum of all number of concurrent consumers from rabbit that use this pool to ensure
you have enough threads for maximum concurrency. We do this by ensuring that this is 1 plus the size of the connection factory cache
size for all consumers -->
<task:executor id="worker-pool" keep-alive="60" pool-size="${rabbit.consumerChannelCacheSize}" queue-capacity="1000" rejection-policy="CALLER_RUNS"/>
<!-- Message converter -->
<bean id="baseMessageConverter" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="classesToBeBound" value="com.company.model.Scraper"/>
</bean>
<bean id="messageConverter" class="org.springframework.amqp.support.converter.MarshallingMessageConverter">
<constructor-arg index="0" ref="baseMessageConverter"/>
</bean>
<!-- *********************************producer*********************************** -->
<!-- Outbound company Events -->
<int:channel id="producerChannelCompany"/>
<int:gateway id="jobcompanyCompleteEventGateway" service-interface="com.company.eventing.companyEventPublisher"
default-request-channel="producerChannelCompany"
default-request-timeout="2000"
error-channel="errors"/>
<amqp:outbound-channel-adapter id="companyEvents.amqpAdapter" channel="producerChannelCompany"
exchange-name="${rabbit.queue.topic}"
routing-key="${rabbit.queue.routing.key}"
amqp-template="psRabbitTemplate"/>
<rabbit:admin id="psRabbitAdmin" connection-factory="connection" />
<rabbit:template id="psRabbitTemplate" channel-transacted="${rabbit.channelTransacted}" encoding="UTF-8" message-converter="messageConverter" connection-factory="connection"/>
<rabbit:topic-exchange id="ps.topic" name="${rabbit.queue.topic}" durable="true" auto-delete="false"/>
<!-- *********************************consumer*********************************** -->
<rabbit:queue id="ps.queue" name="${rabbit.queue}" auto-delete="false" durable="true" exclusive="false" />
<!-- Exchange to queue binding -->
<rabbit:topic-exchange id="ps.topic" name="${rabbit.queue.topic}" durable="true" auto-delete="false" >
<rabbit:bindings>
<rabbit:binding queue="${rabbit.queue}" pattern="${rabbit.queue.pattern}"></rabbit:binding>
</rabbit:bindings>
</rabbit:topic-exchange>
<!-- Configuration for consuming company Complete events -->
<amqp:inbound-channel-adapter id="companyAdapter"
channel="companyCompleteEventChannel"
queue-names="${rabbit.queue}"
channel-transacted="${rabbit.channelTransacted}"
prefetch-count="${rabbit.prefetchCount}"
concurrent-consumers="${rabbit.concurrentConsumers}"
connection-factory="connection"
message-converter="messageConverter"
task-executor="worker-pool"
error-channel="errors"/>
<int:channel id="companyCompleteEventChannel"/>
<int:service-activator id="companyCompleteActivator" input-channel="companyCompleteEventChannel"
ref="companyEventHandler" method="runScraper"/>
<bean id="jvmLauncher" class="com.app.company.jvm.JvmLauncher" />
<!-- company Event handler -->
<bean id="companyEventHandler" class="com.app.company.eventing.consumer.companyEventHandler" depends-on="jvmLauncher">
<!--<property name="scriptHelper" ref="scriptHelper"/>-->
<property name="jvmLauncher" ref="jvmLauncher" />
<property name="defaultMemoryOptions" value="${company.memory.opts}"/>
<property name="defaultMemoryRegex" value="${company.memory.regex}"/>
</bean>
<!-- ERRORS -->
<int:channel id="errors"/>
<int:service-activator id="psErrorLogger" input-channel="errors" ref="psloggingHandler"/>
<bean id="psloggingHandler" class="org.springframework.integration.handler.LoggingHandler">
<constructor-arg index="0" value="DEBUG"></constructor-arg>
<!-- <property name="loggerName" value="com.app.travelerpayments.loggingHandler"/> -->
</bean>
It's not clear what architecture you have, but if all your instances consume messages from the same queue, each message will be consumed only once (unless requeued by consumer). It the best way to use AMQP power in you situation, I guess. And if I missed something, please clarify your question.
With a-la fanout messages delivery, when each instance has their own queue with own messages stack and you want to controls messages delivery by your own (definitely, it's bad idea in almost all situations), why not let all instances to listen to personal queue(s) bounded to fanout exchange and use this exchange for control messages. You can tell instances when to stop or start consuming, flush their queues, schedule restart, etc.
Note, you can use also topic exchange and bind queues by specific routing key, say "control.*"
The idea is to send who is free request, pick the random free worker and send payload to it. You can use specific routing key or just publish payload to default exchange with routing key same as queue name (by default queues bounded to default exchange with routing key same as queue name, see section Default Exchange in RabbitMQ docs).
I am trying to use spring integration to do a Gateway --> Splitter-->ServiceActivator --> Aggregator Pattern in an event driven fashion backed by JMS . I Expect the service activator to be multi-threaded and any of the end points can be executed on a cluster and not necessarily the originating server . I could get this working in a single JVM without using JMS ( Using SI Channels ) but I understand that SI Channels will not help me scale horizontally i.e multiple VMs .
Here's the configuration I have so far
<int:gateway id="transactionGateway" default-reply-channel="transaction-reply"
default-request-channel="transaction-request" default-reply-timeout="10000"
service-interface="com.test.abc.integration.service.ProcessGateway">
</int:gateway>
<int-jms:outbound-gateway id="transactionJMSGateway"
correlation-key="JMSCorrelationID" request-channel="transaction-request"
request-destination="transactionInputQueue" reply-channel="transaction-reply"
reply-destination="transactionOutputQueue" extract-reply-payload="true"
extract-request-payload="true">
<int-jms:reply-listener
max-concurrent-consumers="20" receive-timeout="5000"
max-messages-per-task="1" />
</int-jms:outbound-gateway>
<!-- Inbound Gateway for Splitter -->
<int-jms:inbound-gateway id="splitterGateWay"
request-destination="transactionInputQueue" request-channel="splitter-input"
reply-channel="splitter-output" concurrent-consumers="1"
default-reply-destination="processInputQueue"
max-concurrent-consumers="1" extract-reply-payload="true"
correlation-key="JMSCorrelationID" extract-request-payload="true" />
<!-- Inbound Gateway Invokes Service Activator and Sends response back to
the channel -->
<int-jms:inbound-gateway id="seriveActivatorGateway"
request-destination="processInputQueue" request-channel="process-input"
reply-channel="process-output" concurrent-consumers="1"
default-reply-destination="processOutputQueue"
max-concurrent-consumers="1" extract-reply-payload="true"
correlation-key="JMSCorrelationID" extract-request-payload="true"
max-messages-per-task="1" />
<int-jms:inbound-gateway id="aggregatorGateway"
request-destination="processOutputQueue" request-channel="aggregator-input"
reply-channel="aggregator-output" concurrent-consumers="1"
default-reply-destination="transactionOutputQueue"
max-concurrent-consumers="1" extract-reply-payload="true"
extract-request-payload="true" max-messages-per-task="1"
correlation-key="JMSCorrelationID" />
<int:splitter id="transactionSplitter" input-channel="splitter-input"
ref="processSplitter" output-channel="splitter-output">
</int:splitter>
<int:service-activator id="jbpmServiceActivator"
input-channel="process-input" ref="jbpmService" requires-reply="true"
output-channel="process-output">
</int:service-activator>
<int:aggregator id="transactionAggregator"
input-channel="aggregator-input" method="aggregate" ref="processAggregator"
output-channel="aggregator-output" message-store="processResultMessageStore"
send-partial-result-on-expiry="false">
</int:aggregator>
Before using gateway I tried using JMS backed Channels and that approach was't successful either . The problem I am facing now is that the Splitter now reply back to the transactionOutputQueue . I tried playing around with jms:header-enricher without much success . I feel that my approach to the problem /SI might have fundamental flaw . Any help /guidance is highly appreciated .
Also , in the code snippet I have provided above use a simple in memory aggregator , I understand that If I need to get this working across the cluster I might need a JDBC backed Aggregator but for the for now , I am trying to get this pattern working on a single VM
Here's the updated working configuration based on Gary's Comment
<bean id="processOutputQueue" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg value="test.com.abc.process.output" />
</bean>
<bean id="transactionOutputQueue" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg value="test.com.abc.transaction.result" />
</bean>
<bean id="transactionInputQueue" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg value="test.com.abc.transaction.input" />
</bean>
<int:gateway id="transactionGateway"
default-request-channel="transaction-request" default-reply-timeout="10000"
default-reply-channel="aggregator-output"
service-interface="com.test.abc.integration.service.ProcessGateway">
</int:gateway>
<int:splitter id="transactionSplitter" input-channel="transaction-request"
ref="processSplitter" output-channel="splitter-output">
</int:splitter>
<int-jms:outbound-gateway id="splitterJMSGateway"
correlation-key="JMSCorrelationID" request-channel="splitter-output"
request-destination="processInputQueue" reply-channel="aggregator-input"
reply-destination="processOutputQueue" extract-request-payload="true"
extract-reply-payload="true">
<int-jms:reply-listener
max-concurrent-consumers="20" receive-timeout="5000" />
</int-jms:outbound-gateway>
<!-- Inbound Gateway Invokes Service Activator and Sends response back to
the channel -->
<int-jms:inbound-gateway id="seriveActivatorGateway"
request-destination="processInputQueue" request-channel="process-input"
reply-channel="process-output" default-reply-destination="processOutputQueue"
concurrent-consumers="5" max-concurrent-consumers="10"
extract-reply-payload="true" correlation-key="JMSCorrelationID"
extract-request-payload="true" max-messages-per-task="1" />
<int:service-activator id="jbpmServiceActivator"
input-channel="process-input" ref="jbpmService" requires-reply="true"
output-channel="process-output">
</int:service-activator>
<int:aggregator id="transactionAggregator"
input-channel="aggregator-input" ref="processAggregator"
output-channel="aggregator-output" message-store="processResultMessageStore"
send-partial-result-on-expiry="false">
</int:aggregator>
<bean id="processResultMessageStore"
class="org.springframework.integration.store.SimpleMessageStore" />
<bean id="processResultMessageStoreReaper"
class="org.springframework.integration.store.MessageGroupStoreReaper">
<property name="messageGroupStore" ref="processResultMessageStore" />
<property name="timeout" value="5000" />
</bean>
<task:scheduled-tasks>
<task:scheduled ref="processResultMessageStoreReaper"
method="run" fixed-rate="1000" />
</task:scheduled-tasks>
<int:logging-channel-adapter id="logger"
level="DEBUG" log-full-message="true" />
<int-stream:stdout-channel-adapter
id="stdoutAdapter" channel="logger" />
I limited the JMS pipeline only to the Service Activator , which is what I originally wanted .
The only question I have based on the above approach is that do I need to have my Aggregator backed by a database even if I use this across multiple VMS ( Since the JMS gateway in front of it make sure that it receives only the messages that have valid correlation ID ?)
Regards ,
You probably don't need to use JMS between every component. However we have lots of test cases for chained gateways like this, and all works fine.
Something must be wired up incorrectly. Since you didn't show your full configuration, it's hard to speculate.
Be sure to use the latest version (2.2.4) and turn on DEBUG logging and follow a message through the flow; as long as your message payload is identifiable across JMS boundaries, it should be easy to figure out where things go awry.
I've got a fast producer ESB (converts CSV to XML) and a slow consumer ESB (performing zip/base64/SOAP wrapping of the XML). The ESBs communicate via a JMS topic. This design is legacy and cannot be changed. When a large CSV file is processed, JBoss AS (5.2) grinds to a halt as the producer is flooding out the consumer, this is even with a heap-size of 4096M. Forgive me I'm new to JBoss/JMS and finding it all bewildering.
Producer sending config
<action class="com.example.FooAction" name="ProcessFoo">
<property name="springJndiLocation" value="FooEsbSpring" />
<property name="exceptionMethod" value="exceptionHandler" />
<property name="okMethod" value="processSuccess" />
<property name="jndiName" value="topic/FooTopic" />
<property name="connection-factory" value="ConnectionFactory" />
<property name="unwrap" value="true" />
<property name="security-principal" value="guest" />
<property name="security-credential" value="guest" />
</action>
Producer sending code:
Message msg = MessageFactory.getInstance().getMessage(MessageType.JAVA_SERIALIZED);
msg.getBody().add(foo); // foo is the business specific message
new JMSRouter(config).process(msg);
Consumer receiving config:
<jms-jca-provider connection-factory="ConnectionFactory" name="FooMessaging">
<jms-bus busid="fooChannel">
<jms-message-filter dest-name="topic/FooTopic"
dest-type="TOPIC" transacted="false" />
</jms-bus>
<activation-config>
<property name="dLQMaxResent" value="1" />
</activation-config>
</jms-jca-provider>
Topic config
<server>
<mbean code="org.jboss.jms.server.destination.TopicService"
name="jboss.esb.quickstart.destination:service=Topic,name=FooTopic"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer
</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
</server>
Things I've tried so far.
Run the publisher ESB without the consumer ESB - as expected no problems.
Lots of googling, looking for existing questions on stackoverflow
Found some references to rate limiting but I can't see how to fit these into my config.
I've tried to find an API to discover how many messages are already on the topic unprocessed (with the hope I can implement my own back-off strategy).
Looked at this documentation.
Look at this section 6.3.17.2. org.jboss.mq.server.jmx.Topic and use the 'Depth' related attributes using JMX.
It might help you build the back-off strategy you're looking for