CODEWITHSUNDEEP
spring-integration
IndianaJonas
IndianaJonas

Reputation: 23

Jdbc based Queue Channel without poller. Possible?

I have a scenario where I would like to separate the flow into a number of transactions. I am using queue channels based on a JdbcChannelMessageStore to do so and that works excellent. Its robust and it just works. But because these Jdbc based queues (the database) are polled by the executors, I get a natural limitation on the throughput (I don't really want to configure the poller to poll every 1 millisecond). So my question is this, is there a way for the queue channel to notify the consumer of that channel that a new messages has been queued, and then trigger the "poller" to have a look in the database to see what has to be consumed?

So the simple scenario: 1. A queue channel where someone puts a message 2. A service activator that will process that message (in parallel)

<int:channel id="InputChannel">
   <int:queue message-store="jdbcChannelStore"/>
</int:channel>

<task:executor id="TradeTransformerExecutor" pool-size="2-20" queue-capacity="20" rejection-policy="CALLER_RUNS"/>

<int:service-activator id="TradeConverter" input-channel="InputChannel" output-channel="TradeChannel" method="transform">
   <beans:bean class="com.service.TradeConverter"/>
   <int:poller task-executor="TradeTransformerExecutor" max-messages-per-poll="-1" receive-timeout="0" fixed-rate="100">
      <int:transactional transaction-manager="dbTransactionManager"/>
   </int:poller>
    </int:service-activator>

<int:channel id="TradeChannel"></int:channel>

So how could I make this InputChannel notify the poller (or something else) to start executing the message right away and not wait for 100ms? Also I don't want to use DirectChannels as I do want some persistence between defined flows for robustness reasons.

Cheers guys.

Jonas

Upvotes: 1

Views: 861

Answers (1)

Gary Russell
Gary Russell

Reputation: 174544

There's no way to change a trigger on demand; you can have a dynamic trigger, but changes only take effect after the next poll.

Instead of using a JDBC-backed channel, consider using an outbound channel adapter to store the data and a JDBC outbound gateway (with just a query, no update).

Use a pub-sub channel and, after storing, send the message (perhaps via a bridged ExecutorChannel) to the gateway.

Alternatively, simply inject your queue channel into a service and invoke it via a <service-activator/>. You would need a pub-sub channel bridged to your queue channel, with the second subscriber being the service activator which, when it receives the message calls receive() on the channel.

Finally, consider using a JMS, or RabbitMQ backed-channel for high performance persistence instead - they are much better a queueing than a database.

Upvotes: 1

Related Questions