diff --git a/src/docbkx/bridge.xml b/src/docbkx/bridge.xml index b8018cb32d..a8a2d5778c 100644 --- a/src/docbkx/bridge.xml +++ b/src/docbkx/bridge.xml @@ -37,9 +37,7 @@ PollableChannel to a SubscribableChannel, and when performing this role, the Messaging Bridge may also serve as a throttler: - - - + ]]> diff --git a/src/docbkx/channel-adapter.xml b/src/docbkx/channel-adapter.xml index 6b6d15c51e..c14d6db69f 100644 --- a/src/docbkx/channel-adapter.xml +++ b/src/docbkx/channel-adapter.xml @@ -22,15 +22,11 @@ provide a 'poller' element with either an 'interval-trigger' (in milliseconds) or 'cron-trigger' sub-element. - - - + - - - + ]]> @@ -49,9 +45,8 @@ ]]> If the channel being adapted is a PollableChannel, provide a poller sub-element: - ]]> - - ]]> +]]> ]]> diff --git a/src/docbkx/endpoint.xml b/src/docbkx/endpoint.xml index bb99aa8944..9974574a4c 100644 --- a/src/docbkx/endpoint.xml +++ b/src/docbkx/endpoint.xml @@ -166,32 +166,33 @@ consumer.setTransactionManager(txManager); EventDrivenConsumer depending on the type of the "input-channel" that is referenced: PollableChannel or SubscribableChannel respectively. When the channel is pollable, then the polling behavior is determined based on the endpoint - element's "poller" sub-element. For example, a simple interval-based poller with a 1-second interval would be + element's "poller" sub-element and its attributes. For example, a simple interval-based poller with a 1-second interval would be configured like this: - - - + ]]> - For a poller based on a Cron expression, use the "cron-trigger" child element instead: + As an alternative to 'fixed-rate' you cna also use 'fixed-delay' attribute. + + + For a poller based on a Cron expression, use the "cron" attribute instead: - - - + ]]> If the input channel is a PollableChannel, then the poller configuration is required. Specifically, as mentioned above, the 'trigger' is a required property of the PollingConsumer class. Therefore, if you omit the "poller" sub-element for a Polling Consumer endpoint's configuration, an Exception - may be thrown. However, it is also possible to create top-level pollers in which case only a "ref" is required: - - - - + may be thrown. The exception will also be thrown if you attempt to configure a poller on the element that is + connected to a non-pollable channel. + + + It is also possible to create top-level pollers in which case only a "ref" is required: + + @@ -201,10 +202,8 @@ consumer.setTransactionManager(txManager); an ApplicationContext may have the default attribute with a value of "true". In that case, any endpoint with a PollableChannel for its input-channel that is defined within the same ApplicationContext and has no explicitly configured 'poller' sub-element will use that default. - - - - + + operation can be performed as an atomic unit-of-work. To configure transactions for a poller, simply add the <transactional/> sub-element. The attributes for this element should be familiar to anyone who has experience with Spring's Transaction management: - - + ]]> + + + + AOP Advice chains + + + Since Spring transaction support depends on the Proxy mechanism  with TransactionInterceptor (AOP Advice) handling transactional + behavior of the message flow initiated by the poler, some times there is a need to provide extra Advice(s) to handle other + cross cutting behavior associated with the poller. For that poller defines an 'advice-chain' element allowing you to add + more advices - class that  implements MethodInterceptor interface..  + + + + + + + + +]]> +For more information on how to implement MethodInterceptor please refer to AOP sections of Spring +reference manual (section 7 and 8). Advice chain can also be applied on the poller that does not have +any transaction configuration essentially allowing you to enhance the behavior of the message flow initiated by the poller. The polling threads may be executed by any instance of Spring's TaskExecutor @@ -234,10 +255,8 @@ consumer.setTransactionManager(txManager); (the other major factor being the expected volume on the channel to which the endpoint subscribes). To enable concurrency for a polling endpoint that is configured with the XML namespace support, provide the 'task-executor' reference on its <poller/> element and then provide one or more of the properties shown below: - - - - + + instantaneously. - - - + + ]]> Using this approach does not carry much overhead since internally it is nothing more then a timed-wait thread which does not require nearly as much CPU resource usage as a thrashing, infinite while loop for example. -
diff --git a/src/docbkx/event.xml b/src/docbkx/event.xml index 15adad2870..b4533387f3 100644 --- a/src/docbkx/event.xml +++ b/src/docbkx/event.xml @@ -51,9 +51,7 @@ If you are using PollableChannel (e.g., Queue), you can also provide p - - - + ]]> diff --git a/src/docbkx/jdbc.xml b/src/docbkx/jdbc.xml index 9ee85725a1..a34d208830 100644 --- a/src/docbkx/jdbc.xml +++ b/src/docbkx/jdbc.xml @@ -60,8 +60,7 @@ <jdbc:inbound-channel-adapter query="..." channel="target" data-source="dataSource" update="..."> - <poller> - <interval-trigger interval="1000"/> + <poller fixed-rate"1000"> <transactional/> </poller> </jdbc:inbound-channel-adapter> diff --git a/src/docbkx/jms.xml b/src/docbkx/jms.xml index 2dc3142b42..6e8be44650 100644 --- a/src/docbkx/jms.xml +++ b/src/docbkx/jms.xml @@ -28,9 +28,7 @@ (a 'destinationName' can be provided in place of the 'destination' reference). The following example defines an inbound Channel Adapter with a Destination reference. - - - + ]]> Notice from the configuration that the inbound-channel-adapter is a Polling Consumer. That means that @@ -56,9 +54,7 @@ destination="inQueue" channel="exampleChannel" extract-payload="false"/> - - - + ]]>
diff --git a/src/docbkx/jmx.xml b/src/docbkx/jmx.xml index bbb8e934c0..e96cb57809 100644 --- a/src/docbkx/jmx.xml +++ b/src/docbkx/jmx.xml @@ -89,9 +89,7 @@ channel="channel" object-name="example.domain:name=someService" attribute-name="InvocationCount"> - <si:poller max-messages-per-poll="1"> - <si:interval-trigger interval="5000"/> - </si:poller> + <si:poller max-messages-per-poll="1" fixed-rate="5000"/> </jmx:attribute-polling-channel-adapter> diff --git a/src/docbkx/mail.xml b/src/docbkx/mail.xml index 27f9ea08e6..1701c8754b 100644 --- a/src/docbkx/mail.xml +++ b/src/docbkx/mail.xml @@ -99,9 +99,7 @@ should-delete-messages="true" should-mark-messages-as-read="true" auto-startup="true"> - - - + ]]> If you do have IMAP idle support, then you may want to configure the "imap-idle-channel-adapter" element instead. Since the "idle" command enables event-driven notifications, no poller is necessary for this adapter. It will diff --git a/src/docbkx/samples.xml b/src/docbkx/samples.xml index 772a3a1ab7..0e2a83a6fe 100644 --- a/src/docbkx/samples.xml +++ b/src/docbkx/samples.xml @@ -93,9 +93,7 @@ - - - + ]]> As you can see, each Message Endpoint is connected to input and/or output channels. Each endpoint will manage @@ -221,9 +219,8 @@ ref="barista" method="prepareHotDrink" output-channel="preparedDrinks"> - ]]> - - ]]> + ]]> ]]>]]> diff --git a/src/docbkx/xml.xml b/src/docbkx/xml.xml index b6c0cbeb14..d260ae908e 100644 --- a/src/docbkx/xml.xml +++ b/src/docbkx/xml.xml @@ -140,9 +140,7 @@ input-channel="input" output-channel="output" unmarshaller="unmarshaller"> - - - + ]]> @@ -386,9 +384,7 @@ output-channel="orderItemsChannel" create-documents="true"> - - - + ]]> @@ -403,9 +399,7 @@ - - - + ]]> diff --git a/src/docbkx/xmpp.xml b/src/docbkx/xmpp.xml index a3f6f3814b..7ee1f384a0 100644 --- a/src/docbkx/xmpp.xml +++ b/src/docbkx/xmpp.xml @@ -276,10 +276,7 @@ public class XmppMessageConsumer { class="com.myxmppproducer.outbound.XmppMessageProducer" p:recipient="${user.2.login}"/> - - - +