Tim, I think you properly defined flaws in the JmsStreamer and it defintely makes sense to do the following:
- Deprecate org.apache.ignite.stream.jms11.MessageTransformer in favor of extractors defined in StreamAdapter. This JMS specific transformer doesn't provide any value and only duplicates generic extractors making it very confusing. - Remove JmsStreamer#processMessage method and use StreamAdapter#addMessage. This will make both API and implementation cleaner and more in line with overall streamers design. And the best thing: there is no need to add special support for multiple streamers anymore. If one has one queue/many caches use case, they can simply extend JmsStreamer and override addMessage method (which is protected). This way the behavior can be modified in any desired way, while reusing most of JmsStreamer code. Thoughts? -Val On Wed, Nov 8, 2017 at 1:31 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > On Thu, Nov 9, 2017 at 5:06 AM, Timothy Steffens < > timothy.steff...@yahoo.com > > wrote: > > > Can the JMSStreamer be configured to inspect the message prior to picking > > it off of the queue? If so, then I can use multiple JMSStreamers as you > > suggest. If not, then I cannot since each JMSStreamer will not know if > the > > next message is for them or for another to process. I do not want to have > > multiple queues (one queue per table - which would equate to one > > JMSStreamer per queue) due to ongoing maintenance concerns. > > > > To be honest, queue-per-table seems like the most appropriate solution > here. I do not think inspecting messages before they get picked off the > queue will perform well. > > If queue-per-table is not possible, then my suggestion would be not to use > JMS Streamer at all, and implement your own logic for reading JMS messages > and passing them off to the appropriate data streamer. > > D. >
