ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Aleksandrov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-8173) ignite.getOrCreateCache(cacheConfig).iterator() method works incorrect for replicated cache in case if some data node isn't in baseline
Date Mon, 09 Apr 2018 07:45:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrey Aleksandrov updated IGNITE-8173:
---------------------------------------
    Description: 
How to reproduce:

1)Create new server node and activate the cluster (run the StartOneServerAndActivate.java
example)
 2)Create another server node. (run the StartSecondServerNode.java example after step 1)
 3)Create client node that will create new replicated cache, put some values and try to get
the cache iterator. (run the StartClientNode.java example)

In this case you should see the log like that:

Elements in cache: 0
 **************************
 **************************
 **************************
 **************************

Elements in cache: 1000
 **************************
 **************************
 **************************
 **************************

Elements in cache: 1000
 **************************
 **************************
 **************************
 **************************

Elements in cache: 0
 **************************
 **************************
 **************************
 **************************

Elements in cache: 0
 **************************
 **************************

It means that sometime we see the cache values and sometime we do not. It happens because
second node isn't in the baseline topology. In this case all data was stored to first server
node and it's ok.

The problem here is that when we ask for the iterator then we choose the node that contains
the required cache and send to it scan query. At the moment we can choose the node in baseline
topology (with data) and empty node. Looks like this behavior should be changed.

Incorrect logic located at GridCacheQueryAdapter.java at "private Collection<ClusterNode>
nodes() throws IgniteCheckedException" method:
{noformat}
case REPLICATED:
    if (prj != null || part != null)
        return nodes(cctx, prj, part);

    if (cctx.affinityNode())
        return Collections.singletonList(cctx.localNode());

    Collection<ClusterNode> affNodes = nodes(cctx, null, null); //HERE WE HAVE BOTH
NODES AT affNodes

    return affNodes.isEmpty() ? affNodes : Collections.singletonList(F.rand(affNodes)) {noformat}
 

  was:
How to reproduce:

1)Create new server node and activate the cluster (run the StartOneServerAndActivate.java
example)
2)Create another server node. (run the StartSecondServerNode.java example after step 1)
3)Create client node that will create new replicated cache, put some values and try to get
the cache iterator. (run the StartClientNode.java example)

In this case you should see the log like that:

***** Elements in cache: 0
**************************
**************************
**************************
**************************
***** Elements in cache: 1000
**************************
**************************
**************************
**************************
***** Elements in cache: 1000
**************************
**************************
**************************
**************************
***** Elements in cache: 0
**************************
**************************
**************************
**************************
***** Elements in cache: 0
**************************
**************************



It means that sometime we see the cache values and sometime we do not. It happens because
second node isn't in the baseline topology. In this case all data was stored to first server
node and it's ok.

The problem here is that when we ask for the iterator then we choose the node that contains
the required cache and send to it scan query. At the moment we can choose the node in baseline
topology (with data) and empty node. Looks like this behavior should be changed.

Incorrect logic located at GridCacheQueryAdapter.java at "private Collection<ClusterNode>
nodes() throws IgniteCheckedException" method:


{noformat}
case REPLICATED:
    if (prj != null || part != null)
        return nodes(cctx, prj, part);

    if (cctx.affinityNode())
        return Collections.singletonList(cctx.localNode());

    Collection<ClusterNode> affNodes = nodes(cctx, null, null); //HERE WE HAVE BOTH
NODES AT affNodes

    return affNodes.isEmpty() ? affNodes : Collections.singletonList(F.rand(affNodes)) {noformat}
 


> ignite.getOrCreateCache(cacheConfig).iterator() method works incorrect for replicated
cache in case if some data node isn't in baseline
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-8173
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8173
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Andrey Aleksandrov
>            Priority: Major
>              Labels: persistence
>         Attachments: StartClientNode.java, StartOneServerAndActivate.java, StartSecondServerNode.java
>
>
> How to reproduce:
> 1)Create new server node and activate the cluster (run the StartOneServerAndActivate.java
example)
>  2)Create another server node. (run the StartSecondServerNode.java example after step
1)
>  3)Create client node that will create new replicated cache, put some values and try
to get the cache iterator. (run the StartClientNode.java example)
> In this case you should see the log like that:
> Elements in cache: 0
>  **************************
>  **************************
>  **************************
>  **************************
> Elements in cache: 1000
>  **************************
>  **************************
>  **************************
>  **************************
> Elements in cache: 1000
>  **************************
>  **************************
>  **************************
>  **************************
> Elements in cache: 0
>  **************************
>  **************************
>  **************************
>  **************************
> Elements in cache: 0
>  **************************
>  **************************
> It means that sometime we see the cache values and sometime we do not. It happens because
second node isn't in the baseline topology. In this case all data was stored to first server
node and it's ok.
> The problem here is that when we ask for the iterator then we choose the node that contains
the required cache and send to it scan query. At the moment we can choose the node in baseline
topology (with data) and empty node. Looks like this behavior should be changed.
> Incorrect logic located at GridCacheQueryAdapter.java at "private Collection<ClusterNode>
nodes() throws IgniteCheckedException" method:
> {noformat}
> case REPLICATED:
>     if (prj != null || part != null)
>         return nodes(cctx, prj, part);
>     if (cctx.affinityNode())
>         return Collections.singletonList(cctx.localNode());
>     Collection<ClusterNode> affNodes = nodes(cctx, null, null); //HERE WE HAVE
BOTH NODES AT affNodes
>     return affNodes.isEmpty() ? affNodes : Collections.singletonList(F.rand(affNodes))
{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message