Spring Integration: How to increase processing of incoming messages - spring-integration

Question

I am working on a Spring application which will receive around 500 xml messages per minute. The xml configuration below only allows to process around 60 messages per minute, rest of the messages are stored in the queue (persisted in DB) and they are retrieved at the rate of 60 messages per minute.
Tried reading documentation from multiple sources but still not clear on the role of Poller combined with task executor. My understanding of why 60 messages per minute are processed currently is because the "fixed-delay" value in the poller configuration is set to 10 (so it will poll 6 times in 1 minute) and the "max-messages-per-poll" is set to 10 so 6x10=60 messages are being processed per minute.
Please advise if my understanding is not correct and help to modify the xml configuration to achieve processing of incoming messages at a higher rate.
The role of task executor is unclear too - does it mean that pool-size="50" will allow 50 threads to run in parallel to process the messages polled by the poller?
What I want in entirety is:
JdbcChannelMessageStore is used to store the incoming xml messages in the database (INT_CHANNEL_MESSAGE) table. This is required so in case of server restart messages are still stored in the table and not lost.
Incoming messages to be executed in parallel but in a controlled/limited amount. Based on the capacity of system processing these messages, I would like to limit how many messages system should process in parallel.
As this configuration will be used on multiple servers in a cluster, any server can pickup any message so it should not cause any conflict of same message being processed by two servers. Hopefully that is handled by Spring Integration.
Apologies if this has been answered elsewhere but after reading numerous posts I still don't understand how this works.
Thanks in advance.
<!-- Message Store configuration start -->
<!-- JDBC message store configuration -->
<bean id="store" class="org.springframework.integration.jdbc.store.JdbcChannelMessageStore">
<property name="dataSource" ref="dataSource"/>
<property name="channelMessageStoreQueryProvider" ref="queryProvider"/>
<property name="region" value="TX_TIMEOUT"/>
<property name="usingIdCache" value="true"/>
</bean>
<bean id="queryProvider" class="org.springframework.integration.jdbc.store.channel.MySqlChannelMessageStoreQueryProvider" />
<int:transaction-synchronization-factory
id="syncFactory">
<int:after-commit expression="#store.removeFromIdCache(headers.id.toString())" />
<int:after-rollback expression="#store.removeFromIdCache(headers.id.toString())" />
</int:transaction-synchronization-factory>
<task:executor id="pool" pool-size="50" queue-capacity="100" rejection-policy="CALLER_RUNS" />
<int:poller id="messageStorePoller" fixed-delay="10"
receive-timeout="500" max-messages-per-poll="10" task-executor="pool"
default="true" time-unit="SECONDS">
<int:transactional propagation="REQUIRED"
synchronization-factory="syncFactory" isolation="READ_COMMITTED"
transaction-manager="transactionManager" />
</int:poller>
<bean id="transactionManager"
class="org.springframework.batch.support.transaction.ResourcelessTransactionManager" />
<!-- 1) Store the message in persistent message store -->
<int:channel id="incomingXmlProcessingChannel">
<int:queue message-store= "store" />
</int:channel>
<!-- 2) Check in, Enrich the headers, Check out -->
<!-- (This is the entry point for WebService requests) -->
<int:chain input-channel="incomingXmlProcessingChannel" output-channel="incomingXmlSplitterChannel">
<int:claim-check-in message-store="simpleMessageStore" />
<int:header-enricher >
<int:header name="CLAIM_CHECK_ID" expression="payload"/>
<int:header name="MESSAGE_ID" expression="headers.id" />
<int:header name="IMPORT_ID" value="XML_IMPORT"/>
</int:header-enricher>
<int:claim-check-out message-store="simpleMessageStore" />
</int:chain>
Added after response from Artem:
Thanks Artem. So, on every poll which happens after a fixed delay of 10 seconds (as per the config above), the task executor will check the task queue and if possible (and required) start a new task? And each pollingTask (thread) will receive "10" messages, as per the "maxMessagesPerPoll" config, from the message store (queue).
In order to achieve higher processing time of incoming messages, should I reduce the fixedDelay on poller so that more threads can be started by the task executor? If I set the fixedDelay to 2 seconds, a new thread will be started to execute 10messages and roughly 30 such threads will be started in a minute, processing "roughly" 300 incoming messages in a minute.
Sorry for asking too much in one question - just wanted to explain the complete problem.

Answer 1

The main logic is behind this class:
private final class Poller implements Runnable {
private final Callable<Boolean> pollingTask;
Poller(Callable<Boolean> pollingTask) {
this.pollingTask = pollingTask;
}
#Override
public void run() {
AbstractPollingEndpoint.this.taskExecutor.execute(() -> {
int count = 0;
while (AbstractPollingEndpoint.this.initialized
&& (AbstractPollingEndpoint.this.maxMessagesPerPoll <= 0
|| count < AbstractPollingEndpoint.this.maxMessagesPerPoll)) {
try {
if (!Poller.this.pollingTask.call()) {
break;
}
count++;
}
catch (Exception e) {
if (e instanceof MessagingException) {
throw (MessagingException) e;
}
else {
Message<?> failedMessage = null;
if (AbstractPollingEndpoint.this.transactionSynchronizationFactory != null) {
Object resource = TransactionSynchronizationManager.getResource(getResourceToBind());
if (resource instanceof IntegrationResourceHolder) {
failedMessage = ((IntegrationResourceHolder) resource).getMessage();
}
}
throw new MessagingException(failedMessage, e);
}
}
finally {
if (AbstractPollingEndpoint.this.transactionSynchronizationFactory != null) {
Object resource = getResourceToBind();
if (TransactionSynchronizationManager.hasResource(resource)) {
TransactionSynchronizationManager.unbindResource(resource);
}
}
}
}
});
}
}
As you see the taskExecutor is responsible to spin the pollingTask until the maxMessagesPerPoll in one thread. The other threads from the pool are going to be involved if the current polling task is too long for a new schedule. But all the messages in one poll are processed in the same thread, not in parallel .
That is how it works. Since you are asking too much in one SO question, I hope this information is enough to figure out next your steps.