1.0 M5 and DispatcherPolicy

[bman]

Hello,

Is there an equivalent to the M4 method of configuring maxMessagesPerTask for a channel or handler? I used to be able to configure a channel using a DispatcherPolicy like this:

<bean id="testChannel" class="org.springframework.integration.channel.Que ueChannel">
<constructor-arg ref="testChannelInMemQueue"/>
<!-- Use a custom dispatcher policy -->
<constructor-arg>
<bean class="org.springframework.integration.channel.Dis patcherPolicy"
p:maxMessagesPerTask="100"
p:rejectionLimit="1000"
p:retryInterval="500"/>
</constructor-arg>
</bean>

Thanks,

-Brian

[bman]

Any ideas how to configure maxMessagesPerTask in 1.0M5?

It seems that it is now encapsulated in EndpointTrigger (subclass of PollingDispatcher) which defaults to maxMessagesPerTask=1. I can't figure out a way to configure this without resorting to code somehow *after* the MessageEndpoint is completely registered with the MessageBus. The EndpointTrigger instance is created during channel registration in DefaultMessageBus.activateEndpoint.

I need this feature for getting better throughput with high message rates without using lots of threads - any ideas would be appreciated.

Thanks,

Brian

[Mark Fisher]

Brian,

If you don't mind, could you submit an issue in JIRA for this? The intention is to provide that configuration option on the <poller/> sub-element of a service-activator or channel-adapter.

I am also considering switching the default to UNLMITED - meaning that the poller will continue to invoke receive() until it returns null, then stop until the next trigger.

Regards,
Mark

[bman]

Thanks Mark - will do.

-Brian

[Mark Fisher]

Thanks Brian.

I also meant to point out the motivation for this change. The association of a 'dispatcherPolicy' with the channel seemed rather backwards; i.e. the 'maxMessages' property seems more appropriate as a configuration option for the poller.

Also, the way polling works now, the receiver tasks can be scheduled in thread pools such that throughput is now driven by the consumers rather than the sender facing rejected exceptions because all consumers are busy. This also seems to be a better implementation of "competing consumers". The default rejection policy is now "CallerRuns" as well so that when the thread pool is maxed-out, it throttles back against the trigger thread (to prevent excessive trigger rejection).

Hope that explanation makes sense.

-Mark

[bman]

Mark,

It makes perfect sense - in fact when I first started looking at this project, I was pretty confused when I first started looking at the dispatcher configuration and its association with the channel.

Thanks for the explanation and quick responses.

-Brian