Announcement Announcement Module
Collapse
No announcement yet.
maxMessagesPerPoll, taskExecutor and TRansaction demarcation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • maxMessagesPerPoll, taskExecutor and TRansaction demarcation

    Hi the spec says:

    The 'maxMessagesPerPoll' property specifies the maximum number of messages to receive within a given poll operation. This means that the poller will continue calling receive() without waiting until either null is returned or that max is reached. For example, if a poller has a 10 second interval trigger and a 'maxMessagesPerPoll' setting of 25, and it is polling a channel that has 100 messages in its queue, all 100 messages can be retrieved within 40 seconds. It grabs 25, waits 10 seconds, grabs the next 25, and so on.
    Whats not clear to me from this is if the multiple messages received during a single poll are processed within a single transaction, in what order and if using a taskExecutor does each message get its own thread?

    Regards

    Tim

  • #2
    No; the order in which they are retrieved; no.

    Think of a specific poll as being a scheduled task (which is what it is). When the trigger fires, the task starts. If there's a declared task executor, the task is handed off to a thread from that executor, otherwise the default SyncTaskExecutor is used (the task runs on the scheduler's thread). The task loops for up to max-messages-per-poll; within each iteration of the loop, the transaction (if any) starts, the next message is retrieved and processed. When the loop exits (maybe early) it will run again on the next trigger.

    The specific code to look at is in AbstractPollingEndpoint.Poller.

    Comment

    Working...
    X