nau
nau

Reputation: 1165

Spring Integration DSL message driven jms listener uses poller instead

I use the following code to create a int-jms:message-driven-channel-adapter, however, seems it is based on polling, as it return the data in 1 second intervals rather than responding to ticks.

The flow I defined as follows:

jms.listen(requestDestinationName = "myTopic", connectionFactory = connectionFactory).additionalAttributes(requestPubSubDomain = true) --> ...

The question is, how to make it message-driven?

Upvotes: 0

Views: 711

Answers (2)

nau
nau

Reputation: 1165

OK, as a workaround I manually create SubscribableJmsChannel:

lazy val subscribeChannel = {
  val c = new SubscribableJmsChannel(jmsContainer, jmsTemplate)
  c.afterPropertiesSet()
  c.subscribe(new MessageHandler {
    def handleMessage(message: Message[_]) {processMessage(message)}
  })
  c
}

subscribeChannel.start()

where processMessage(message) is my processing function, and

lazy val jmsContainer= {
    val c = new DefaultMessageListenerContainer
    c.setConnectionFactory(connectionFactory)
    c.setDestination(dest)
    c.setPubSubDomain(true)
    c.afterPropertiesSet()
    c
 }

Please, be aware that SubscribableJmsChannel doesn't map JMS properties to SI Message headers! I had to fallback to using Spring Integration XML flow definitions.

Upvotes: 1

Biju Kunjummen
Biju Kunjummen

Reputation: 49935

I checked the underlying implementation in scala dsl and found that it defaults to creating a jms:inbound-gateway(not a message-driven-channel-adapter), which internally uses a DefaultMessageListenerContainer. So yes, it is a message driven container internally but because it seems to be using a gateway component, it has a request/reply type of flow, this could be what you are seeing as a 1 second delay, instead of the polling.

Upvotes: 1

Related Questions