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 04:42:08 GMT
Tim,

If you want to do this change by yourself, then create a ticket in Jira,
assign to yourself and prepare a pull request.

See here for more information about the process:
https://ignite.apache.org/community/contribute.html#contribute
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

-Val

On Thu, Nov 9, 2017 at 8:34 PM Timothy Steffens <timothy.steffens@yahoo.com>
wrote:

> Yes, this makes sense. The proposed changes will improve the overall
> implementation of the JMSStreamer and the changes will also allow for me to
> then extend the streamer and implement my own custom functionality as
> needed.
>
> What are the next steps to getting this change implemented?
>
>
>
> On Thursday, November 9, 2017, 6:11:01 PM CST, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
>
> 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 <dsetrakyan@apache.org>
> wrote:
>
> > 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.
> >
>

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