ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: JMSStreamer enhancement -- needs to support multiple IgniteDataStreamers.
Date Fri, 10 Nov 2017 00:10:24 GMT

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

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.



On Wed, Nov 8, 2017 at 1:31 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>

> On Thu, Nov 9, 2017 at 5:06 AM, Timothy Steffens <
> timothy.steffens@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message