[
https://issues.apache.org/jira/browse/IGNITE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695039#comment-14695039
]
Raúl Kripalani edited comment on IGNITE-534 at 8/13/15 10:38 AM:
-----------------------------------------------------------------
bq. I'm not sure why we need setBatched() configuration property. In my
understanding, we can just have default batch size of 1 which automatically
means disabled batching. If user sets to any value greater than 1, batching is
enabled. BTW, we have pretty similar configuration API in ContinuousQuery, you
can take a look to see what I mean.
I see what you mean, but this will confuse users. batchSize = 1 is not the same
as not using batching. Batching automatically enables JMS Sessions. So batching
= 1 is ambiguous because the user may actually want to enable batching (w/
transactions) and with batch size = 1.
By using your approach, we would have wrongly assumed that with batchSize == 1
the user wanted to disable batching altogether, which was not the user's
intention in the above scenario.
I don't think this change proceeds.
bq. The same goes for setTransacted(). It looks like it's always enabled
together with batching. And if I understand correctly, if there is no batching,
setting transacted to true does not change anything. This makes me feel that
there is no reason for two separate properties. Correct me if I'm wrong.
See this {{else if}} where transactions are used outside the context of
batching:
https://github.com/apache/incubator-ignite/pull/14/files#diff-4da92378206ff13d146e2c8709438c84R496.
was (Author: raulvk):
bq. I'm not sure why we need setBatched() configuration property. In my
understanding, we can just have default batch size of 1 which automatically
means disabled batching. If user sets to any value greater than 1, batching is
enabled. BTW, we have pretty similar configuration API in ContinuousQuery, you
can take a look to see what I mean.
I see what you mean, but this will confuse users. Batching = 1 is not the same
as not using batching. Batching automatically enables JMS Sessions. So batching
= 1 is ambiguous because the user may want to enable batching (w/ transactions)
and with batch size = 1.
I don't think this change proceeds.
bq. The same goes for setTransacted(). It looks like it's always enabled
together with batching. And if I understand correctly, if there is no batching,
setting transacted to true does not change anything. This makes me feel that
there is no reason for two separate properties. Correct me if I'm wrong.
See this {{else if}} where transactions are used outside the context of
batching:
https://github.com/apache/incubator-ignite/pull/14/files#diff-4da92378206ff13d146e2c8709438c84R496.
> Implement IgniteJmsStreamer to stream data from a JMS broker like ActiveMQ
> --------------------------------------------------------------------------
>
> Key: IGNITE-534
> URL: https://issues.apache.org/jira/browse/IGNITE-534
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
> Reporter: Dmitriy Setrakyan
> Assignee: Valentin Kulichenko
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> We should create {{IgniteJmsStreamer}} which will consume messages from a
> given queue or topic of a JMS broker and stream them into Ignite caches.
> Even though we'll use AMQ for testing, this streamer should be
> implementation-agnostic and only use JMS constructs where possible.
> See [Apache ActiveMQ|http://activemq.apache.org/] for more information.
> More details to follow, but to the least we should be able to:
> * Convert a JMS message to Ignite data using an optional pluggable converter.
> If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
