ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raúl Kripalani (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-534) Implement IgniteJmsStreamer to stream data from a JMS broker like ActiveMQ
Date Thu, 13 Aug 2015 10:38:45 GMT

    [ 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)

Mime
View raw message