[
https://issues.apache.org/jira/browse/APEXMALHAR-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279172#comment-15279172
]
ASF GitHub Bot commented on APEXMALHAR-1988:
--------------------------------------------
Github user chandnisingh commented on a diff in the pull request:
https://github.com/apache/incubator-apex-malhar/pull/186#discussion_r62769280
--- Diff:
contrib/src/main/java/com/datatorrent/contrib/cassandra/AbstractCassandraInputOperator.java
---
@@ -45,7 +47,8 @@
public abstract class AbstractCassandraInputOperator<T> extends
AbstractStoreInputOperator<T, CassandraStore> {
private static final Logger logger =
LoggerFactory.getLogger(AbstractCassandraInputOperator.class);
-
+ private PagingState nextPageState;
+ private int fetchSize;
int waitForDataTimeout = 100;
@AutoMetric
protected long tuplesRead;
--- End diff --
@DT-Priyanka
If tuples count is not right, isn't that the problem with all the
operators?
In that case why did we decide to add this user metric to just this
operator?
I asked this question because I want to understand what was use case which
made it necessary to add this metric just to cassandra input operator.
> CassandraInputOperator fetches less number of records inconsistenly
> -------------------------------------------------------------------
>
> Key: APEXMALHAR-1988
> URL: https://issues.apache.org/jira/browse/APEXMALHAR-1988
> Project: Apache Apex Malhar
> Issue Type: Bug
> Reporter: Priyanka Gugale
> Assignee: Priyanka Gugale
>
> CassandraInputOperator fetches less number of records than available in
> table. Also number of records returned in each runs are different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)