[jira] [Resolved] (IGNITE-12775) Update URLs and other content on Ignite downloads page

[Maxim Muzafarov (Jira)]

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

Maxim Muzafarov resolved IGNITE-12775.
--
Resolution: Fixed

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12775) Update URLs and other content on Ignite downloads page

[Maxim Muzafarov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083626#comment-17083626
 ] 

Maxim Muzafarov commented on IGNITE-12775:
--

[~dmagda]

thank you for the review.
I've merged changes to the master branch.

https://ignite.apache.org/download.cgi

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: IgniteCheckedException: Cannot enable read-through (loader or store is not provided) for cache

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12898:
-

 Summary: Server node with CacheStore fails to re-join the cluster: 
IgniteCheckedException: Cannot enable read-through (loader or store is not 
provided) for cache
 Key: IGNITE-12898
 URL: https://issues.apache.org/jira/browse/IGNITE-12898
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin


If a cache with external persistence is dynamically created on a non-affinity 
node then the cache affinity node cannot join the cluster after restart.
h2. Repro Steps
 # Run an "empty" Ignite node where no cache is going to be started
 # Run a cache affinity node having the "ROLE" attribute set to "DATA"
 # Create the cache from the "empty" node and use a Node Filter to limit the 
cache to the "data" node. External persistence is configured for the cache.
 # Restart the "data" node

h3. Actual Result
{{IgniteCheckedException: Cannot enable read-through (loader or store is not 
provided) for cache}}

h2. Reproducer
h3. Reproducer.java
{code:java}
public class Reproducer {
@Test
public void test() throws Exception {
final String DB_URL = "jdbc:h2:mem:test";
final String ENTITY_NAME = "Person";

Function igniteCfgFactory = instanceName ->
new IgniteConfiguration()
.setIgniteInstanceName(instanceName)
.setDiscoverySpi(new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

// 1. Run an "empty" Ignite node where no cache is going to be started
try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa", "");
 Statement dbStmt = dbConn.createStatement();
 Ignite emptyNode = 
Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
// 2. Run a "Person" cache affinity node having the "ROLE" 
attribute set to "DATA"
Map dataNodeAttrs = new HashMap<>(1);
dataNodeAttrs.put(DataNodeFilter.ATTR_NAME, 
DataNodeFilter.ATTR_VAL);

Ignite dataNode = 
Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));

// 3. Create the "Person" cache from the "empty" node and use a 
Node Filter to limit the cache to the
// "data" node. External persistence to the "Person" table in H2 DB 
is configured for the cache.
dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY 
KEY, name varchar)");

CacheJdbcPojoStoreFactory igniteStoreFactory 
= new CacheJdbcPojoStoreFactory<>();
igniteStoreFactory.setDataSourceFactory(() -> 
JdbcConnectionPool.create(DB_URL, "sa", ""))
.setTypes(
new JdbcType()
.setCacheName(ENTITY_NAME)
.setDatabaseTable(ENTITY_NAME)
.setKeyType(Integer.class)
.setValueType(ENTITY_NAME)
.setKeyFields(new JdbcTypeField(java.sql.Types.INTEGER, 
"id", Integer.class, "id"))
.setValueFields(
new JdbcTypeField(java.sql.Types.INTEGER, "id", 
Integer.class, "id"),
new JdbcTypeField(java.sql.Types.VARCHAR, "name", 
String.class, "name")
)
);

CacheConfiguration cacheCfg =
new CacheConfiguration(ENTITY_NAME)
.setCacheMode(CacheMode.REPLICATED)
.setCacheStoreFactory(igniteStoreFactory)
.setWriteThrough(true)
.setReadThrough(true)
.setNodeFilter(new DataNodeFilter());

emptyNode.createCache(cacheCfg).withKeepBinary();

// 4. Restart the "data" node
dataNode.close();
dataNode = 
Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));

dataNode.close();
}
}

private static class DataNodeFilter implements IgnitePredicate 
{
public static final String ATTR_NAME = "ROLE";
public static final String ATTR_VAL = "DATA";

@Override public boolean apply(ClusterNode node) {
Object role = node.attributes().get(ATTR_NAME);
return role != null && ATTR_VAL.equalsIgnoreCase(role.toString());
}
}
}
{code}

h3. build.gradle
{code:groovy}
dependencies {
compile group: 'org.apache.ignite', name: 'ignite-core', version: '2.8.0'
compile group: 'com.h2database', name: 'h2', version: '1.4.200'

testCompile group: 'junit', name: 'junit', version: '4.12'
}
{code}

h2. Workaround
Create dynamic caches only on the affinity nodes or use "static" caches defined 
in ignite node configuration.

h2. Stack Trace
{code}
class 

[jira] [Updated] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: Cannot enable read-through (loader or store is not provided) for cache

[Alexey Kukushkin (Jira)]

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

Alexey Kukushkin updated IGNITE-12898:
--
Summary: Server node with CacheStore fails to re-join the cluster: Cannot 
enable read-through (loader or store is not provided) for cache  (was: Server 
node with CacheStore fails to re-join the cluster: IgniteCheckedException: 
Cannot enable read-through (loader or store is not provided) for cache)

> Server node with CacheStore fails to re-join the cluster: Cannot enable 
> read-through (loader or store is not provided) for cache
> 
>
> Key: IGNITE-12898
> URL: https://issues.apache.org/jira/browse/IGNITE-12898
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
>
> If a cache with external persistence is dynamically created on a non-affinity 
> node then the cache affinity node cannot join the cluster after restart.
> h2. Repro Steps
>  # Run an "empty" Ignite node where no cache is going to be started
>  # Run a cache affinity node having the "ROLE" attribute set to "DATA"
>  # Create the cache from the "empty" node and use a Node Filter to limit the 
> cache to the "data" node. External persistence is configured for the cache.
>  # Restart the "data" node
> h3. Actual Result
> {{IgniteCheckedException: Cannot enable read-through (loader or store is not 
> provided) for cache}}
> h2. Reproducer
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> @Test
> public void test() throws Exception {
> final String DB_URL = "jdbc:h2:mem:test";
> final String ENTITY_NAME = "Person";
> Function igniteCfgFactory = instanceName 
> ->
> new IgniteConfiguration()
> .setIgniteInstanceName(instanceName)
> .setDiscoverySpi(new TcpDiscoverySpi()
> .setIpFinder(new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> // 1. Run an "empty" Ignite node where no cache is going to be started
> try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa", 
> "");
>  Statement dbStmt = dbConn.createStatement();
>  Ignite emptyNode = 
> Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
> // 2. Run a "Person" cache affinity node having the "ROLE" 
> attribute set to "DATA"
> Map dataNodeAttrs = new HashMap<>(1);
> dataNodeAttrs.put(DataNodeFilter.ATTR_NAME, 
> DataNodeFilter.ATTR_VAL);
> Ignite dataNode = 
> Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));
> // 3. Create the "Person" cache from the "empty" node and use a 
> Node Filter to limit the cache to the
> // "data" node. External persistence to the "Person" table in H2 
> DB is configured for the cache.
> dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY 
> KEY, name varchar)");
> CacheJdbcPojoStoreFactory 
> igniteStoreFactory = new CacheJdbcPojoStoreFactory<>();
> igniteStoreFactory.setDataSourceFactory(() -> 
> JdbcConnectionPool.create(DB_URL, "sa", ""))
> .setTypes(
> new JdbcType()
> .setCacheName(ENTITY_NAME)
> .setDatabaseTable(ENTITY_NAME)
> .setKeyType(Integer.class)
> .setValueType(ENTITY_NAME)
> .setKeyFields(new 
> JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"))
> .setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id", 
> Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name", 
> String.class, "name")
> )
> );
> CacheConfiguration cacheCfg =
> new CacheConfiguration(ENTITY_NAME)
> .setCacheMode(CacheMode.REPLICATED)
> .setCacheStoreFactory(igniteStoreFactory)
> .setWriteThrough(true)
> .setReadThrough(true)
> .setNodeFilter(new DataNodeFilter());
> emptyNode.createCache(cacheCfg).withKeepBinary();
> // 4. Restart the "data" node
> dataNode.close();
> dataNode = 
> Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));
> dataNode.close();
> }
> }
> private static class DataNodeFilter implements 
> IgnitePredicate {
> public static final String 

[jira] [Commented] (IGNITE-12890) JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns getPublicThreadPoolSize() instead of formatted executor service

[Maria Makedonskaya (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083674#comment-17083674
 ] 

Maria Makedonskaya commented on IGNITE-12890:
-

[~agura], could you please review my ticket?

> JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns 
> getPublicThreadPoolSize() instead of formatted executor service
> ---
>
> Key: IGNITE-12890
> URL: https://issues.apache.org/jira/browse/IGNITE-12890
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> while testing JmxWorker I found a possible bug in one of attributes of 
> IgniteMXBean
> 1. start ignite node with IGNITE_JMX_PORT=1100
> 2. get ExecutorServiceFormatted attribute via JMX
> {noformat}
> /usr/lib/jvm/java-8-oracle/bin/java -cp 
> ./ignite-test-tools-1.0.0-SNAPSHOT.jar org.apache.ignite.testtools.JmxWorker 
> -host=127.0.0.1 -port=1100 -bean=IgniteKernal -group=Kernal 
> -attribute=ExecutorServiceFormatted
> 8
> {noformat}
> a number does not looks like proper value for string representation of 
> complex object, browsing the code reveals following:
> {noformat}
>  @Override public String getExecutorServiceFormatted() {
>  assert cfg != null;
> return String.valueOf(cfg.getPublicThreadPoolSize());
>  }
> {noformat}
> We should deprecate 'getExecutorServiceFormatted' and create a new method 
> 'getPublicThreadPoolSize'.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-9144) A client node leaving a grid may trigger the wrong message about coordinator change in the logs

[Maria Makedonskaya (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083682#comment-17083682
 ] 

Maria Makedonskaya commented on IGNITE-9144:


Hi, [~ezagumennov], if you don't plan to continue this task, I will take it.

> A client node leaving a grid may trigger the wrong message about coordinator 
> change in the logs
> ---
>
> Key: IGNITE-9144
> URL: https://issues.apache.org/jira/browse/IGNITE-9144
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Artukhov
>Assignee: Evgenii Zagumennov
>Priority: Major
>
> The issue was introduced by https://issues.apache.org/jira/browse/IGNITE-8738.
> Suppose we have a grid with X server nodes and Y client nodes. Server nodes 
> are restarted periodically while client nodes are left untouched. In this 
> case *order* of current coordinator might be greater than *order* of any 
> client node. Then when some client node leaves the grid, we will erroneously 
> print the *Coordinator changed* message with *client* node being the previous 
> coordinator. E.g.:
> {noformat}
> [2018-07-19 14:55:28,897][INFO ][disco-event-worker-#61] Node left topology: 
> TcpDiscoveryNode [id=7240957f-a51b-452d-bfc8-420e8ef9ea68, addrs=[127.0.0.1, 
> 172.17.0.1, 172.25.1.15], sockAddrs=[/172.17.0.1:0, /127.0.0.1:0, 
> lab15.gridgain.local/172.25.1.15:0], discPort=0, order=16, intOrder=11, 
> lastExchangeTime=1532001260398, loc=false, ver=2.5.1#20180717-sha1:80e51c80, 
> isClient=true]
> [2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Topology snapshot 
> [ver=27, servers=3, clients=4, CPUs=96, offheap=260.0GB, heap=56.0GB]
> [2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Coordinator changed 
> [prev=TcpDiscoveryNode [id=7240957f-a51b-452d-bfc8-420e8ef9ea68, 
> addrs=[127.0.0.1, 172.17.0.1, 172.25.1.15], sockAddrs=[/172.17.0.1:0, 
> /127.0.0.1:0, lab15.gridgain.local/172.25.1.15:0], discPort=0, order=16, 
> intOrder=11, lastExchangeTime=1532001260398, loc=false, 
> ver=2.5.1#20180717-sha1:80e51c80, isClient=true], cur=TcpDiscoveryNode 
> [id=760fd8f2-b9d7-4953-aa86-3954c05c9feb, addrs=[127.0.0.1, 172.17.0.1, 
> 172.25.1.21], sockAddrs=[/172.17.0.1:47500, 
> lab21.gridgain.local/172.25.1.21:47500, /127.0.0.1:47500], discPort=47500, 
> order=21, intOrder=15, lastExchangeTime=1532001260428, loc=false, 
> ver=2.5.1#20180717-sha1:80e51c80, isClient=false]]
> [2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61]   ^-- Node 
> [id=22B15E97-9944-48B5-A473-5C64E75A4D5A, clusterState=ACTIVE]
> [2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61]   ^-- Baseline 
> [id=6, size=3, online=3, offline=0]
> [2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Data Regions 
> Configured:
> [2018-07-19 14:55:28,900][INFO ][disco-event-worker-#61]   ^-- default 
> [initSize=256.0 MiB, maxSize=60.0 GiB, persistenceEnabled=true]
> {noformat}
> The *Coordinator changed* message should not be here because in fact the 
> coordinator was not changed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-8732) SQL: REPLICATED cache cannot be left-joined to PARTITIONED

[Stanislav Lukyanov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083787#comment-17083787
 ] 

Stanislav Lukyanov commented on IGNITE-8732:


I'm now working on a draft of the approach #2 - treat REPLICATED as PARTITIONED.
It seems to be doable relatively cheap. The limitation with this approach is 
that it requires the primary partitions of REPLICATED and PARTITIONED caches to 
be collocated, i.e. the REPLICATED cache needs to have the same affinity key 
and affinity function.

> SQL: REPLICATED cache cannot be left-joined to PARTITIONED
> --
>
> Key: IGNITE-8732
> URL: https://issues.apache.org/jira/browse/IGNITE-8732
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: sql-engine
>
> *Steps to reproduce*
> # Run 
> {{org.apache.ignite.sqltests.ReplicatedSqlTest#testLeftJoinReplicatedPartitioned}}
> # Observe that we have 2x results on 2-node cluster
> *Root Cause*
> {{left LEFT JOIN right ON cond}} operation assumes full scan of of a left 
> expression. Currently we perform this scan on every node and then simply 
> merge results on reducer. Two nodes, two scans of {{REPLICATED}} cache, 2x 
> results.
> *Potential Solutions*
> We may consider several solutions. Deeper analysis is required to understand 
> which is the right one.
> # Perform deduplication on reducer - this most prospective and general 
> technique, described in more details below
> # Treat {{REPLICATED}} cache as {{PARTITIONED}}. Essentially, we just need to 
> pass proper backup filter. But what if {{REPLICATED}} cache spans more nodes 
> than {{PARTITIONED}}? We cannot rely on primary/backup in this case
> # Implement additional execution phase as follows: 
> {code}
> SELECT left.cols, right.cols FROM left INNER JOIN right ON cond;  
> // Get "inner join" part
> UNION
> UNICAST SELECT left.cols, [NULL].cols FROM left WHERE left.id NOT IN ([ids 
> from the first phase]) // Get "outer join" part
> {code}
> *Reducer Deduplication*
> The idea is to get all data locally and then perform final deduplication. 
> This may incur high network overhead, because of lot of duplicated left parts 
> would be transferred. However, this could be optimized greatly with the 
> following techniques applied one after another
> # Semi-jions: {{left}} is {{joined}} on mapper node, but instead of sending 
> {{(left, right)}} relation, we send {{(left) + (right)}}
> # In case {{left}} part is known to be idempotent (i.e. it produces the same 
> result set on all nodes), only one node will send {{(left) + (right)}}, other 
> nodes will send {{(right)}} only
> # Merge {{left}} results with if needed (i.e. if idempotence-related opto was 
> not applicable)
> # Join {{left}} and {{right}} parts on reducer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-8732) SQL: REPLICATED cache cannot be left-joined to PARTITIONED

[Stanislav Lukyanov (Jira)]

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

Stanislav Lukyanov reassigned IGNITE-8732:
--

Assignee: Stanislav Lukyanov

> SQL: REPLICATED cache cannot be left-joined to PARTITIONED
> --
>
> Key: IGNITE-8732
> URL: https://issues.apache.org/jira/browse/IGNITE-8732
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Stanislav Lukyanov
>Priority: Major
>  Labels: sql-engine
>
> *Steps to reproduce*
> # Run 
> {{org.apache.ignite.sqltests.ReplicatedSqlTest#testLeftJoinReplicatedPartitioned}}
> # Observe that we have 2x results on 2-node cluster
> *Root Cause*
> {{left LEFT JOIN right ON cond}} operation assumes full scan of of a left 
> expression. Currently we perform this scan on every node and then simply 
> merge results on reducer. Two nodes, two scans of {{REPLICATED}} cache, 2x 
> results.
> *Potential Solutions*
> We may consider several solutions. Deeper analysis is required to understand 
> which is the right one.
> # Perform deduplication on reducer - this most prospective and general 
> technique, described in more details below
> # Treat {{REPLICATED}} cache as {{PARTITIONED}}. Essentially, we just need to 
> pass proper backup filter. But what if {{REPLICATED}} cache spans more nodes 
> than {{PARTITIONED}}? We cannot rely on primary/backup in this case
> # Implement additional execution phase as follows: 
> {code}
> SELECT left.cols, right.cols FROM left INNER JOIN right ON cond;  
> // Get "inner join" part
> UNION
> UNICAST SELECT left.cols, [NULL].cols FROM left WHERE left.id NOT IN ([ids 
> from the first phase]) // Get "outer join" part
> {code}
> *Reducer Deduplication*
> The idea is to get all data locally and then perform final deduplication. 
> This may incur high network overhead, because of lot of duplicated left parts 
> would be transferred. However, this could be optimized greatly with the 
> following techniques applied one after another
> # Semi-jions: {{left}} is {{joined}} on mapper node, but instead of sending 
> {{(left, right)}} relation, we send {{(left) + (right)}}
> # In case {{left}} part is known to be idempotent (i.e. it produces the same 
> result set on all nodes), only one node will send {{(left) + (right)}}, other 
> nodes will send {{(right)}} only
> # Merge {{left}} results with if needed (i.e. if idempotence-related opto was 
> not applicable)
> # Join {{left}} and {{right}} parts on reducer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12807) Key and Value fields with same name and SQL DML

[Alexey Kukushkin (Jira)]

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

Alexey Kukushkin reassigned IGNITE-12807:
-

Assignee: (was: Alexey Kukushkin)

> Key and Value fields with same name and SQL DML
> ---
>
> Key: IGNITE-12807
> URL: https://issues.apache.org/jira/browse/IGNITE-12807
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
> Attachments: ignite-12807-vs-2.8.patch
>
>
> Key/Value API allows both the Key and Value have fields with same name. This 
> is a very popular arrangement since most users are ready to sacrifice extra 
> memory footprint for the sake of having a self-sufficient value entity.
> Using SQL DML to update such an entry will update only the key field, leaving 
> the value field unchanged. This is a huge usability issue for the mixed K/V 
> and SQL API apps.
> h1. Proposal
> h2. Requirements
> h3. Example Data Model
> Consider a business domain entity *Person \{ id: int, passportNo: String, 
> name: String }*
> Suppose an Ignite application development team decided to map the Person 
> entity to Ignite data model as:
>  * *PersonKey \{ id: int, passportNo: String }*
>  * *Person \{ passportNo: String, name: String }*
> h3. Public API
>  * *Cache API*: add new method {{setKeyValueFields(keyValueFields: 
> Set): QueryEntity}} to class {{QueryEntity}}
>  ** The method marks Cache API Key and Value fields that SQL API must 
> initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
>  ** It is still possible to use Cache API to initialize the fields marked 
> with {{setKeyValueFields}} to different values. SQL SELECT statement returns 
> value of such a field from the Key entity.
>  ** The method accepts a set of field names and returns the declaring class 
> instance for chaining.
>  ** The method throws {{ArgumentException}} if the Key and Value types are 
> available and the field types are different within the Key and Value entities.
>  * *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}} 
> statement's additional parameters list.
>  ** The parameter's value is a space-separated list of field names with the 
> semantics equivalent to that of the {{setKeyValueFields}} method described 
> above.
>  ** The parameter can be specified only if both the {{KEY_TYPE}} and 
> {{VALUE_TYPE}} parameters are specified.
> h3. Use Cases
> h4. Inserting Into Key and Value Fields With Same Name Initializes Both 
> Fields in QueryEntity-Defined Cache
>  * GIVEN a Person cache from the example data model configured like this in 
> Ignite:
> {code:java}
> new CacheConfiguration("CACHE")
> .setQueryEntities(Collections.singleton(
> new QueryEntity(PersonKey.class, Person.class)
> .addQueryField("id", int.class.getName(), null)
> .addQueryField("passportNo", String.class.getName(), null)
> .addQueryField("name", String.class.getName(), null)
> .setKeyFields(Collections.singleton("id"))
> .setKeyValueFields(Collections.singleton("passportNo"))
> ));
> {code}
>  ** AND an entry is added to the cache with this SQL statement:
> {code:sql}
>  INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1') 
> {code}
>  * WHEN the user gets the entity using Cache API:
> {code:java}
> final PersonKey K = new PersonKey(1, "1");
> Person v = cache.get(K); 
> {code}
>  * THEN the *passportNo* field is initialized to the same value within the 
> key and value entities:
> {code:java}
> assertEquals(K.passportNo, v.passportNo);
> {code}
> h4. Querying Key and Value Fields With Same Name and Different Values Returns 
> Value from the Key in QueryEntity-Defined Cache
>  * GIVEN a Person cache from the previous use case
>  ** AND an entry with different passportNo is added to the cache with this 
> Cache API:
> {code:java}
> final PersonKey K = new PersonKey(1, "1");
> final Person V = new Person("2", "Name1");
> cache.put(K, V);
> {code}
>  * WHEN the user runs this SQL to get the enty:
> {code:sql}
>  SELECT ID, PASSPORTNO, NAME FROM CACHE.Person 
> {code}
>  * THEN the retrieved PASSPORTNO is that of the Key: "1"
> h4. Inserting Into Key and Value Fields With Same Name Initializes Both 
> Fields in SQL-Defined Cache
>  * GIVEN a Person cache from the example data model configured like this in 
> Ignite:
> {code:sql}
> CREATE TABLE Person (
>   id int,
>   passportNo varchar,
>   name varchar,
>   PRIMARY KEY(id, passportNo)
> ) WITH "key_type=PersonKey, value_type=Person, key_value_fields=passportNo"
> {code}
>  ** AND an entry is added to the cache with this SQL statement:
> {code:sql}
>  INSERT INTO CACHE.Person (ID, 

[jira] [Assigned] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

[Alexey Kukushkin (Jira)]

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

Alexey Kukushkin reassigned IGNITE-12894:
-

Assignee: (was: Alexey Kukushkin)

> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in 
> discovery-based service deployment mode. 
>  Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
> switch to the discovery-based service deployment mode.
>  * Create a service initializing an {{IgniteAtomicService}} in method 
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
>  * Start an Ignite node with the service specified in the IgniteConfiguration
>  * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed 
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws 
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
> 
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based 
> service deployment mode (but not in the default deployment mode):
> {code:java}
> 
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET 
> {{GetServiceProxy}} API does not support the service wait timeout, which is 
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
>  Failed to initialize service (service will not be deployed): 
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
> waiting for future to complete.
>   at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
>   at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
>   at 
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
>   at 
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
>   at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
>   at 
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
>   at 
> org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
>   at java.base/java.util.HashMap.forEach(HashMap.java:1336)
>   at 
> 

[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

[Alexey Kukushkin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083017#comment-17083017
 ] 

Alexey Kukushkin commented on IGNITE-12894:
---

Might be related to IGNITE-12490

> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in 
> discovery-based service deployment mode. 
>  Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
> switch to the discovery-based service deployment mode.
>  * Create a service initializing an {{IgniteAtomicService}} in method 
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
>  * Start an Ignite node with the service specified in the IgniteConfiguration
>  * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed 
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws 
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
> 
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based 
> service deployment mode (but not in the default deployment mode):
> {code:java}
> 
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET 
> {{GetServiceProxy}} API does not support the service wait timeout, which is 
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
>  Failed to initialize service (service will not be deployed): 
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
> waiting for future to complete.
>   at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
>   at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
>   at 
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
>   at 
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
>   at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
>   at 
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
>   at 
> org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
>   at 

[jira] [Commented] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy

[Alexey Kukushkin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083015#comment-17083015
 ] 

Alexey Kukushkin commented on IGNITE-12490:
---

There is a single-node scenario causing same problem described in IGNITE-12894

> Service proxy throws "Service not found" exception right after deploy
> -
>
> Key: IGNITE-12490
> URL: https://issues.apache.org/jira/browse/IGNITE-12490
> Project: Ignite
>  Issue Type: Improvement
>  Components: managed services
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: ServiceInvokeTest.java
>
>
> In the following scenario:
>  * Start nodes A, B
>  * Deploy a service on A
>  * Create a service proxy on B
>  * Invoke the proxy
> The proxy invocation throws a service not found exception. As per discussion 
> [on the dev 
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
>  this case should be handled by an automatic retry, however, it's not.
> The reproducer is attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12345) Remote listener of IgniteMessaging has to run inside the Ignite Sandbox.

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082992#comment-17082992
 ] 

Ignite TC Bot commented on IGNITE-12345:


{panel:title=Branch: [pull/7666/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5219765buildTypeId=IgniteTests24Java8_RunAll]

> Remote listener of IgniteMessaging has to run inside the Ignite Sandbox.
> 
>
> Key: IGNITE-12345
> URL: https://issues.apache.org/jira/browse/IGNITE-12345
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remote listener of IgniteMessaging has to run on a remote node inside the 
> Ignite Sandbox if it is turned on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12821) control.sh validate_indexes must check that index size and cache size are same

[Kirill Tkalenko (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082892#comment-17082892
 ] 

Kirill Tkalenko commented on IGNITE-12821:
--

[~slava.koptilin] Pleas make code review.

> control.sh validate_indexes must check that index size and cache size are same
> --
>
> Key: IGNITE-12821
> URL: https://issues.apache.org/jira/browse/IGNITE-12821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Validate_indexes should check that index size and cache size are same. 
> That check must be enabled by option \{{--check-sizes}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12823) .NET: Service method with user type array parameter can't be found

[Alexey Kukushkin (Jira)]

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

Alexey Kukushkin updated IGNITE-12823:
--
Description: 
*+Setup+*
 * Ignite Java service with a method having an array of user types as a 
parameters, for example, caclulate(Parameter[] params)

*+Actions+*
 * .NET client calls the Ignite Java service, for example, 
ignite.GetServices().GetServiceProxy().calculate(new[] \{new 
Parameter()});

*+Expected+*
 * The service method is called

*+Actual+*
 * Exception "Could not find proxy method 'calculate' in class ICalculator"

*+Workaround+*
 * Replace array of user types with array of objects in the service methods 
signatures, for example, caclulate(Object[] params)

  was:
*+Setup+*
 * Java service with a method having an array of user types as a parameters, 
for example, caclulate(Parameter[] params)

*+Actions+*
 * .NET client calls the GG Java service, for example, 
ignite.GetServices().GetServiceProxy().calculate(new[] \{new 
Parameter()});

*+Expected+*
 * The service method is called

*+Actual+*
 * Exception "Could not find proxy method 'calculate' in class ICalculator"

*+Workaround+*
 * Replace array of user types with array of objects in the service methods 
signatures, for example, caclulate(Object[] params)


> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
>
> *+Setup+*
>  * Ignite Java service with a method having an array of user types as a 
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
>  * .NET client calls the Ignite Java service, for example, 
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new 
> Parameter()});
> *+Expected+*
>  * The service method is called
> *+Actual+*
>  * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
>  * Replace array of user types with array of objects in the service methods 
> signatures, for example, caclulate(Object[] params)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12895) AlreadyClosedException: this IndexReader is closed in Cluster Query

[Jira]

André Schäfer created IGNITE-12895:
--

 Summary: AlreadyClosedException: this IndexReader is closed in 
Cluster Query
 Key: IGNITE-12895
 URL: https://issues.apache.org/jira/browse/IGNITE-12895
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7.6
Reporter: André Schäfer


A simple text query like 

{code:java}
var query = new TextQuery(type, 
parse(search.getQuery())).setPageSize(search.getMaxResults());

try (final var cursor = cache.getCache(cacheName).query(query)) {
return stream(cursor).map(Entry::getValue).collect(toList());
}
{code}

in our 6 node setup produces in 3-5 log messages on ERROR level but seem to 
deliver a correct result set anyway. It seems that the "remote" searches may be 
performed on a closed index reader for some unknown reason.



{code}
 Failed to run query [qry=GridCacheQueryInfo [loc=false, trans=null, 
rdc=null, qry=GridCacheQueryAdapter [type=TEXT, clsName=Person, 
clause=(dietmar)^20.0 dietmar~1, filter=null, transform=null, part=null, 
incMeta=false, metrics=null, pageSize=1024, timeout=0, incBackups=false, 
forceLocal=false, dedup=false, prj=null, keepBinary=false, 
subjId=06170e29-2b5f-44e3-a0ae-35eceef94971, taskHash=0, mvccSnapshot=null], 
locFut=null, sndId=06170e29-2b5f-44e3-a0ae-35eceef94971, reqId=71340905, 
incMeta=false, all=false], node=3821e3d1-11b7-49c4-af19-df0fd32066e2]
{code}
{code}
org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed
at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:257)
at 
org.apache.lucene.index.BaseCompositeReader.document(BaseCompositeReader.java:116)
at org.apache.lucene.index.IndexReader.document(IndexReader.java:349)
at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:316)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex$It.findNext(GridLuceneIndex.java:381)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex$It.onNext(GridLuceneIndex.java:413)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex$It.onNext(GridLuceneIndex.java:308)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:41)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1144)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:234)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:109)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:107)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
 {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12807) Key and Value fields with same name and SQL DML

[Alexey Kukushkin (Jira)]

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

Alexey Kukushkin reassigned IGNITE-12807:
-

Assignee: Alexey Kukushkin

> Key and Value fields with same name and SQL DML
> ---
>
> Key: IGNITE-12807
> URL: https://issues.apache.org/jira/browse/IGNITE-12807
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
> Attachments: ignite-12807-vs-2.8.patch
>
>
> Key/Value API allows both the Key and Value have fields with same name. This 
> is a very popular arrangement since most users are ready to sacrifice extra 
> memory footprint for the sake of having a self-sufficient value entity.
> Using SQL DML to update such an entry will update only the key field, leaving 
> the value field unchanged. This is a huge usability issue for the mixed K/V 
> and SQL API apps.
> h1. Proposal
> h2. Requirements
> h3. Example Data Model
> Consider a business domain entity *Person \{ id: int, passportNo: String, 
> name: String }*
> Suppose an Ignite application development team decided to map the Person 
> entity to Ignite data model as:
>  * *PersonKey \{ id: int, passportNo: String }*
>  * *Person \{ passportNo: String, name: String }*
> h3. Public API
>  * *Cache API*: add new method {{setKeyValueFields(keyValueFields: 
> Set): QueryEntity}} to class {{QueryEntity}}
>  ** The method marks Cache API Key and Value fields that SQL API must 
> initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
>  ** It is still possible to use Cache API to initialize the fields marked 
> with {{setKeyValueFields}} to different values. SQL SELECT statement returns 
> value of such a field from the Key entity.
>  ** The method accepts a set of field names and returns the declaring class 
> instance for chaining.
>  ** The method throws {{ArgumentException}} if the Key and Value types are 
> available and the field types are different within the Key and Value entities.
>  * *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}} 
> statement's additional parameters list.
>  ** The parameter's value is a space-separated list of field names with the 
> semantics equivalent to that of the {{setKeyValueFields}} method described 
> above.
>  ** The parameter can be specified only if both the {{KEY_TYPE}} and 
> {{VALUE_TYPE}} parameters are specified.
> h3. Use Cases
> h4. Inserting Into Key and Value Fields With Same Name Initializes Both 
> Fields in QueryEntity-Defined Cache
>  * GIVEN a Person cache from the example data model configured like this in 
> Ignite:
> {code:java}
> new CacheConfiguration("CACHE")
> .setQueryEntities(Collections.singleton(
> new QueryEntity(PersonKey.class, Person.class)
> .addQueryField("id", int.class.getName(), null)
> .addQueryField("passportNo", String.class.getName(), null)
> .addQueryField("name", String.class.getName(), null)
> .setKeyFields(Collections.singleton("id"))
> .setKeyValueFields(Collections.singleton("passportNo"))
> ));
> {code}
>  ** AND an entry is added to the cache with this SQL statement:
> {code:sql}
>  INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1') 
> {code}
>  * WHEN the user gets the entity using Cache API:
> {code:java}
> final PersonKey K = new PersonKey(1, "1");
> Person v = cache.get(K); 
> {code}
>  * THEN the *passportNo* field is initialized to the same value within the 
> key and value entities:
> {code:java}
> assertEquals(K.passportNo, v.passportNo);
> {code}
> h4. Querying Key and Value Fields With Same Name and Different Values Returns 
> Value from the Key in QueryEntity-Defined Cache
>  * GIVEN a Person cache from the previous use case
>  ** AND an entry with different passportNo is added to the cache with this 
> Cache API:
> {code:java}
> final PersonKey K = new PersonKey(1, "1");
> final Person V = new Person("2", "Name1");
> cache.put(K, V);
> {code}
>  * WHEN the user runs this SQL to get the enty:
> {code:sql}
>  SELECT ID, PASSPORTNO, NAME FROM CACHE.Person 
> {code}
>  * THEN the retrieved PASSPORTNO is that of the Key: "1"
> h4. Inserting Into Key and Value Fields With Same Name Initializes Both 
> Fields in SQL-Defined Cache
>  * GIVEN a Person cache from the example data model configured like this in 
> Ignite:
> {code:sql}
> CREATE TABLE Person (
>   id int,
>   passportNo varchar,
>   name varchar,
>   PRIMARY KEY(id, passportNo)
> ) WITH "key_type=PersonKey, value_type=Person, key_value_fields=passportNo"
> {code}
>  ** AND an entry is added to the cache with this SQL statement:
> {code:sql}
>  INSERT 

[jira] [Created] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness

[Zaar Hai (Jira)]

Zaar Hai created IGNITE-12896:
-

 Summary: excludeNeighbors=true breaks zone-awareness
 Key: IGNITE-12896
 URL: https://issues.apache.org/jira/browse/IGNITE-12896
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Zaar Hai


Good day,

 

If I configure node config as in the official [example 
|[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]
 but also set excludeNeighbors to true, then zone-aware partition distribution 
simply doesn't work. No errors or warnings that  found - it is just does not 
work. 

>From documentation it's not clear (at least to me) that excludeNeighbors=true 
>has such a critical implication on zone-awareness info. From what is sounds, 
>zone-awareness is an extension of excludeNeighbors.

I think this behavour should be fixed or at least documented with big red 
signs. As it's now, it resulted in several days of my time batting with 
zone-aware setup.

There are more details here in this StackOverflow question: 
[https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12821) control.sh validate_indexes must check that index size and cache size are same

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082891#comment-17082891
 ] 

Ignite TC Bot commented on IGNITE-12821:


{panel:title=Branch: [pull/7613/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5219894buildTypeId=IgniteTests24Java8_RunAll]

> control.sh validate_indexes must check that index size and cache size are same
> --
>
> Key: IGNITE-12821
> URL: https://issues.apache.org/jira/browse/IGNITE-12821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Validate_indexes should check that index size and cache size are same. 
> That check must be enabled by option \{{--check-sizes}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12343) Remote filter and transformer of ContinuousQueries have to run inside the Ignite Sandbox

[Denis Garus (Jira)]

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

Denis Garus reassigned IGNITE-12343:


Assignee: Denis Garus

> Remote filter and transformer of ContinuousQueries have to run inside the 
> Ignite Sandbox
> 
>
> Key: IGNITE-12343
> URL: https://issues.apache.org/jira/browse/IGNITE-12343
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> Remote filter and transformer of ContinuousQueries have to run on a remote 
> node inside the Ignite Sandbox if it is turned on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12821) control.sh validate_indexes must check that index size and cache size are same

[Vyacheslav Koptilin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083252#comment-17083252
 ] 

Vyacheslav Koptilin commented on IGNITE-12821:
--

Hi [~ktkale...@gridgain.com],

The PR looks good to me. Merged to master. Thanks for your contribution! 

> control.sh validate_indexes must check that index size and cache size are same
> --
>
> Key: IGNITE-12821
> URL: https://issues.apache.org/jira/browse/IGNITE-12821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Validate_indexes should check that index size and cache size are same. 
> That check must be enabled by option \{{--check-sizes}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12890) JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns getPublicThreadPoolSize() instead of formatted executor service

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083245#comment-17083245
 ] 

Ignite TC Bot commented on IGNITE-12890:


{panel:title=Branch: [pull/7667/head] Base: [master] : Possible Blockers 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5222394]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5219417buildTypeId=IgniteTests24Java8_RunAll]

> JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns 
> getPublicThreadPoolSize() instead of formatted executor service
> ---
>
> Key: IGNITE-12890
> URL: https://issues.apache.org/jira/browse/IGNITE-12890
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> while testing JmxWorker I found a possible bug in one of attributes of 
> IgniteMXBean
> 1. start ignite node with IGNITE_JMX_PORT=1100
> 2. get ExecutorServiceFormatted attribute via JMX
> {noformat}
> /usr/lib/jvm/java-8-oracle/bin/java -cp 
> ./ignite-test-tools-1.0.0-SNAPSHOT.jar org.apache.ignite.testtools.JmxWorker 
> -host=127.0.0.1 -port=1100 -bean=IgniteKernal -group=Kernal 
> -attribute=ExecutorServiceFormatted
> 8
> {noformat}
> a number does not looks like proper value for string representation of 
> complex object, browsing the code reveals following:
> {noformat}
>  @Override public String getExecutorServiceFormatted() {
>  assert cfg != null;
> return String.valueOf(cfg.getPublicThreadPoolSize());
>  }
> {noformat}
> We should deprecate 'getExecutorServiceFormatted' and create a new method 
> 'getPublicThreadPoolSize'.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12890) JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns getPublicThreadPoolSize() instead of formatted executor service

[Maria Makedonskaya (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083279#comment-17083279
 ] 

Maria Makedonskaya commented on IGNITE-12890:
-

[PDS 
(Indexing)|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexing?branch=pull%2F7667%2Fhead]
 suite timeout is not related to my changes.

> JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns 
> getPublicThreadPoolSize() instead of formatted executor service
> ---
>
> Key: IGNITE-12890
> URL: https://issues.apache.org/jira/browse/IGNITE-12890
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> while testing JmxWorker I found a possible bug in one of attributes of 
> IgniteMXBean
> 1. start ignite node with IGNITE_JMX_PORT=1100
> 2. get ExecutorServiceFormatted attribute via JMX
> {noformat}
> /usr/lib/jvm/java-8-oracle/bin/java -cp 
> ./ignite-test-tools-1.0.0-SNAPSHOT.jar org.apache.ignite.testtools.JmxWorker 
> -host=127.0.0.1 -port=1100 -bean=IgniteKernal -group=Kernal 
> -attribute=ExecutorServiceFormatted
> 8
> {noformat}
> a number does not looks like proper value for string representation of 
> complex object, browsing the code reveals following:
> {noformat}
>  @Override public String getExecutorServiceFormatted() {
>  assert cfg != null;
> return String.valueOf(cfg.getPublicThreadPoolSize());
>  }
> {noformat}
> We should deprecate 'getExecutorServiceFormatted' and create a new method 
> 'getPublicThreadPoolSize'.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12897) Add .NET api to enabling SQL indexing for existing cache.

[Ivan Daschinskiy (Jira)]

Ivan Daschinskiy created IGNITE-12897:
-

 Summary: Add .NET api to enabling SQL indexing for existing cache.
 Key: IGNITE-12897
 URL: https://issues.apache.org/jira/browse/IGNITE-12897
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy


Add .NET api to enabling SQL indexing for existing cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083349#comment-17083349
 ] 

Ignite TC Bot commented on IGNITE-12893:


{panel:title=Branch: [pull/7670/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5221358buildTypeId=IgniteTests24Java8_RunAll]

> Add support for the SimplifyBooleanExpression rule to checkstyle
> 
>
> Key: IGNITE-12893
> URL: https://issues.apache.org/jira/browse/IGNITE-12893
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The rule must be supported by the checkstyle according to Ignite coding 
> conventions [1].
> {code}
> 
> {code}
>  
> https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness

[Ilya Kasnacheev (Jira)]

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

Ilya Kasnacheev updated IGNITE-12896:
-
Component/s: cache

> excludeNeighbors=true breaks zone-awareness
> ---
>
> Key: IGNITE-12896
> URL: https://issues.apache.org/jira/browse/IGNITE-12896
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
>Reporter: Zaar Hai
>Priority: Major
>
> Good day,
>  
> If I configure node config as in the official [example 
> |[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]
>  but also set excludeNeighbors to true, then zone-aware partition 
> distribution simply doesn't work. No errors or warnings that  found - it is 
> just does not work. 
> From documentation it's not clear (at least to me) that excludeNeighbors=true 
> has such a critical implication on zone-awareness info. From what is sounds, 
> zone-awareness is an extension of excludeNeighbors.
> I think this behavour should be fixed or at least documented with big red 
> signs. As it's now, it resulted in several days of my time batting with 
> zone-aware setup.
> There are more details here in this StackOverflow question: 
> [https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness

[Ilya Kasnacheev (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083284#comment-17083284
 ] 

Ilya Kasnacheev commented on IGNITE-12896:
--

I think than, when running in docker/k8s, Ignite can't tell one server from 
another and consider them all neighbors, and stopping partition picking logic 
at that.

> excludeNeighbors=true breaks zone-awareness
> ---
>
> Key: IGNITE-12896
> URL: https://issues.apache.org/jira/browse/IGNITE-12896
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Zaar Hai
>Priority: Major
>
> Good day,
>  
> If I configure node config as in the official [example 
> |[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]
>  but also set excludeNeighbors to true, then zone-aware partition 
> distribution simply doesn't work. No errors or warnings that  found - it is 
> just does not work. 
> From documentation it's not clear (at least to me) that excludeNeighbors=true 
> has such a critical implication on zone-awareness info. From what is sounds, 
> zone-awareness is an extension of excludeNeighbors.
> I think this behavour should be fixed or at least documented with big red 
> signs. As it's now, it resulted in several days of my time batting with 
> zone-aware setup.
> There are more details here in this StackOverflow question: 
> [https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness

[Ilya Kasnacheev (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083294#comment-17083294
 ] 

Ilya Kasnacheev commented on IGNITE-12896:
--

Yes, you are right, setting excludeNeighbours ignores any backup filtering 
logic, and in the way how it is implemented I think it's a bug.

> excludeNeighbors=true breaks zone-awareness
> ---
>
> Key: IGNITE-12896
> URL: https://issues.apache.org/jira/browse/IGNITE-12896
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
>Reporter: Zaar Hai
>Priority: Major
>
> Good day,
>  
> If I configure node config as in the official [example 
> |[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]
>  but also set excludeNeighbors to true, then zone-aware partition 
> distribution simply doesn't work. No errors or warnings that  found - it is 
> just does not work. 
> From documentation it's not clear (at least to me) that excludeNeighbors=true 
> has such a critical implication on zone-awareness info. From what is sounds, 
> zone-awareness is an extension of excludeNeighbors.
> I think this behavour should be fixed or at least documented with big red 
> signs. As it's now, it resulted in several days of my time batting with 
> zone-aware setup.
> There are more details here in this StackOverflow question: 
> [https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12855) Node failed after get operation when entries from the cache expired concurrently

[Anton Kalashnikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083192#comment-17083192
 ] 

Anton Kalashnikov commented on IGNITE-12855:


[~alex_pl] [~alex_pl] thanks for your changes. But unfortunately, it broke one 
important invariant. 
There was a bug with deadlock between checkpointLock and entryLock - they were 
taken in a different order in different cases. It was fixed at 
https://issues.apache.org/jira/browse/IGNITE-12594, so after that, we always 
take entryLock only after checkpointLock. These changes weren't clear enough 
because they require from you invoking method such GridCacheMapEntry#innerGet 
only under checkpointLock which is not obvious. Anyway, as I can see your 
changes make it possible to reorder these locks again, which is not good and it 
should be fixed. If you have an idea of how to simplify lock ordering logic, 
please, share it. 

> Node failed after get operation when entries from the cache expired 
> concurrently 
> -
>
> Key: IGNITE-12855
> URL: https://issues.apache.org/jira/browse/IGNITE-12855
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Failed with the error:
> {noformat}
> [12:10:50] (err) Failed to notify listener: 
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter$6...@7c956694java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2456)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4401)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4095)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:767)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGetVersioned(GridCacheMapEntry.java:694)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2175)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:709)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:413)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:279)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:261)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:821)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:836)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:152)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:150)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> {noformat}
> Reproducer:
>  
> {code:java}
> @Test
> public void 

[jira] [Commented] (IGNITE-12873) Hosts names resolution takes place even if all nodes are configured via ip addresses

[Alexey Goncharuk (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083377#comment-17083377
 ] 

Alexey Goncharuk commented on IGNITE-12873:
---

[~ktkale...@gridgain.com] I think that we need to handle the IP address 
{{0.0.0.0}} and any loopback IP specifically and still send the hostname if 
this particular IP is specified. Otherwise, other nodes will try to always 
connect to the local host, not to a remote node.

> Hosts names resolution takes place even if all nodes are configured via ip 
> addresses
> 
>
> Key: IGNITE-12873
> URL: https://issues.apache.org/jira/browse/IGNITE-12873
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We got a problem: When connection with DNS was lost transactions processing 
> hanged up. This happened because IgniteUtils.toSocketAddresses resolves 
> hostName even if all nodes are configured via ip-addresses.
> {code:java}
> Thread [name=""utility-#432631%GRID%GridNodeName%"", id=992176, 
> state=RUNNABLE, blockCnt=1, waitCnt=16]
>  at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
>  at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
>  at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
>  at java.net.InetAddress.getAllByName0(InetAddress.java:1277)
>  at java.net.InetAddress.getAllByName(InetAddress.java:1193)
>  at java.net.InetAddress.getAllByName(InetAddress.java:1127)
>  at java.net.InetAddress.getByName(InetAddress.java:1077)
>  at java.net.InetSocketAddress.(InetSocketAddress.java:220)
>  at o.a.i.i.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:8982)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.nodeAddresses(TcpCommunicationSpi.java:3228)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.nodeAddresses(TcpCommunicationSpi.java:3200)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3291)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:3027)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2907)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2750)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2709)
>  at o.a.i.i.managers.communication.GridIoManager.send(GridIoManager.java:1643)
>  at 
> o.a.i.i.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1863)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1873)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1844)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1826)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:1244)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:1181)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:882)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler.access$600(CacheContinuousQueryHandler.java:85)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$2.onEntryUpdated(CacheContinuousQueryHandler.java:429)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:400)
>  at 
> o.a.i.i.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:659)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:796)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:603)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:475)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:532)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1017)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:896)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:852)
>  at 
> 

[jira] [Commented] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness

[Vyacheslav Koptilin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083391#comment-17083391
 ] 

Vyacheslav Koptilin commented on IGNITE-12896:
--

Hello [~haizaar],

Yes, it seems the following pages should be updated:
 - provide comprehensive information about {{excludeNeighbors}} 
[https://apacheignite.readme.io/docs/affinity-collocation#section-affinity-function]
 - correct example 
[ClusterNodeAttributeAffinityBackupFilter|[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]

 

By the way, {{RendezvousAffinityFunction}} clearly describes this aspect
{code:java}
/**
 * Sets optional backup filter.
 * ...
 * 
 * Note that {@code affinityBackupFilter} is ignored if {@code 
excludeNeighbors} is set to {@code true}.
 * ...
 */
public RendezvousAffinityFunction setAffinityBackupFilter(
IgniteBiPredicate> affinityBackupFilter) 
{...}

{code}

> excludeNeighbors=true breaks zone-awareness
> ---
>
> Key: IGNITE-12896
> URL: https://issues.apache.org/jira/browse/IGNITE-12896
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
>Reporter: Zaar Hai
>Priority: Major
>
> Good day,
>  
> If I configure node config as in the official [example 
> |[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]
>  but also set excludeNeighbors to true, then zone-aware partition 
> distribution simply doesn't work. No errors or warnings that  found - it is 
> just does not work. 
> From documentation it's not clear (at least to me) that excludeNeighbors=true 
> has such a critical implication on zone-awareness info. From what is sounds, 
> zone-awareness is an extension of excludeNeighbors.
> I think this behavour should be fixed or at least documented with big red 
> signs. As it's now, it resulted in several days of my time batting with 
> zone-aware setup.
> There are more details here in this StackOverflow question: 
> [https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

[Maxim Muzafarov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083394#comment-17083394
 ] 

Maxim Muzafarov commented on IGNITE-12893:
--

Pavel, 

Thank you for the review, merged to the master branch.

> Add support for the SimplifyBooleanExpression rule to checkstyle
> 
>
> Key: IGNITE-12893
> URL: https://issues.apache.org/jira/browse/IGNITE-12893
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The rule must be supported by the checkstyle according to Ignite coding 
> conventions [1].
> {code}
> 
> {code}
>  
> https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12873) Hosts names resolution takes place even if all nodes are configured via ip addresses

[Alexey Goncharuk (Jira)]

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

Alexey Goncharuk updated IGNITE-12873:
--
Release Note: Ignite will not try to send and resolve hostnames when 
localHost is set as IP  (was: Not filling ATTR_HOST_NAMES in TcpCommunication 
if set the IP address as a local address, adding JVM option 
IGNITE_TCP_COMM_SET_ATTR_HOST_NAMES for backward compatibility.)

> Hosts names resolution takes place even if all nodes are configured via ip 
> addresses
> 
>
> Key: IGNITE-12873
> URL: https://issues.apache.org/jira/browse/IGNITE-12873
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We got a problem: When connection with DNS was lost transactions processing 
> hanged up. This happened because IgniteUtils.toSocketAddresses resolves 
> hostName even if all nodes are configured via ip-addresses.
> {code:java}
> Thread [name=""utility-#432631%GRID%GridNodeName%"", id=992176, 
> state=RUNNABLE, blockCnt=1, waitCnt=16]
>  at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
>  at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
>  at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
>  at java.net.InetAddress.getAllByName0(InetAddress.java:1277)
>  at java.net.InetAddress.getAllByName(InetAddress.java:1193)
>  at java.net.InetAddress.getAllByName(InetAddress.java:1127)
>  at java.net.InetAddress.getByName(InetAddress.java:1077)
>  at java.net.InetSocketAddress.(InetSocketAddress.java:220)
>  at o.a.i.i.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:8982)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.nodeAddresses(TcpCommunicationSpi.java:3228)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.nodeAddresses(TcpCommunicationSpi.java:3200)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3291)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:3027)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2907)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2750)
>  at 
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2709)
>  at o.a.i.i.managers.communication.GridIoManager.send(GridIoManager.java:1643)
>  at 
> o.a.i.i.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1863)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1873)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1844)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1826)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:1244)
>  at 
> o.a.i.i.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:1181)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:882)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler.access$600(CacheContinuousQueryHandler.java:85)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$2.onEntryUpdated(CacheContinuousQueryHandler.java:429)
>  at 
> o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:400)
>  at 
> o.a.i.i.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:659)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:796)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:603)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:475)
>  at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:532)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1017)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:896)
>  at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:852)
>  at 
> 

[jira] [Commented] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083378#comment-17083378
 ] 

Pavel Pereslegin commented on IGNITE-12893:
---

[~mmuzaf], looks good,
thanks for clearing the code and reducing the number of annoying inspection 
warnings.

> Add support for the SimplifyBooleanExpression rule to checkstyle
> 
>
> Key: IGNITE-12893
> URL: https://issues.apache.org/jira/browse/IGNITE-12893
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The rule must be supported by the checkstyle according to Ignite coding 
> conventions [1].
> {code}
> 
> {code}
>  
> https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness

[Vyacheslav Koptilin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083391#comment-17083391
 ] 

Vyacheslav Koptilin edited comment on IGNITE-12896 at 4/14/20, 4:24 PM:


Hello [~haizaar],

Yes, it seems the following pages should be updated:
  - provide comprehensive information about {{excludeNeighbors}} 
[https://apacheignite.readme.io/docs/affinity-collocation#section-affinity-function]
  - correct example 
[ClusterNodeAttributeAffinityBackupFilter|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]

By the way, {{RendezvousAffinityFunction}} clearly describes this aspect
{code:java}
/**
 * Sets optional backup filter.
 * ...
 * 
 * Note that {@code affinityBackupFilter} is ignored if {@code 
excludeNeighbors} is set to {@code true}.
 * ...
 */
public RendezvousAffinityFunction setAffinityBackupFilter(
IgniteBiPredicate> affinityBackupFilter) 
{...}

{code}


was (Author: slava.koptilin):
Hello [~haizaar],

Yes, it seems the following pages should be updated:
 - provide comprehensive information about {{excludeNeighbors}} 
[https://apacheignite.readme.io/docs/affinity-collocation#section-affinity-function]
 - correct example 
[ClusterNodeAttributeAffinityBackupFilter|[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]

 

By the way, {{RendezvousAffinityFunction}} clearly describes this aspect
{code:java}
/**
 * Sets optional backup filter.
 * ...
 * 
 * Note that {@code affinityBackupFilter} is ignored if {@code 
excludeNeighbors} is set to {@code true}.
 * ...
 */
public RendezvousAffinityFunction setAffinityBackupFilter(
IgniteBiPredicate> affinityBackupFilter) 
{...}

{code}

> excludeNeighbors=true breaks zone-awareness
> ---
>
> Key: IGNITE-12896
> URL: https://issues.apache.org/jira/browse/IGNITE-12896
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
>Reporter: Zaar Hai
>Priority: Major
>
> Good day,
>  
> If I configure node config as in the official [example 
> |[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]]
>  but also set excludeNeighbors to true, then zone-aware partition 
> distribution simply doesn't work. No errors or warnings that  found - it is 
> just does not work. 
> From documentation it's not clear (at least to me) that excludeNeighbors=true 
> has such a critical implication on zone-awareness info. From what is sounds, 
> zone-awareness is an extension of excludeNeighbors.
> I think this behavour should be fixed or at least documented with big red 
> signs. As it's now, it resulted in several days of my time batting with 
> zone-aware setup.
> There are more details here in this StackOverflow question: 
> [https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)