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.steff...@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.kuliche...@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 <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. > > >
