How do i get multiple pollers of same type to route messages to a single transformer .I don't mind having the messages queued before the transformer
Well, I think you just want to reuse a message flow for all your <int-mail:imap-idle-channel-adapter>s. It's just enough to configure them all to the same channel.
Actually there is no difference with classical OOP design, when you inject the same service to different actions, like MVC controller, or JMS listeners.
But here we do exactly the same, but inject a MessageChannel to send results of those entry point to it and don't think what's going on underneath.
Please, read more books about Enterprise Integration Patterns
Related
When developing inbound channel adapters, I couldn’t find any place that mentions the differences between AbstractMessageSource and MessageProducerSupport in Spring Integration. I’m asking this question in the context of reactive streams, so I’m actually looking at AbstractReactiveMessageSource, but I guess it doesn’t matter for my question. I also wonder whether MessageProducerSupport supports project reactor and doesn’t have an equivalent to AbstractReactiveMessageSource.
There is some documentation about these types of components: https://docs.spring.io/spring-integration/docs/current/reference/html/overview.html#finding-class-names-for-java-and-dsl-configuration
The inbound message flow side has its own components, which are divided into polling and listening behaviors.
So, the MessageProducerSupport is for those protocols which provide a listening callback for us. So, we can hook up into that, build message and produce it into a channel provided by the MessageProducer. So, it is self-eventing component which really has everything to listen to the source system and produce messages from the callback. This type of channel adapters called event-driven and samples of them are JMS, AMQP, HTTP, IMAP, Kinesis etc.
From here it is wrong to try to compare the MessageProducerSupport with an AbstractMessageSource because the are not relevant. The one you should look into is a SourcePollingChannelAdapter. Exactly this one is that kind of flow beginning endpoint which is similar to MessageProducerSupport. With only the problem that it is based on a periodic scheduled task to request for messages in the provided MessageSource. This type of component is for those protocols which don't provide listening callback, e.g. local file system, (S)FTP, JDBC, MongoDb, POP3, S3 etc.
You probable would expect something similar to MessageSource for the MessageProducer level, but there is not that kind of layer because everything single event-driven protocol has its own specifics, therefore we cannot extract some common abstraction like in case of polling protocols.
If your source system provides for you a reactive Publisher, you don't need to look into a SourcePollingChannelAdapter and MessageSource. You just need a MessageProducerSupport and call its subscribeToPublisher(Publisher<? extends Message<?>> publisher) from the start() implementation.
There is no need in the reactive implementation for the polling since Publisher is not pollable by itself it is event-driven. Although it has its own back-pressure specifics which is out of MessageProducerSupport scope.
There is also some explanation in this section of the doc: https://docs.spring.io/spring-integration/docs/current/reference/html/reactive-streams.html#source-polling-channel-adapter. And see a couple next paragraphs.
I am trying to get multiple listeners configured on same queue, but with different message selector. I am using Solace JMS provider.
The behavior is that the first loaded listener will have its selector registered and is receiving the messages.
the second listener is NOT receiving the message. And using Spring integration DSL 1.1.3
what could be wrong?
I tried with two different Queue connection factory, but could not get it working.
How can we have two Selective consumers configured ?
I think you should start from your vendor first of all and try to figure out if it supports concurrent selective consumers.
Although you have to bear in mind that with the Queue only one consumer accepts message anyway. So, if first one is able to process the message, the second one won't receive it, even with different selector.
Consider to switch to the Topic.
I' m currently investigation the implementation of queue's or topic, based on activeMQ within our project. The setup is pretty straight forward in which we are using maven modules to seprate business logic according to the business domain. One common module allows us to assemble common logic.
simplified Example:
common module
products module
clients module
One of the requirements is that certain operations are asynchronous towards a backend (by means of a activeMQ) which in turn responds with a result message.
The second requirement is that it should be possible to horizontally scale the application by creating a new deployable artifact with only that module that needs more juice.
We are using spring 4 with of course jms and activeMQ.
On to my question. We would like to use just one queue or topic for backend connectivity. Which would mean our common module would handle jms configuration (jms factory, jms-configuration) and different types of messages will be send over that one queue/topic.
How would can I make sure that product related messages get handled by the "products" module and client related messages get handled by the "clients" module? How can I make sure only one of the "products" modules logic would handle a message if the module was deployed two times? What approach would you recommend or is this one queue/topic "nuts"?
I was myself thinking in the direction of using a topic because of the publ/subsc pattern... , or maybe queue listener acting as publisher in a observer pattern to which product- or client subscribers might subscribe to take over handling the message?
Thanks for your help.
Why using a Topic if you want just one of the "products" modules to handle one message? With Topic you'd have one message - multiple subscribers each getting the message. The Queue ensures only one consumer gets a message (point-to-point), with Topic you'd have one message dispatched to all subscribers.
Regarding the "filtering" of messages, this should be something provider specific. Looking at ActiveMQ docs I see this. So, basically each consumer should get the messages the broker, based on selector, will dispatch. I don't know the specifics, but this would be the first place I would start this investigation.
On the same idea, have a look at this discussion from the Spring forum. It is, indeed, related to Spring Integration, but it's on the same idea of message selection. On the other hand, you could consider adopting Spring Integration in your project: it's kind of an abstraction of integration patterns and fits well with everything message oriented.
Few interesting ideas from that forum post:
JmsTemplate from Spring contains a doReceive method that takes as a parameter a String as message selector
Message selectors are in the JMS spec (scroll down to "Message Properties" section)
Relevant section in the Spring Integration documentation is here
I need a messaging or event framework in my Spring project.
Basic requirements:
Single producer/sender, which will create the messages/events
Global channel/queue/etc where the producer will send messages into
Multiple components should be able to register within this channel/queue, so they can receive the messages/events
All components should be able to receive all messages - every message would be visible to all receivers, NOT just to one (first one for example). So single consumer cannot make a message to disappear and be not visible to others
Messages should be distributed across all consumers asynchronous way, so all of them can receive messages at the same time, not just each after other
What would the best fit for my needs?
I think your requirements meet the features of Spring Integration.
http://www.springsource.org/spring-integration
Spring has native support for Observer pattern (Look at Events section). Check if it meets your needs. If it doesn't then you can use Spring's JMS support + ActiveMQ.
Guava EventBus could work for you. It allows publish-subscribe-style communication between components without the need for them to explicitly know of each other. Here's a nice article explaining it further with some examples.
Can anybody point out a reference on how to implement
a single consumer multiple producer in activemq? Or could give a very simple implementation.
This will be very helpful.
Thanks
Matt Raible's AppFuse project is a good skeleton project which is implemented using different libraries. You can pick the one which uses Spring and introduce ActiveMQ as Bharati Raja has explained in his blog post jms with appfuse1x.
There is no special implementation required for this. This is the core business of MessageBrokers. The only thing you need to make sure of:
If you decide to give an ID to your producers, make sure they are different from each other.. You cannot have multiple producers with the same ID. Same goes for consumers.
If you need to guarantee that a message can be consumed by only one consumer, then this is the point-to-point communication model which can be implemented using a JMS Queue in ActiveMQ.
Many producers can send messages to the same queue. Only one active consumer will receive a message from the queue.