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+Co
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 Thur
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 dup
On Thu, Nov 9, 2017 at 5:06 AM, Timothy Steffens 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
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
Tim,
I am not sure why we need to change the JMS streamer. Why not just create a
separate JMS streamer per cache? In my view, it is more intuitive to keep
one-to-one relationship between JMS streamer and the data streamer.
D.
On Wed, Nov 8, 2017 at 9:40 AM, Timothy Steffens <
timothy.steff...@ya
