[jira] [Commented] (IGNITE-6797) Handle IO errors in LFS files

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-6797:
--

One more fake error with this scenario:
{noformat}
java.lang.AssertionError: java.lang.AssertionError: Assertion error on lookup 
row: 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@a2ed544

at 
org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsThreadInterruptionTest.testInterruptsOnLFSRead(IgnitePdsThreadInterruptionTest.java:195)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.AssertionError: Assertion error on lookup row: 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@a2ed544
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1076)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:406)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:359)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:324)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:212)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:204)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1448)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:514)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:512)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:809)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:512)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4523)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4504)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:828)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:662)
at 
org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsThreadInterruptionTest$1.run(IgnitePdsThreadInterruptionTest.java:163)
... 1 more
Caused by: java.lang.AssertionError: itemId=5, directCnt=1, indirectCnt=0, 
page=00014521 [56][][free=0]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:454)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:498)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataTree.compareKeys(IgniteCacheOffheapManagerImpl.java:1929)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataTree.compare(IgniteCacheOffheapManagerImpl.java:1893)
at 

[jira] [Assigned] (IGNITE-6618) Web console: Do not show client nodes in node selection modal

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6618:
-

Assignee: Alexander Kalinin

> Web console: Do not show client nodes in node selection modal
> -
>
> Key: IGNITE-6618
> URL: https://issues.apache.org/jira/browse/IGNITE-6618
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Pavel Konstantinov
>Assignee: Alexander Kalinin
>Priority: Major
> Fix For: 2.4
>
>
> I tried to 'Execute on Selected Node' the following query
> {code}
> SELECT c.id, d.id, p.id, p.salary 
> FROM "c_partitioned".City c
> inner join "c_partitioned".Department d
> on c.id=d.CTYID 
> inner join "c_partitioned".Person p
> on d.id=p.depID and p.salary > 5000
> inner join "c_partitioned".PersonBonus pb
> on p.id=pb.perID and pb.COUNT  < 5000
> where exists (select * from "c_partitioned".Person where rank > 0)
> {code}
> and selected a client node in the list of nodes
> and got exception
> {code}
> General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, 
> d.id, p.id, p.salary 
>  FROM "c_partitioned".City c
>  inner join "c_partitioned".Department d
>  on c.id=d.CTYID 
>  inner join "c_partitioned".Person p
>  on d.id=p.depID and p.salary > 5000
>  inner join "c_partitioned".PersonBonus pb
>  on p.id=pb.perID and pb.COUNT < 5000
>  where exists (select * from "c_partitioned".Person where rank > 0) 
> [5-195]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Sunny Chan (JIRA)]

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

Sunny Chan commented on IGNITE-6252:


It's good thank you.

> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>Priority: Major
>
> During our testing, we have found that certain warning about prepared 
> statement:
> 2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with another Cluster instance.
> We notice that after this warning occurs some of the data didn't persist 
> properly in cassandra cache. After further examining the Ignite's 
> CassandraSessionImpl code in method 
> execute(BatchExecutionAssistance,Iterable), we found that at around [line 
> 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
>  if the prepare statement fails in the asnyc call, it will not retry the 
> operation as the error is stored in [line 
> 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
>  and cleared in [line 
> 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
>  but it was not checked again after going through the [ResultSetFuture 
> |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].
> I believe in line 307 you should check for error != null such that any 
> failure will be retry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6807) NPE is thrown if local query is executed on client

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-6807:
---

 Summary: NPE is thrown if local query is executed on client
 Key: IGNITE-6807
 URL: https://issues.apache.org/jira/browse/IGNITE-6807
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: sql
Affects Versions: 2.3
Reporter: Valentin Kulichenko


If a local query is executed on client node by mistake, ugly NPE is thrown:
{noformat}
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.segmentsCount(H2TreeIndex.java:162)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.threadLocalSegment(GridH2IndexBase.java:172)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find(H2TreeIndex.java:177)
at org.h2.index.BaseIndex.find(BaseIndex.java:128)
at org.h2.index.IndexCursor.find(IndexCursor.java:169)
at org.h2.table.TableFilter.next(TableFilter.java:468)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1452)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
... 21 more
{noformat}
We should detect this situation and throw proper exception instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6804:
-

[~dpavlov], yes thanks for clarifying the description.

> Print a warning if HashMap is passed into bulk update operations
> 
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Reporter: Denis Magda
>Priority: Critical
>  Labels: usability
> Fix For: 2.4
>
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are 
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap, 
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element. 
> However, we should make sure that we only print that warning once and not 
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6804:


[~dmagda],  I've changed description from HashMap to any not SortedMap, there 
can be a tons of maps provided into api. I suggest to check condition: not 
instanceof SortedMap. Are you agree?

> Print a warning if HashMap is passed into bulk update operations
> 
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Reporter: Denis Magda
>Priority: Critical
>  Labels: usability
> Fix For: 2.4
>
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are 
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap, 
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element. 
> However, we should make sure that we only print that warning once and not 
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6804:
---
Description: 
Ignite newcomers tend to stumble on deadlocks simply because the keys are 
passed in an unordered HashMap. Propose to do the following:
* update bulk operations Java docs.
* print out a warning if not SortedMap (e.g. HashMap, 
Weak/Identity/Concurrent/Linked HashMap etc) is passed into
a bulk method (instead of SortedMap) and contains more than 1 element. However, 
we should make sure that we only print that warning once and not every time the 
API is called.
* do not produce warning for explicit optimistic transactions

More details are here:
http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html

  was:
Ignite newcomers tend to stumble on deadlocks simply because the keys are 
passed in an unordered HashMap. Propose to do the following:
* update bulk operations Java docs.
* print out a warning if HashMap is passed into
a bulk method (instead of SortedMap) and contains more than 1 element. However, 
we should make sure that we only print that warning once and not every time the 
API is called.

More details are here:
http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html


> Print a warning if HashMap is passed into bulk update operations
> 
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Reporter: Denis Magda
>Priority: Critical
>  Labels: usability
> Fix For: 2.4
>
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are 
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap, 
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element. 
> However, we should make sure that we only print that warning once and not 
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6686) Document SQL Data Types

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6686:

Fix Version/s: (was: 2.4)
   2.3

> Document SQL Data Types
> ---
>
> Key: IGNITE-6686
> URL: https://issues.apache.org/jira/browse/IGNITE-6686
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> The data types page should include all SQL types supported and how they 
> mapped to a language or driver specific type. Presently the types are 
> represented in a tabular format:
> https://apacheignite-sql.readme.io/v2.3/docs/data-types
> Guys, please help to fill out langage/drivers specific columns:
> # [~ptupitsyn] - .NET data types.
> # [~isapego] - C++ and ODBC data type.
> # [~al.psc] - JDBC and JAVA data types.
> [~vozerov], please suggest what to do with these few types below. They 
> supported by H2 but I'm not sure how Ignite deals with them:
> http://www.h2database.com/html/datatypes.html#identity_type
> http://www.h2database.com/html/datatypes.html#binary_type
> http://www.h2database.com/html/datatypes.html#other_type
> http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type
> http://www.h2database.com/html/datatypes.html#blob_type
> http://www.h2database.com/html/datatypes.html#clob_type
> http://www.h2database.com/html/datatypes.html#array_type
> http://www.h2database.com/html/datatypes.html#enum_type



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6685) Release new Ignite SQL Documentation

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-6685:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Release new Ignite SQL Documentation
> 
>
> Key: IGNITE-6685
> URL: https://issues.apache.org/jira/browse/IGNITE-6685
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> The new SQL documentation is ready:
> https://apacheignite-sql.readme.io/docs
> Complete all the subtasks and the following bullet points before releasing it:
> * Hide all the SQL related docs on basic Java, NET, C++ and tools domains. Do 
> NOT remove them. There are many resources that refer to them.
> * Update all SQL and tools related articles on Apache Ignite site.
> * Run a crawler on the site to catch any 404 pages.
> * Make the new SQL doc visible to Google and other search engines.
> Validate correctness of DML syntax:
> http://apache-ignite-developers.2346864.n4.nabble.com/FOR-UPDATE-support-in-SELECT-clause-td23412.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6685) Release new Ignite SQL Documentation

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6685:
-

[~pgarg],

Please complete the steps below and close the ticket:
* Update all SQL and tools related pages on Apache Ignite site making sure all 
the references go to https://apacheignite-sql.readme.io/docs domain.
* Run a crawler on the site to catch any 404 pages.

> Release new Ignite SQL Documentation
> 
>
> Key: IGNITE-6685
> URL: https://issues.apache.org/jira/browse/IGNITE-6685
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.3
>
>
> The new SQL documentation is ready:
> https://apacheignite-sql.readme.io/docs
> Complete all the subtasks and the following bullet points before releasing it:
> * Hide all the SQL related docs on basic Java, NET, C++ and tools domains. Do 
> NOT remove them. There are many resources that refer to them.
> * Update all SQL and tools related articles on Apache Ignite site.
> * Run a crawler on the site to catch any 404 pages.
> * Make the new SQL doc visible to Google and other search engines.
> Validate correctness of DML syntax:
> http://apache-ignite-developers.2346864.n4.nabble.com/FOR-UPDATE-support-in-SELECT-clause-td23412.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6717) Hashcode/equals is not needed for custom keys serialized into a binary form

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6717:

Fix Version/s: (was: 2.4)
   2.3

> Hashcode/equals is not needed for custom keys serialized into a binary form
> ---
>
> Key: IGNITE-6717
> URL: https://issues.apache.org/jira/browse/IGNITE-6717
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> It turns out that hashCode/equals implementation is no longer required for 
> custom complex keys if a key is serialized to the binary form. Discussed here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-3-troubles-with-key-value-APIs-in-the-cluster-configured-with-DDL-td23501.html#a23506
> The marshaller calculates the hash code automatically. This info has to be 
> added to the binary marshaller page:
> https://apacheignite.readme.io/docs/binary-marshaller



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6806) Document logs forwarding to ELK stack

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6806:
---

 Summary: Document logs forwarding to ELK stack
 Key: IGNITE-6806
 URL: https://issues.apache.org/jira/browse/IGNITE-6806
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: documentation
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.4


Ignite logs can be forwarded to remote servers and software stacks for advanced 
processing.

For instance, this project shows how to do this for ELK stack:
https://github.com/akuramshingg/elk-monitor

Mention it on Ignite logging page:
https://apacheignite.readme.io/docs/logging



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6805) Tests are red for another MAX_BLOCK_SIZE value (4 or 8 instead 32)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-6805:


 Summary: Tests are red for another MAX_BLOCK_SIZE value (4 or 8 
instead 32)
 Key: IGNITE-6805
 URL: https://issues.apache.org/jira/browse/IGNITE-6805
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.4
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In SparseDistributedBlockMatrixTest are red next tests
* testCacheBehaviour
* testSquareMatrixTimes
with another value of constant MAX_BLOCK_SIZE (4 or 8, for example)

In my opinion, it means that algorithm is incorrect for matrices with large 
number of blocks



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6804:
---

 Summary: Print a warning if HashMap is passed into bulk update 
operations
 Key: IGNITE-6804
 URL: https://issues.apache.org/jira/browse/IGNITE-6804
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: cache
Reporter: Denis Magda
Priority: Critical
 Fix For: 2.4


Ignite newcomers tend to stumble on deadlocks simply because the keys are 
passed in an unordered HashMap. Propose to do the following:
* update bulk operations Java docs.
* print out a warning if HashMap is passed into
a bulk method (instead of SortedMap) and contains more than 1 element. However, 
we should make sure that we only print that warning once and not every time the 
API is called.

More details are here:
http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2656:

Fix Version/s: (was: 2.3)
   2.4

> Documentation on debugging and fixing the reasons of node disconnection from 
> the cluster
> 
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.4
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the 
> issue by looking at logs files. Usually the node that was kicked off contains 
> "Local node segmented" message and the node that failed its next neighbor 
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about 
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and 
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by 
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout, 
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout, 
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to 
> be mentioned as well.
>   
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for 
> join result, node stop, socket reader first message.) there as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6717) Hashcode/equals is not needed for custom keys serialized into a binary form

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6717:

Fix Version/s: (was: 2.3)
   2.4

> Hashcode/equals is not needed for custom keys serialized into a binary form
> ---
>
> Key: IGNITE-6717
> URL: https://issues.apache.org/jira/browse/IGNITE-6717
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> It turns out that hashCode/equals implementation is no longer required for 
> custom complex keys if a key is serialized to the binary form. Discussed here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-3-troubles-with-key-value-APIs-in-the-cluster-configured-with-DDL-td23501.html#a23506
> The marshaller calculates the hash code automatically. This info has to be 
> added to the binary marshaller page:
> https://apacheignite.readme.io/docs/binary-marshaller



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6803) UriDeploymentSpi affects execution of other tasks, including Ignite internals

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-6803:
---

Assignee: Ilya Kasnacheev

https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2955%2Fhead

> UriDeploymentSpi affects execution of other tasks, including Ignite internals
> -
>
> Key: IGNITE-6803
> URL: https://issues.apache.org/jira/browse/IGNITE-6803
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>
> From the maillist:
> http://apache-ignite-users.70518.x6.nabble.com/Code-deployment-throught-UriDeploumentSpi-tt17807.html
> In our project we need to deploy custom compute tasks into cluster without 
> cluster restart and p2p class loading.  
> I try to use org.apache.ignite.spi.deployment.uri.UriDeploumentSpi for that 
> purpose, but I have a problem.
> I have simple Ignite Service and Ignite Compute Task which use it throught 
> @ServiceResource.
> This ComputeTask located into .gar file which was deployed via 
> UriDeploumentSpi.
> If I have service implementation on each node(node singleton service) then it 
> works great. 
> But if I deploy service as a cluster singleton then task executes correctly 
> only on node with this service. 
> On other nodes @ServiceResource returns ServiceProxy that throws exception on 
> service remote method invokation (lambda with service call cannot be 
> deployed):
> {code}
> SEVERE: Failed to execute job 
> [jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=task-one, 
> dep=GridDeployment [ts=1509275650885, depMode=SHARED, 
> clsLdr=GridUriDeploymentClassLoader 
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
>  clsLdrId=7eb15d76f51-428ec712-e6d0-4eab-97f9-ce58d7b3e0f5, userVer=0, 
> loc=true, sampleClsName=com.gridfore.tfedyanin.deploy.Task1, 
> pendingUndeploy=false, undeployed=false, usage=1], 
> taskClsName=com.gridfore.tfedyanin.deploy.Task1, 
> sesId=38a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
> startTime=1509275650601, endTime=9223372036854775807, 
> taskNodeId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
> clsLdr=GridUriDeploymentClassLoader 
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
>  closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1, 
> fullSup=false, internal=false, subjId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
> mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false, 
> state=INIT, res=null, hash=1254296516]], execName=null], 
> jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86]]
> class org.apache.ignite.IgniteDeploymentException: Failed to auto-deploy task 
> (was task (re|un)deployed?): class 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceTopologyCallable
> {code}
> Problem works as follows:
> - Ignite has to determine which node has deployed service, by name.
> - Ignite has to send ServiceTopologyCallable task.
> - Ignite tries to deploy ServiceTopologyCallable task using UriDeploymentSpi.
> - UriDeploymentSpi doesn't have it obviously, but it also tries to fallback 
> towards "CLASS" loading from local ClassLoader
> - Which fails because it is told that ServiceTopologyCallable comes from its 
> classloader and not from the local one!
> So I'm at loss where it should be fixed properly. It is also sad that we are 
> using all that deploy pipeline to handle IgniteInternal tasks, but there 
> obviously are non-internal local tasks which might be affected by same 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6803) UriDeploymentSpi affects execution of other tasks, including Ignite internals

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6803:


GitHub user alamar opened a pull request:

https://github.com/apache/ignite/pull/2955

IGNITE-6803 Inverse classloader widening condition to fix UriDeploymentSpi.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/alamar/ignite ignite-6803

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2955.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2955


commit 2a1419bc386b740a40633d744b87780a33232142
Author: Ilya Kasnacheev 
Date:   2017-10-31T17:11:55Z

IGNITE-6803 Inverse classloader widening condition to fix UriDeploymentSpi.




> UriDeploymentSpi affects execution of other tasks, including Ignite internals
> -
>
> Key: IGNITE-6803
> URL: https://issues.apache.org/jira/browse/IGNITE-6803
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>
> From the maillist:
> http://apache-ignite-users.70518.x6.nabble.com/Code-deployment-throught-UriDeploumentSpi-tt17807.html
> In our project we need to deploy custom compute tasks into cluster without 
> cluster restart and p2p class loading.  
> I try to use org.apache.ignite.spi.deployment.uri.UriDeploumentSpi for that 
> purpose, but I have a problem.
> I have simple Ignite Service and Ignite Compute Task which use it throught 
> @ServiceResource.
> This ComputeTask located into .gar file which was deployed via 
> UriDeploumentSpi.
> If I have service implementation on each node(node singleton service) then it 
> works great. 
> But if I deploy service as a cluster singleton then task executes correctly 
> only on node with this service. 
> On other nodes @ServiceResource returns ServiceProxy that throws exception on 
> service remote method invokation (lambda with service call cannot be 
> deployed):
> {code}
> SEVERE: Failed to execute job 
> [jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=task-one, 
> dep=GridDeployment [ts=1509275650885, depMode=SHARED, 
> clsLdr=GridUriDeploymentClassLoader 
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
>  clsLdrId=7eb15d76f51-428ec712-e6d0-4eab-97f9-ce58d7b3e0f5, userVer=0, 
> loc=true, sampleClsName=com.gridfore.tfedyanin.deploy.Task1, 
> pendingUndeploy=false, undeployed=false, usage=1], 
> taskClsName=com.gridfore.tfedyanin.deploy.Task1, 
> sesId=38a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
> startTime=1509275650601, endTime=9223372036854775807, 
> taskNodeId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
> clsLdr=GridUriDeploymentClassLoader 
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
>  closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1, 
> fullSup=false, internal=false, subjId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
> mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false, 
> state=INIT, res=null, hash=1254296516]], execName=null], 
> jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86]]
> class org.apache.ignite.IgniteDeploymentException: Failed to auto-deploy task 
> (was task (re|un)deployed?): class 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceTopologyCallable
> {code}
> Problem works as follows:
> - Ignite has to determine which node has deployed service, by name.
> - Ignite has to send ServiceTopologyCallable task.
> - Ignite tries to deploy ServiceTopologyCallable task using UriDeploymentSpi.
> - UriDeploymentSpi doesn't have it obviously, but it also tries to fallback 
> towards "CLASS" loading from local ClassLoader
> - Which fails because it is told that ServiceTopologyCallable comes from its 
> classloader and not from the local one!
> So I'm at loss where it should be fixed properly. It is also sad that we are 
> using all that deploy pipeline to handle IgniteInternal tasks, but there 
> obviously are non-internal local tasks which might be affected by same 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6803) UriDeploymentSpi affects execution of other tasks, including Ignite internals

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6803:
-

We should check whether the problem is confined to tasks ran as a result of 
UriDeploymentSpi task, or it affects any task in presence of UriDeploymentSpi 
in configuration.

> UriDeploymentSpi affects execution of other tasks, including Ignite internals
> -
>
> Key: IGNITE-6803
> URL: https://issues.apache.org/jira/browse/IGNITE-6803
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>
> From the maillist:
> http://apache-ignite-users.70518.x6.nabble.com/Code-deployment-throught-UriDeploumentSpi-tt17807.html
> In our project we need to deploy custom compute tasks into cluster without 
> cluster restart and p2p class loading.  
> I try to use org.apache.ignite.spi.deployment.uri.UriDeploumentSpi for that 
> purpose, but I have a problem.
> I have simple Ignite Service and Ignite Compute Task which use it throught 
> @ServiceResource.
> This ComputeTask located into .gar file which was deployed via 
> UriDeploumentSpi.
> If I have service implementation on each node(node singleton service) then it 
> works great. 
> But if I deploy service as a cluster singleton then task executes correctly 
> only on node with this service. 
> On other nodes @ServiceResource returns ServiceProxy that throws exception on 
> service remote method invokation (lambda with service call cannot be 
> deployed):
> {code}
> SEVERE: Failed to execute job 
> [jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=task-one, 
> dep=GridDeployment [ts=1509275650885, depMode=SHARED, 
> clsLdr=GridUriDeploymentClassLoader 
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
>  clsLdrId=7eb15d76f51-428ec712-e6d0-4eab-97f9-ce58d7b3e0f5, userVer=0, 
> loc=true, sampleClsName=com.gridfore.tfedyanin.deploy.Task1, 
> pendingUndeploy=false, undeployed=false, usage=1], 
> taskClsName=com.gridfore.tfedyanin.deploy.Task1, 
> sesId=38a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
> startTime=1509275650601, endTime=9223372036854775807, 
> taskNodeId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
> clsLdr=GridUriDeploymentClassLoader 
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
>  closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1, 
> fullSup=false, internal=false, subjId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
> mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false, 
> state=INIT, res=null, hash=1254296516]], execName=null], 
> jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86]]
> class org.apache.ignite.IgniteDeploymentException: Failed to auto-deploy task 
> (was task (re|un)deployed?): class 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceTopologyCallable
> {code}
> Problem works as follows:
> - Ignite has to determine which node has deployed service, by name.
> - Ignite has to send ServiceTopologyCallable task.
> - Ignite tries to deploy ServiceTopologyCallable task using UriDeploymentSpi.
> - UriDeploymentSpi doesn't have it obviously, but it also tries to fallback 
> towards "CLASS" loading from local ClassLoader
> - Which fails because it is told that ServiceTopologyCallable comes from its 
> classloader and not from the local one!
> So I'm at loss where it should be fixed properly. It is also sad that we are 
> using all that deploy pipeline to handle IgniteInternal tasks, but there 
> obviously are non-internal local tasks which might be affected by same 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6803) UriDeploymentSpi affects execution of other tasks, including Ignite internals

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-6803:
---

 Summary: UriDeploymentSpi affects execution of other tasks, 
including Ignite internals
 Key: IGNITE-6803
 URL: https://issues.apache.org/jira/browse/IGNITE-6803
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Ilya Kasnacheev


>From the maillist:
http://apache-ignite-users.70518.x6.nabble.com/Code-deployment-throught-UriDeploumentSpi-tt17807.html

In our project we need to deploy custom compute tasks into cluster without 
cluster restart and p2p class loading.  
I try to use org.apache.ignite.spi.deployment.uri.UriDeploumentSpi for that 
purpose, but I have a problem.

I have simple Ignite Service and Ignite Compute Task which use it throught 
@ServiceResource.
This ComputeTask located into .gar file which was deployed via UriDeploumentSpi.

If I have service implementation on each node(node singleton service) then it 
works great. 
But if I deploy service as a cluster singleton then task executes correctly 
only on node with this service. 

On other nodes @ServiceResource returns ServiceProxy that throws exception on 
service remote method invokation (lambda with service call cannot be deployed):

{code}
SEVERE: Failed to execute job 
[jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, ses=GridJobSessionImpl 
[ses=GridTaskSessionImpl [taskName=task-one, dep=GridDeployment 
[ts=1509275650885, depMode=SHARED, clsLdr=GridUriDeploymentClassLoader 
[urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
 clsLdrId=7eb15d76f51-428ec712-e6d0-4eab-97f9-ce58d7b3e0f5, userVer=0, 
loc=true, sampleClsName=com.gridfore.tfedyanin.deploy.Task1, 
pendingUndeploy=false, undeployed=false, usage=1], 
taskClsName=com.gridfore.tfedyanin.deploy.Task1, 
sesId=38a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, 
startTime=1509275650601, endTime=9223372036854775807, 
taskNodeId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
clsLdr=GridUriDeploymentClassLoader 
[urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
 closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false, 
internal=false, subjId=7919c34c-9a48-4068-bcd6-70dad5595e86, 
mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false, 
state=INIT, res=null, hash=1254296516]], execName=null], 
jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86]]
class org.apache.ignite.IgniteDeploymentException: Failed to auto-deploy task 
(was task (re|un)deployed?): class 
org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceTopologyCallable
{code}

Problem works as follows:
- Ignite has to determine which node has deployed service, by name.
- Ignite has to send ServiceTopologyCallable task.
- Ignite tries to deploy ServiceTopologyCallable task using UriDeploymentSpi.
- UriDeploymentSpi doesn't have it obviously, but it also tries to fallback 
towards "CLASS" loading from local ClassLoader
- Which fails because it is told that ServiceTopologyCallable comes from its 
classloader and not from the local one!

So I'm at loss where it should be fixed properly. It is also sad that we are 
using all that deploy pipeline to handle IgniteInternal tasks, but there 
obviously are non-internal local tasks which might be affected by same problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6640) Introduction of models import/export

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-6640:


[~chief] code looks good. I made few comments in the PR where you may want to 
take a second look

> Introduction of models import/export
> 
>
> Key: IGNITE-6640
> URL: https://issues.apache.org/jira/browse/IGNITE-6640
> Project: Ignite
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> We need to add basic import/export functionality for ml models. We will start 
> from simple binary save to file and load from file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-6802:


 Summary: NullPointerException when WAL store and WAL archive paths 
are same 
 Key: IGNITE-6802
 URL: https://issues.apache.org/jira/browse/IGNITE-6802
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Alexey Kukushkin
 Fix For: 2.4


Configuring WAL store and WAL archive paths to be the same results in 
NullPointerException. We should display a meaningful error about the 
misconfiguration instead.

See 
http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
The thread includes the reproducer code and stack trace. I was able to 
reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6717) Hashcode/equals is not needed for custom keys serialized into a binary form

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6717:
-

[~pgarg], 

Overall, please review the sections below.

"Automatic GetHashCode and Equals Implementation" callout on:
https://apacheignite-sql.readme.io/v2.3/docs/net-schema-and-indexes
https://apacheignite-net.readme.io/v2.3/docs/serialization

 "Automatic Hash Code Calculation and Equals Implementation" callout on:
https://apacheignite.readme.io/docs/binary-marshaller#section-basic-concepts
https://apacheignite-sql.readme.io/v2.3/docs/schema-and-indexes#section-custom-keys


> Hashcode/equals is not needed for custom keys serialized into a binary form
> ---
>
> Key: IGNITE-6717
> URL: https://issues.apache.org/jira/browse/IGNITE-6717
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> It turns out that hashCode/equals implementation is no longer required for 
> custom complex keys if a key is serialized to the binary form. Discussed here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-3-troubles-with-key-value-APIs-in-the-cluster-configured-with-DDL-td23501.html#a23506
> The marshaller calculates the hash code automatically. This info has to be 
> added to the binary marshaller page:
> https://apacheignite.readme.io/docs/binary-marshaller



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6585) SVM for Apache Ignite ML module

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev reassigned IGNITE-6585:


Assignee: Aleksey Zinoviev  (was: Oleg Ignatenko)

> SVM for Apache Ignite ML module
> ---
>
> Key: IGNITE-6585
> URL: https://issues.apache.org/jira/browse/IGNITE-6585
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
>
> SVM - support vector machine, is pretty common algorithm and I think that we 
> need it in our module.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6801) Ignite Kafka Connector certification with Confluent

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-6801:


 Summary: Ignite Kafka Connector certification with Confluent
 Key: IGNITE-6801
 URL: https://issues.apache.org/jira/browse/IGNITE-6801
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
 Environment: 

Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
 Fix For: 2.4


Certifying Ignite Kafka connector with Confluent will give Ignite Community 
benefits like:
* TBD (I will put the benefits here after I confirm them)

A certified connector must be coded according to [these 
requirements](https://www.confluent.io/wp-content/uploads/Partner-Dev-Guide-for-Kafka-Connect.pdf),
 reviewed and approved by Confluent.
The existing ignite-kafka module does not comply with the requirements.

The purpose of this task to develop a certified version of the connector.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6640) Introduction of models import/export

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-6640:


[~oignatenko], could you please review those changes?

> Introduction of models import/export
> 
>
> Key: IGNITE-6640
> URL: https://issues.apache.org/jira/browse/IGNITE-6640
> Project: Ignite
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> We need to add basic import/export functionality for ml models. We will start 
> from simple binary save to file and load from file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6640) Introduction of models import/export

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6640:


GitHub user ybabak opened a pull request:

https://github.com/apache/ignite/pull/2953

IGNITE-6640: Introduction of models import/export



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6640

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2953.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2953


commit dfb9a657c7c07070a2620cdfc08af6970e6b7ea3
Author: Yury Babak 
Date:   2017-10-25T16:28:43Z

IGNITE-6640: Introduction of models import/export.
 added test for cluster model

commit 090e0ed9c5a14f0e8366941ebff6e1afe0aefa7b
Author: Yury Babak 
Date:   2017-10-30T22:46:21Z

IGNITE-6640: Introduction of models import/export.
Initial kmeans test passed.

commit 548ae4da1d65f1a70484fb228bc69f10d60d2340
Author: Yury Babak 
Date:   2017-10-31T15:45:15Z

IGNITE-6640: Introduction of models import/export.
 refactored model import/export functionality.

commit 883f99bed1ac76fe01a0ecb46d14e18d846cabff
Author: Yury Babak 
Date:   2017-10-31T15:48:55Z

Merge branch 'apacheMaster' into ignite-6640

# Conflicts:
#   
modules/ml/src/main/java/org/apache/ignite/ml/math/impls/storage/matrix/BlockMatrixStorage.java




> Introduction of models import/export
> 
>
> Key: IGNITE-6640
> URL: https://issues.apache.org/jira/browse/IGNITE-6640
> Project: Ignite
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> We need to add basic import/export functionality for ml models. We will start 
> from simple binary save to file and load from file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6252:
--

Hi [~sunnychanclsa],
Thank you for your contribution! I looked your code and did some minor changes. 
I've pushed the changes to ignite-6252 branch. Could you look at it and provide 
your feedback?


> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>
> During our testing, we have found that certain warning about prepared 
> statement:
> 2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with another Cluster instance.
> We notice that after this warning occurs some of the data didn't persist 
> properly in cassandra cache. After further examining the Ignite's 
> CassandraSessionImpl code in method 
> execute(BatchExecutionAssistance,Iterable), we found that at around [line 
> 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
>  if the prepare statement fails in the asnyc call, it will not retry the 
> operation as the error is stored in [line 
> 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
>  and cleared in [line 
> 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
>  but it was not checked again after going through the [ResultSetFuture 
> |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].
> I believe in line 307 you should check for error != null such that any 
> failure will be retry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5189) Unexpected error occurs when node left topology.

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-5189:
--

Fixed at 2.1 by IGNITE-5225

> Unexpected error occurs when node left topology.
> 
>
> Key: IGNITE-5189
> URL: https://issues.apache.org/jira/browse/IGNITE-5189
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8, 1.9, 2.0
>Reporter: Andrew Mashenkov
>Assignee: Alexey Popov
>
> Error occurs sporadically. Usually, it happens when one of server nodes left 
> topology and client can't connect to other servers via communication.
> Using preferIPv4 option solve the issue.
> Also, possibly the fact that it seems ok on ignite-1.6 version, may be 
> helpful.
> ERROR 2017-05-10T09:57:58,282 - 
> de.uplanet.test.integration.RemoteTestServiceBean[pool-4-thread-1]
> Failed to send message to remote node: TcpDiscoveryNode 
> [id=ef626cb1-3880-418e-a9d1-68fd692771fd, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.0.2.15, 127.0.0.1, 172.17.0.1], sockAddrs=[/172.17.0.1:0, 
> 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], discPort=0, order=3, 
> intOrder=3, lastExchangeTime=1494410235152, loc=false, 
> ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true]
> org.apache.ignite.spi.IgniteSpiException: Failed to send message to remote 
> node: TcpDiscoveryNode [id=ef626cb1-3880-418e-a9d1-68fd692771fd, 
> addrs=[0:0:0:0:0:0:0:1%lo, 10.0.2.15, 127.0.0.1, 172.17.0.1], 
> sockAddrs=[/172.17.0.1:0, 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], 
> discPort=0, order=3, intOrder=3, lastExchangeTime=1494410235152, loc=false, 
> ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2483)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2419)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1329)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1698)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessageToGridTopic(GridIoManager.java:1473)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendUserMessage(GridIoManager.java:1588)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.IgniteMessagingImpl.sendOrdered(IgniteMessagingImpl.java:165)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> de.uplanet.lucy.server.distributed.cloud.datagrid.ignite.IgniteGridTopic.publish(IgniteGridTopic.java:58)
>  ~[update/:?]
> at 
> de.uplanet.test.integration.RemoteTestServiceBean.lambda$3(RemoteTestServiceBean.java:123)
>  ~[update/:?]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_92]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [?:1.8.0_92]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_92]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
> Caused by: org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242) 
> ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2630)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2455)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> ... 13 more
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_92]
> 

[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6526:

Fix Version/s: (was: 2.3)
   2.4

> Ignite 2.x capacity planning guide
> --
>
> Key: IGNITE-6526
> URL: https://issues.apache.org/jira/browse/IGNITE-6526
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
> Fix For: 2.4
>
>
> Current capacity planning guide [1] is too high level and should be 
> elaborated considering durable memory's internals:
> - memory pages overhead.
> - per-entry overhead 
> (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
> - space occupied for indexing needs.
> - free lists
> - etc.
> The page has to include estimates for the Ignite Native Persistence:
> - entry size and its overheads.
> - index size and overheads.
> - data files overheads.
> - estimated WAL size and how to shrink it basing on checkpointing settings.
> [1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4718) Add section in documentation on what actions may cause deadlock

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4718:

Fix Version/s: (was: 2.3)
   2.4

> Add section in documentation on what actions may cause deadlock
> ---
>
> Key: IGNITE-4718
> URL: https://issues.apache.org/jira/browse/IGNITE-4718
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> Ignite has number of common cases, where wrong usage of API may lead to 
> deadlocks, starvations, cluster hangs, and they should be properly 
> documented. 
> For example, cache operations is not allowed in CacheEntryProcessor, 
> ContinuousQuery's remote filter, etc. And in some callbacks it's possible to 
> use cache API if they annotated with @IgniteAsyncCallback.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6686) Document SQL Data Types

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6686:

Fix Version/s: (was: 2.3)
   2.4

> Document SQL Data Types
> ---
>
> Key: IGNITE-6686
> URL: https://issues.apache.org/jira/browse/IGNITE-6686
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> The data types page should include all SQL types supported and how they 
> mapped to a language or driver specific type. Presently the types are 
> represented in a tabular format:
> https://apacheignite-sql.readme.io/v2.3/docs/data-types
> Guys, please help to fill out langage/drivers specific columns:
> # [~ptupitsyn] - .NET data types.
> # [~isapego] - C++ and ODBC data type.
> # [~al.psc] - JDBC and JAVA data types.
> [~vozerov], please suggest what to do with these few types below. They 
> supported by H2 but I'm not sure how Ignite deals with them:
> http://www.h2database.com/html/datatypes.html#identity_type
> http://www.h2database.com/html/datatypes.html#binary_type
> http://www.h2database.com/html/datatypes.html#other_type
> http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type
> http://www.h2database.com/html/datatypes.html#blob_type
> http://www.h2database.com/html/datatypes.html#clob_type
> http://www.h2database.com/html/datatypes.html#array_type
> http://www.h2database.com/html/datatypes.html#enum_type



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2737) Ignite-Spark documentation is missing some useful informations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2737:

Fix Version/s: (was: 2.3)
   2.4

> Ignite-Spark documentation is missing some useful informations
> --
>
> Key: IGNITE-2737
> URL: https://issues.apache.org/jira/browse/IGNITE-2737
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Luca Rea
>Assignee: Denis Magda
>  Labels: community
> Fix For: 2.4
>
>
> Hi,
> in my tests I have experienced some configuration issue running spark in 
> local and yarn-client mode, so I want to share them.
> In order to let Ignite work correctly I had to customize spark-defaults.conf 
> adding to "spark.driver.extraClassPath" and "spark.executor.extraClassPath" 
> the string
> {code}
> "/opt/ignite/libs/*:/opt/ignite/libs/optional/ignite-spark/*:/opt/ignite/libs/optional/ignite-log4j/*:/opt/ignite/libs/optional/ignite-yarn/*:/opt/ignite/libs/ignite-spring/*"
> {code}
> (opt/ignite is my IGNITE_HOME) and other IGNITE_ useful variables like 
> "spark.executorEnv.IGNITE_WORK_DIR" in order to let them be loaded by 
> executors.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4221) Document ComputeJobMasterLeaveAware interface usage

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4221:

Fix Version/s: (was: 2.3)
   2.4

> Document ComputeJobMasterLeaveAware interface usage
> ---
>
> Key: IGNITE-4221
> URL: https://issues.apache.org/jira/browse/IGNITE-4221
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> The usage and applicability of `ComputeJobMasterLeaveAware` have to be 
> documented on Apache Ignite Readme.io which will help out to avoid discussion 
> like that [1]. The new page has to be created for the topic and placed here 
> [2].
> In advance, the following example has to be contributed to Apache Ignite
> https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/compute/masterleave/ComputeMasterLeaveAwareExample.java
>  
> [1] 
> http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html
> [2] https://apacheignite.readme.io/docs/compute-grid#section-features



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4222) Document the usage of ComputeJobContinuation API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4222:

Fix Version/s: (was: 2.3)
   2.4

> Document the usage of ComputeJobContinuation API
> 
>
> Key: IGNITE-4222
> URL: https://issues.apache.org/jira/browse/IGNITE-4222
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> The usage and applicability of `ComputeJobContinuation` have to be documented 
> on Apache Ignite Readme.io which will help out to avoid discussion like those 
> [1] and [4]. The new page has to be created for the topic and placed here [2].
> The content should consist not only of technical details but also provide use 
> cases for this API:
> - don't block a thread from the public pool if a job is waiting for some 
> result. Put the thread back into the pool and wait for the result 
> asynchronously.
> - splitting a job into several pieces that can be executed in parallel. Refer 
> to this example [3].
>  
> [1] 
> http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html
> [2] https://apacheignite.readme.io/docs/compute-grid#section-features
> [3] 
> https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/computegrid/ComputeFibonacciContinuationExample.java
> [4] 
> http://apache-ignite-users.70518.x6.nabble.com/ignite-compute-job-continuation-documentation-td16725.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4361) Documentation: working with Ignite through JCache API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4361:

Fix Version/s: (was: 2.3)
   2.4

> Documentation: working with Ignite through JCache API
> -
>
> Key: IGNITE-4361
> URL: https://issues.apache.org/jira/browse/IGNITE-4361
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> Regardless of the fact that Ignite supports JCache API there is no any 
> documentation with code snippets that will elaborate on how to work with 
> Ignite purely with JCache API.
> This documentation [1] must contain a section showing all the ways how a 
> JCache Ignite provider can be created and used after that.
> [1] https://apacheignite.readme.io/docs/jcache



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6696) Update loading and streaming page on the site

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6696:

Fix Version/s: (was: 2.3)
   2.4

> Update loading and streaming page on the site
> -
>
> Key: IGNITE-6696
> URL: https://issues.apache.org/jira/browse/IGNITE-6696
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> The pages below incorporate table with streaming and loading features of 
> Ignite:
> * https://ignite.apache.org/features/streaming.html
> * https://ignite.apache.org/features.html
> Update them with the content for the following:
> * Data Loading: https://apacheignite.readme.io/docs/data-loading
> * Flink: https://apacheignite-mix.readme.io/docs/flink-streamer
> * ZeroMQ: https://apacheignite-mix.readme.io/docs/zeromq-streamer
> * RocketMQ: https://apacheignite-mix.readme.io/docs/rocketmq-streamer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4718) Add section in documentation on what actions may cause deadlock

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4718:

Fix Version/s: (was: 2.4)
   2.3

> Add section in documentation on what actions may cause deadlock
> ---
>
> Key: IGNITE-4718
> URL: https://issues.apache.org/jira/browse/IGNITE-4718
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Denis Magda
> Fix For: 2.3
>
>
> Ignite has number of common cases, where wrong usage of API may lead to 
> deadlocks, starvations, cluster hangs, and they should be properly 
> documented. 
> For example, cache operations is not allowed in CacheEntryProcessor, 
> ContinuousQuery's remote filter, etc. And in some callbacks it's possible to 
> use cache API if they annotated with @IgniteAsyncCallback.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2737) Ignite-Spark documentation is missing some useful informations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2737:

Fix Version/s: (was: 2.4)
   2.3

> Ignite-Spark documentation is missing some useful informations
> --
>
> Key: IGNITE-2737
> URL: https://issues.apache.org/jira/browse/IGNITE-2737
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Luca Rea
>Assignee: Denis Magda
>  Labels: community
> Fix For: 2.3
>
>
> Hi,
> in my tests I have experienced some configuration issue running spark in 
> local and yarn-client mode, so I want to share them.
> In order to let Ignite work correctly I had to customize spark-defaults.conf 
> adding to "spark.driver.extraClassPath" and "spark.executor.extraClassPath" 
> the string
> {code}
> "/opt/ignite/libs/*:/opt/ignite/libs/optional/ignite-spark/*:/opt/ignite/libs/optional/ignite-log4j/*:/opt/ignite/libs/optional/ignite-yarn/*:/opt/ignite/libs/ignite-spring/*"
> {code}
> (opt/ignite is my IGNITE_HOME) and other IGNITE_ useful variables like 
> "spark.executorEnv.IGNITE_WORK_DIR" in order to let them be loaded by 
> executors.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2656:

Fix Version/s: (was: 2.4)
   2.3

> Documentation on debugging and fixing the reasons of node disconnection from 
> the cluster
> 
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the 
> issue by looking at logs files. Usually the node that was kicked off contains 
> "Local node segmented" message and the node that failed its next neighbor 
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about 
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and 
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by 
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout, 
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout, 
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to 
> be mentioned as well.
>   
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for 
> join result, node stop, socket reader first message.) there as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5189) Unexpected error occurs when node left topology.

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-5189:
--

IgniteUtils.reachable is failed with NPE at
{{ return addr.isReachable(reachTimeout);}}
It means that addr is NULL here.

TcpCommunicationSpi.java:2891 passes a list with NULL element...


> Unexpected error occurs when node left topology.
> 
>
> Key: IGNITE-5189
> URL: https://issues.apache.org/jira/browse/IGNITE-5189
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8, 1.9, 2.0
>Reporter: Andrew Mashenkov
>Assignee: Alexey Popov
>
> Error occurs sporadically. Usually, it happens when one of server nodes left 
> topology and client can't connect to other servers via communication.
> Using preferIPv4 option solve the issue.
> Also, possibly the fact that it seems ok on ignite-1.6 version, may be 
> helpful.
> ERROR 2017-05-10T09:57:58,282 - 
> de.uplanet.test.integration.RemoteTestServiceBean[pool-4-thread-1]
> Failed to send message to remote node: TcpDiscoveryNode 
> [id=ef626cb1-3880-418e-a9d1-68fd692771fd, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.0.2.15, 127.0.0.1, 172.17.0.1], sockAddrs=[/172.17.0.1:0, 
> 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], discPort=0, order=3, 
> intOrder=3, lastExchangeTime=1494410235152, loc=false, 
> ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true]
> org.apache.ignite.spi.IgniteSpiException: Failed to send message to remote 
> node: TcpDiscoveryNode [id=ef626cb1-3880-418e-a9d1-68fd692771fd, 
> addrs=[0:0:0:0:0:0:0:1%lo, 10.0.2.15, 127.0.0.1, 172.17.0.1], 
> sockAddrs=[/172.17.0.1:0, 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], 
> discPort=0, order=3, intOrder=3, lastExchangeTime=1494410235152, loc=false, 
> ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2483)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2419)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1329)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1698)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessageToGridTopic(GridIoManager.java:1473)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendUserMessage(GridIoManager.java:1588)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.IgniteMessagingImpl.sendOrdered(IgniteMessagingImpl.java:165)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> de.uplanet.lucy.server.distributed.cloud.datagrid.ignite.IgniteGridTopic.publish(IgniteGridTopic.java:58)
>  ~[update/:?]
> at 
> de.uplanet.test.integration.RemoteTestServiceBean.lambda$3(RemoteTestServiceBean.java:123)
>  ~[update/:?]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_92]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [?:1.8.0_92]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_92]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
> Caused by: org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242) 
> ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2630)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2455)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> ... 13 more
> Caused by: 

[jira] [Updated] (IGNITE-4361) Documentation: working with Ignite through JCache API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4361:

Fix Version/s: (was: 2.4)
   2.3

> Documentation: working with Ignite through JCache API
> -
>
> Key: IGNITE-4361
> URL: https://issues.apache.org/jira/browse/IGNITE-4361
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> Regardless of the fact that Ignite supports JCache API there is no any 
> documentation with code snippets that will elaborate on how to work with 
> Ignite purely with JCache API.
> This documentation [1] must contain a section showing all the ways how a 
> JCache Ignite provider can be created and used after that.
> [1] https://apacheignite.readme.io/docs/jcache



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4221) Document ComputeJobMasterLeaveAware interface usage

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4221:

Fix Version/s: (was: 2.4)
   2.3

> Document ComputeJobMasterLeaveAware interface usage
> ---
>
> Key: IGNITE-4221
> URL: https://issues.apache.org/jira/browse/IGNITE-4221
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> The usage and applicability of `ComputeJobMasterLeaveAware` have to be 
> documented on Apache Ignite Readme.io which will help out to avoid discussion 
> like that [1]. The new page has to be created for the topic and placed here 
> [2].
> In advance, the following example has to be contributed to Apache Ignite
> https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/compute/masterleave/ComputeMasterLeaveAwareExample.java
>  
> [1] 
> http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html
> [2] https://apacheignite.readme.io/docs/compute-grid#section-features



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4222) Document the usage of ComputeJobContinuation API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4222:

Fix Version/s: (was: 2.4)
   2.3

> Document the usage of ComputeJobContinuation API
> 
>
> Key: IGNITE-4222
> URL: https://issues.apache.org/jira/browse/IGNITE-4222
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> The usage and applicability of `ComputeJobContinuation` have to be documented 
> on Apache Ignite Readme.io which will help out to avoid discussion like those 
> [1] and [4]. The new page has to be created for the topic and placed here [2].
> The content should consist not only of technical details but also provide use 
> cases for this API:
> - don't block a thread from the public pool if a job is waiting for some 
> result. Put the thread back into the pool and wait for the result 
> asynchronously.
> - splitting a job into several pieces that can be executed in parallel. Refer 
> to this example [3].
>  
> [1] 
> http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html
> [2] https://apacheignite.readme.io/docs/compute-grid#section-features
> [3] 
> https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/computegrid/ComputeFibonacciContinuationExample.java
> [4] 
> http://apache-ignite-users.70518.x6.nabble.com/ignite-compute-job-continuation-documentation-td16725.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5189) Unexpected error occurs when node left topology.

[Alexey Popov (JIRA)]

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

Alexey Popov reassigned IGNITE-5189:


Assignee: Alexey Popov

> Unexpected error occurs when node left topology.
> 
>
> Key: IGNITE-5189
> URL: https://issues.apache.org/jira/browse/IGNITE-5189
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8, 1.9, 2.0
>Reporter: Andrew Mashenkov
>Assignee: Alexey Popov
>
> Error occurs sporadically. Usually, it happens when one of server nodes left 
> topology and client can't connect to other servers via communication.
> Using preferIPv4 option solve the issue.
> Also, possibly the fact that it seems ok on ignite-1.6 version, may be 
> helpful.
> ERROR 2017-05-10T09:57:58,282 - 
> de.uplanet.test.integration.RemoteTestServiceBean[pool-4-thread-1]
> Failed to send message to remote node: TcpDiscoveryNode 
> [id=ef626cb1-3880-418e-a9d1-68fd692771fd, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.0.2.15, 127.0.0.1, 172.17.0.1], sockAddrs=[/172.17.0.1:0, 
> 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], discPort=0, order=3, 
> intOrder=3, lastExchangeTime=1494410235152, loc=false, 
> ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true]
> org.apache.ignite.spi.IgniteSpiException: Failed to send message to remote 
> node: TcpDiscoveryNode [id=ef626cb1-3880-418e-a9d1-68fd692771fd, 
> addrs=[0:0:0:0:0:0:0:1%lo, 10.0.2.15, 127.0.0.1, 172.17.0.1], 
> sockAddrs=[/172.17.0.1:0, 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], 
> discPort=0, order=3, intOrder=3, lastExchangeTime=1494410235152, loc=false, 
> ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2483)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2419)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1329)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1698)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessageToGridTopic(GridIoManager.java:1473)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendUserMessage(GridIoManager.java:1588)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.IgniteMessagingImpl.sendOrdered(IgniteMessagingImpl.java:165)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> de.uplanet.lucy.server.distributed.cloud.datagrid.ignite.IgniteGridTopic.publish(IgniteGridTopic.java:58)
>  ~[update/:?]
> at 
> de.uplanet.test.integration.RemoteTestServiceBean.lambda$3(RemoteTestServiceBean.java:123)
>  ~[update/:?]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_92]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [?:1.8.0_92]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_92]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
> Caused by: org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242) 
> ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2630)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2455)
>  ~[ignite-core-2.0.0.jar:2.0.0]
> ... 13 more
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_92]
> at 

[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6526:

Component/s: documentation

> Ignite 2.x capacity planning guide
> --
>
> Key: IGNITE-6526
> URL: https://issues.apache.org/jira/browse/IGNITE-6526
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
> Fix For: 2.3
>
>
> Current capacity planning guide [1] is too high level and should be 
> elaborated considering durable memory's internals:
> - memory pages overhead.
> - per-entry overhead 
> (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
> - space occupied for indexing needs.
> - free lists
> - etc.
> The page has to include estimates for the Ignite Native Persistence:
> - entry size and its overheads.
> - index size and overheads.
> - data files overheads.
> - estimated WAL size and how to shrink it basing on checkpointing settings.
> [1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6625) JDBC thin: support SSL connection to Ignite node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6625:

Fix Version/s: (was: 2.3)
   2.4

> JDBC thin: support SSL connection to Ignite node
> 
>
> Key: IGNITE-6625
> URL: https://issues.apache.org/jira/browse/IGNITE-6625
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.2
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> SSL connection must be supported for JDBC thin driver.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6580) Cluster can fail during concurrent re-balancing and cache destruction

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6580:

Fix Version/s: (was: 2.3)

> Cluster can fail during concurrent re-balancing and cache destruction
> -
>
> Key: IGNITE-6580
> URL: https://issues.apache.org/jira/browse/IGNITE-6580
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.2
>Reporter: Mikhail Cherkasov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> The following exceptions can be abserved during concurrent re-balancing and 
> cache destruction:
> 1.
> {noformat}
> [00:01:27,135][ERROR][sys-#4375%null%][GridDhtPreloader] Partition eviction 
> failed, this can cause grid hang.
> org.apache.ignite.IgniteException: Runtime failure on search row: 
> Row@6be51c3d[ **REMOVED SENSITIVE INFORMATION** ]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1787)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.remove(BPlusTree.java:1578)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.remove(H2TreeIndex.java:226)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:523)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:416)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:574)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2172)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1462)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1425)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:951)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:809)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6629)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-2.1.4.jar:2.1.4]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> Caused by: java.lang.IllegalStateException: Item not found: 1
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.findIndirectItemIndex(DataPageIO.java:346)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:446)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> 

[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6526:

Labels:   (was: documentation)

> Ignite 2.x capacity planning guide
> --
>
> Key: IGNITE-6526
> URL: https://issues.apache.org/jira/browse/IGNITE-6526
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
> Fix For: 2.3
>
>
> Current capacity planning guide [1] is too high level and should be 
> elaborated considering durable memory's internals:
> - memory pages overhead.
> - per-entry overhead 
> (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
> - space occupied for indexing needs.
> - free lists
> - etc.
> The page has to include estimates for the Ignite Native Persistence:
> - entry size and its overheads.
> - index size and overheads.
> - data files overheads.
> - estimated WAL size and how to shrink it basing on checkpointing settings.
> [1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6580) Cluster can fail during concurrent re-balancing and cache destruction

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6580:

Fix Version/s: 2.4

> Cluster can fail during concurrent re-balancing and cache destruction
> -
>
> Key: IGNITE-6580
> URL: https://issues.apache.org/jira/browse/IGNITE-6580
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.2
>Reporter: Mikhail Cherkasov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> The following exceptions can be abserved during concurrent re-balancing and 
> cache destruction:
> 1.
> {noformat}
> [00:01:27,135][ERROR][sys-#4375%null%][GridDhtPreloader] Partition eviction 
> failed, this can cause grid hang.
> org.apache.ignite.IgniteException: Runtime failure on search row: 
> Row@6be51c3d[ **REMOVED SENSITIVE INFORMATION** ]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1787)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.remove(BPlusTree.java:1578)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.remove(H2TreeIndex.java:226)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:523)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:416)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:574)
>  ~[ignite-indexing-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2172)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1462)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1425)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:951)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:809)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6629)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
>  [ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-2.1.4.jar:2.1.4]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> Caused by: java.lang.IllegalStateException: Item not found: 1
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.findIndirectItemIndex(DataPageIO.java:346)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:446)
>  ~[ignite-core-2.1.4.jar:2.1.4]
>   at 
> 

[jira] [Updated] (IGNITE-6618) Web console: Do not show client nodes in node selection modal

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6618:

Fix Version/s: (was: 2.3)
   2.4

> Web console: Do not show client nodes in node selection modal
> -
>
> Key: IGNITE-6618
> URL: https://issues.apache.org/jira/browse/IGNITE-6618
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Pavel Konstantinov
> Fix For: 2.4
>
>
> I tried to 'Execute on Selected Node' the following query
> {code}
> SELECT c.id, d.id, p.id, p.salary 
> FROM "c_partitioned".City c
> inner join "c_partitioned".Department d
> on c.id=d.CTYID 
> inner join "c_partitioned".Person p
> on d.id=p.depID and p.salary > 5000
> inner join "c_partitioned".PersonBonus pb
> on p.id=pb.perID and pb.COUNT  < 5000
> where exists (select * from "c_partitioned".Person where rank > 0)
> {code}
> and selected a client node in the list of nodes
> and got exception
> {code}
> General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, 
> d.id, p.id, p.salary 
>  FROM "c_partitioned".City c
>  inner join "c_partitioned".Department d
>  on c.id=d.CTYID 
>  inner join "c_partitioned".Person p
>  on d.id=p.depID and p.salary > 5000
>  inner join "c_partitioned".PersonBonus pb
>  on p.id=pb.perID and pb.COUNT < 5000
>  where exists (select * from "c_partitioned".Person where rank > 0) 
> [5-195]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6526:

Labels: documentation  (was: documentaion)

> Ignite 2.x capacity planning guide
> --
>
> Key: IGNITE-6526
> URL: https://issues.apache.org/jira/browse/IGNITE-6526
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>  Labels: documentation
> Fix For: 2.3
>
>
> Current capacity planning guide [1] is too high level and should be 
> elaborated considering durable memory's internals:
> - memory pages overhead.
> - per-entry overhead 
> (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
> - space occupied for indexing needs.
> - free lists
> - etc.
> The page has to include estimates for the Ignite Native Persistence:
> - entry size and its overheads.
> - index size and overheads.
> - data files overheads.
> - estimated WAL size and how to shrink it basing on checkpointing settings.
> [1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6308) BaselineTopology is created on first cluster activation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6308:

Fix Version/s: (was: 2.3)
   2.4

> BaselineTopology is created on first cluster activation
> ---
>
> Key: IGNITE-6308
> URL: https://issues.apache.org/jira/browse/IGNITE-6308
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: IEP-4, Phase-1
> Fix For: 2.4
>
>
> h2. Use Cases
> * User starts up and activates brand-new grid. On activation BaselineTopology 
> is created and persisted.
> * User starts up some (not all) nodes of old grid (BLT might be already 
> presented on them) and activates new smaller grid.
> BLT is recreated with fewer number of nodes and replaces previous BLT in 
> persistent storage.
> * User starts nodes of old grid (each node already has a BLT available 
> locally). When all nodes presented in BLT are started grid is activated 
> automatically.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6464) ignite.active() == true, but ignite.utilityCache() may return null

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6464:

Fix Version/s: (was: 2.3)
   2.4

> ignite.active() == true, but ignite.utilityCache() may return null
> --
>
> Key: IGNITE-6464
> URL: https://issues.apache.org/jira/browse/IGNITE-6464
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Kuznetsov
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6423) PDS could be corrupted if partition have been evicted and owned again

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6423:

Fix Version/s: (was: 2.3)
   2.4

> PDS could be corrupted if partition have been evicted and owned again
> -
>
> Key: IGNITE-6423
> URL: https://issues.apache.org/jira/browse/IGNITE-6423
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.4
>
>
> So, what is going on? 
> Partition had been changed, its pages had been put to checkpoint pages.
> After it partition was evicted, checkpoint started.
> We are allocating a page and because it's already in checkpoint we copy the 
> empty page to copy it on disk.
> If we restart right now we will read the empty page from disk. Therefore 
> assertion error would be thrown etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6612) Wrap ack methods in their own class

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6612:

Fix Version/s: (was: 2.3)
   2.4

> Wrap ack methods in their own class
> ---
>
> Key: IGNITE-6612
> URL: https://issues.apache.org/jira/browse/IGNITE-6612
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: None
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
>  Labels: refactor
> Fix For: 2.4
>
>
> Several methods in IgniteKernal implement similar functions: “ackAsciiLogo”, 
> “ackConfigUrl”, “ackDaemon”, “ackOsInfo”, “ackLanguageRuntime”, 
> “ackRemoteManagement”, “ackVmArguments”, “ackClassPaths”, 
> “ackSystemProperties”, “ackEnviromentVariables”, “ackMemoryConfiguration”, 
> “ackCacheConfiguration”, “ackP2PConfiguration”, “ackRebalanceConfiguration”. 
> These methods should be placed in separate class “AckVariousInformation” and 
> called from the class instance in IgniteKernal.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6771) Insert query failed if kye field is present in value fields

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6771:

Fix Version/s: (was: 2.3)
   2.4

> Insert query failed if kye field is present in value fields
> ---
>
> Key: IGNITE-6771
> URL: https://issues.apache.org/jira/browse/IGNITE-6771
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Affects Versions: 2.2
>Reporter: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> I'm imported model from DB where a table hasn't a primary key.
> Then using web console I added key field manually (the first field in the 
> table).
> Note: 
> {code}
> 
> {code}
> Then I generated the project and started one server node.
> I'm opened query in web console and tried to execute insert query
> and got an error
> {code}
> ...duplicate field
> {code}
> The issue disappeared only after I removed the same field from value fields.
> I guess it is possible to handle that automatically in POJO logic.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6531) Need to add a 'required' field to the SpringResource annotation.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6531:

Fix Version/s: (was: 2.3)
   2.4

> Need to add a 'required' field to the SpringResource annotation.
> 
>
> Key: IGNITE-6531
> URL: https://issues.apache.org/jira/browse/IGNITE-6531
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: joungdal.nam
>Assignee: joungdal.nam
>Priority: Minor
>  Labels: easyfix, newbie
> Fix For: 2.4
>
>
> In my test environment, only the client is used(setForceServerMode(true)). 
> Operating environments use clients and servers.
> Sometimes Injection is not required in the test environment.
> NoSuchBeanDefinitionException is not generated by specifying a value of false.
> public @interface SpringResource {
>   
>   /**
>* Declares whether the annotated dependency is required.
>* Defaults to {@code true}.
>*/
>   boolean required() default true;
> ..
> if (!StringUtils.isEmpty(beanName)) {
>   try {
>   bean = springCtx.getBean(beanName);
>   } catch(NoSuchBeanDefinitionException ne) {
>   if(annotation.required()) {
>   throw ne;
>   }
>   }
> }
> else {
>   try {
>   bean = springCtx.getBean(beanCls);
>   } catch(NoSuchBeanDefinitionException ne) {
>   if(annotation.required()) {
>   throw ne;
>   }
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6752) JDBC thin: connection property refactoring

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6752:

Fix Version/s: (was: 2.3)
   2.4

> JDBC thin: connection property refactoring
> --
>
> Key: IGNITE-6752
> URL: https://issues.apache.org/jira/browse/IGNITE-6752
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: jdbc
>Affects Versions: 2.2
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> The issues IGNITE-6140 and IGNITE-6625 have to connection properties 
> refactoring.
> Otherwise the logic to work with connection properties is separated between 
> several classes.
> Also, SSL implementation for JDB client adds many new properties.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6766) RC check automation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6766:

Fix Version/s: (was: 2.3)
   2.4

> RC check automation
> ---
>
> Key: IGNITE-6766
> URL: https://issues.apache.org/jira/browse/IGNITE-6766
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>Assignee: Oleg Ostanin
>  Labels: teamcity
> Fix For: 2.4
>
>
> Need to add task which downloads RC from 
> https://dist.apache.org/repos/dist/dev/ignite/X.Y.Z-rcK
> and checks that sha1, md5, gpg, src(license, build)) are ok.
> Also it should check that all Jira issues are resolved or closed for this 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6444) Validate that copyOnRead flag is configured with on-heap cache enabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6444:

Fix Version/s: (was: 2.3)
   2.4

> Validate that copyOnRead flag is configured with on-heap cache enabled
> --
>
> Key: IGNITE-6444
> URL: https://issues.apache.org/jira/browse/IGNITE-6444
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Alexey Goncharuk
>Assignee: Roman Shtykh
>  Labels: usability
> Fix For: 2.4
>
>
> Link to the user-list discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-CopyOnRead-Problem-td17009.html
> It makes sense to validate the flag and print out a warning if on-heap cache 
> is disabled. I do not think that we should prevent node from startup because 
> this may break existing deployments.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6502:

Fix Version/s: (was: 2.3)
   2.4

> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: usability
> Fix For: 2.4
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested and another issue has been filed - 
> https://issues.apache.org/jira/browse/IGNITE-6503.
> For now it seems to be pretty handy just to have warning on node start:
> {noformat}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6500) POJO fields of java wrapper type are not retaining null values from Cassandra persistent store, while using ignite's CassandraCacheStoreFactory

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6500:

Fix Version/s: (was: 2.3)
   2.4

> POJO fields of java wrapper type are not retaining null values from Cassandra 
> persistent store, while using ignite's CassandraCacheStoreFactory
> ---
>
> Key: IGNITE-6500
> URL: https://issues.apache.org/jira/browse/IGNITE-6500
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Yashasvi Kotamraju
>Assignee: Yashasvi Kotamraju
>Priority: Minor
> Fix For: 2.4
>
>
> While using  ignite's CassandraCacheStoreFactory(part of 
> ignite-cassandra-store.jar) as cacheStoreFactory for a cache, if a POJO field 
> is of wrapper class type, and the column value mapped in Cassandra persistent 
> store is null then the POJO field is getting set to default primitive type 
> instead of null.
> For Example: Assume a table 'person' in a Cassandra persistent store with the 
> following structure and data.
> *table person:*
> *column*person_no(int)phno(text) address(text)  age(int)  
> name(text)   
> *data* 1 12353   null 
>  nullyash 
> person_no is the PRIMARY_KEY.
> This table is mapped to person POJO  for ignite cache.
> public class person{
>   private int person_no;
>   private String name;
>   private Integer age=null;
>   private String phno;
>   private String address;
> .getters and setters etc..
> }
> Now we load the row from Cassandra into ignite cache using cache.get(1) or 
> cache.load(..) And we are using ignite's CassandraCacheStoreFactory for this 
> cache.
> Let person p1 = cache.get(1);
> now p1.getName returns "yash", p1.getAddress returns null.
> But  p1.getAge returns 0 instead of null. It is expected null value since the 
> value is null in Cassandra persistent store.
> Hence if the value is 0 for the age field there is no way differentiate if it 
> was null or it was actually 0. The similar problem exists for other wrapper 
> types -> Long, Float, Double, Boolean.
> This problem cause is as follows. 
> In 
> org.apache.ignite.cache.store.cassandra.persistence.PojoField.setValueFromRow(..)
>  method first the Cassandra field value is obtained by using the method 
> PropertyMappingHelper.getCassandraColumnValue(..). This method calls DataStax 
> Driver methods Row.getInt() or Row.getFloat() or Row.getDouble() etc.. 
> depending upon the column. This value obtained from this method is then set 
> to the respective POJO field. But According to Datastax documentation getInt 
> returns 0 if column value is null and similarly getLong returns 0L , 
> getDouble return 0.0 etc. Hence PropertyMappingHelper. 
> getCassandraColumnValue returns 0 or 0L or 0.0 or false even if the value is 
> null. And then this value is set to the wrapper type POJO fields. The problem 
> only persists with the primitive data types in Cassandra mapped to wrapper 
> type fields in POJO. For other types like String , Date etc.. the null values 
> are retained in the POJO fields. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5795:


GitHub user kukushal opened a pull request:

https://github.com/apache/ignite/pull/2952

fix for IGNITE-5795



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-5795-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2952.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2952


commit 83b0fa59804442909a84e9419d6a3b195c3b642b
Author: Alexey Kukushkin 
Date:   2017-10-31T13:56:11Z

fix for IGNITE-5795




> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Alexey Kukushkin
>  Labels: usability
> Fix For: 2.4
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
> will force registering key.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5979:

Fix Version/s: (was: 2.3)
   2.4

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vadim Opolski
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6015:

Fix Version/s: (was: 2.3)
   2.4

> Test fail in Ignite Cache 2: 
> GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform 
> --
>
> Key: IGNITE-6015
> URL: https://issues.apache.org/jira/browse/IGNITE-6015
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> {code}
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testGetAndTransform, timeout=30]
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
> at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
> at 
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6005:

Fix Version/s: (was: 2.3)
   2.4

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> 

[jira] [Updated] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5960:

Fix Version/s: (was: 2.3)
   2.4

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
> -
>
> Key: IGNITE-5960
> URL: https://issues.apache.org/jira/browse/IGNITE-5960
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4
>
>
> According to [TC 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E]
>  test is flaky.
> It is possible to reproduce it locally, sample run shows 9 failed tests out 
> of 30 overall executed.
> Test fails with jUnit assertion check: 
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :1
> Actual   :0
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5789:

Fix Version/s: (was: 2.3)
   2.4

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>Assignee: vk
> Fix For: 2.4
>
> Attachments: ClientReconnectAfterClusterRestartTest.java
>
>
> User with this problem on SO:
> https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2092) Ignite does not recognize the right number of CPU cores when running under Docker

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2092:

Fix Version/s: (was: 2.3)
   2.4

> Ignite does not recognize the right number of CPU cores when running under 
> Docker
> -
>
> Key: IGNITE-2092
> URL: https://issues.apache.org/jira/browse/IGNITE-2092
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Maxim Neverov
>  Labels: newbie
> Fix For: 2.4
>
> Attachments: ignite_boot_log.txt
>
>
> Run Ignite under a Docker container.
> Limit Ignite from using all CPUs by way of Docker settings (which internally 
> uses Linux CGROUPS). 
> Ignite will still report that all available CPUs are used ignoring Docker 
> settings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5302:

Fix Version/s: (was: 2.3)
   2.4

> Empty LOST partition may be used as OWNING after resetting lost partitions
> --
>
> Key: IGNITE-5302
> URL: https://issues.apache.org/jira/browse/IGNITE-5302
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Dmitriy Sorokin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.4
>
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in 
> ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is 
> declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are 
> reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary 
> node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not 
> only to P/B nodes with real value but also to the node where that partition 
> existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition 
> counter is increased for empty partition in LOST state which looks wrong



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5357) Replicated cache reads load balancing.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5357:

Fix Version/s: (was: 2.3)
   2.4

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Mikhail Lipkovich
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-602:
---
Fix Version/s: (was: 2.4)

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-898) Ignite does not starts from folder which name contains space

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-898:
---
Fix Version/s: (was: 2.3)

> Ignite does not starts from folder which name contains space
> 
>
> Key: IGNITE-898
> URL: https://issues.apache.org/jira/browse/IGNITE-898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Aleksei Zaitsev
>Priority: Trivial
> Fix For: 2.4
>
>
> Observed:
> In case folder name contains space character Ignite node cannot be started.
> Expected:
> Ingine node should be startable even when folder name contains space 
> character.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-898) Ignite does not starts from folder which name contains space

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-898:
---
Fix Version/s: 2.4

> Ignite does not starts from folder which name contains space
> 
>
> Key: IGNITE-898
> URL: https://issues.apache.org/jira/browse/IGNITE-898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Aleksei Zaitsev
>Priority: Trivial
> Fix For: 2.4
>
>
> Observed:
> In case folder name contains space character Ignite node cannot be started.
> Expected:
> Ingine node should be startable even when folder name contains space 
> character.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-602:
---
Fix Version/s: 2.4

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6800) С++: Continuous Query example:extra lines in log if run example with 3 standalone node

[Irina Zaporozhtseva (JIRA)]

Irina Zaporozhtseva created IGNITE-6800:
---

 Summary: С++: Continuous Query example:extra lines in log if run 
example with 3 standalone node
 Key: IGNITE-6800
 URL: https://issues.apache.org/jira/browse/IGNITE-6800
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: platforms
Affects Versions: 2.3
Reporter: Irina Zaporozhtseva


С++: Continuous Query example:extra lines in log if run example with 3 
standalone node

without standalone node or with 1 standalone node :

{code}
>>> Cache continuous query example started.

Queried entry [key=20, val=20]
Queried entry [key=21, val=21]
Queried entry [key=22, val=22]
Queried entry [key=23, val=23]
Queried entry [key=24, val=24]

>>> Press 'Enter' to continue...
{code}

with 3 standalone nodes :

{code}
>>> Cache continuous query example started.

Queried entry [key=20, val=20]
Queried entry [key=21, val=21]
Queried entry [key=22, val=22]
Queried entry [key=23, val=23]
Queried entry [key=24, val=24]
Queried entry [key=25, val=25]
Queried entry [key=26, val=26]
Queried entry [key=27, val=27]
Queried entry [key=28, val=28]

>>> Press 'Enter' to continue...
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6800) С++: Continuous Query example: extra lines in log if run example with 3 standalone node

[Irina Zaporozhtseva (JIRA)]

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

Irina Zaporozhtseva updated IGNITE-6800:

Summary: С++: Continuous Query example: extra lines in log if run example 
with 3 standalone node  (was: С++: Continuous Query example:extra lines in log 
if run example with 3 standalone node)

> С++: Continuous Query example: extra lines in log if run example with 3 
> standalone node
> ---
>
> Key: IGNITE-6800
> URL: https://issues.apache.org/jira/browse/IGNITE-6800
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>  Labels: C++
>
> С++: Continuous Query example: extra lines in log if run example with 3 
> standalone nodes
> without standalone node or with 1 standalone node :
> {code}
> >>> Cache continuous query example started.
> Queried entry [key=20, val=20]
> Queried entry [key=21, val=21]
> Queried entry [key=22, val=22]
> Queried entry [key=23, val=23]
> Queried entry [key=24, val=24]
> >>> Press 'Enter' to continue...
> {code}
> with 3 standalone nodes :
> {code}
> >>> Cache continuous query example started.
> Queried entry [key=20, val=20]
> Queried entry [key=21, val=21]
> Queried entry [key=22, val=22]
> Queried entry [key=23, val=23]
> Queried entry [key=24, val=24]
> Queried entry [key=25, val=25]
> Queried entry [key=26, val=26]
> Queried entry [key=27, val=27]
> Queried entry [key=28, val=28]
> >>> Press 'Enter' to continue...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6800) С++: Continuous Query example:extra lines in log if run example with 3 standalone node

[Irina Zaporozhtseva (JIRA)]

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

Irina Zaporozhtseva updated IGNITE-6800:

Description: 
С++: Continuous Query example: extra lines in log if run example with 3 
standalone nodes

without standalone node or with 1 standalone node :

{code}
>>> Cache continuous query example started.

Queried entry [key=20, val=20]
Queried entry [key=21, val=21]
Queried entry [key=22, val=22]
Queried entry [key=23, val=23]
Queried entry [key=24, val=24]

>>> Press 'Enter' to continue...
{code}

with 3 standalone nodes :

{code}
>>> Cache continuous query example started.

Queried entry [key=20, val=20]
Queried entry [key=21, val=21]
Queried entry [key=22, val=22]
Queried entry [key=23, val=23]
Queried entry [key=24, val=24]
Queried entry [key=25, val=25]
Queried entry [key=26, val=26]
Queried entry [key=27, val=27]
Queried entry [key=28, val=28]

>>> Press 'Enter' to continue...
{code}

  was:
С++: Continuous Query example:extra lines in log if run example with 3 
standalone node

without standalone node or with 1 standalone node :

{code}
>>> Cache continuous query example started.

Queried entry [key=20, val=20]
Queried entry [key=21, val=21]
Queried entry [key=22, val=22]
Queried entry [key=23, val=23]
Queried entry [key=24, val=24]

>>> Press 'Enter' to continue...
{code}

with 3 standalone nodes :

{code}
>>> Cache continuous query example started.

Queried entry [key=20, val=20]
Queried entry [key=21, val=21]
Queried entry [key=22, val=22]
Queried entry [key=23, val=23]
Queried entry [key=24, val=24]
Queried entry [key=25, val=25]
Queried entry [key=26, val=26]
Queried entry [key=27, val=27]
Queried entry [key=28, val=28]

>>> Press 'Enter' to continue...
{code}


> С++: Continuous Query example:extra lines in log if run example with 3 
> standalone node
> --
>
> Key: IGNITE-6800
> URL: https://issues.apache.org/jira/browse/IGNITE-6800
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>  Labels: C++
>
> С++: Continuous Query example: extra lines in log if run example with 3 
> standalone nodes
> without standalone node or with 1 standalone node :
> {code}
> >>> Cache continuous query example started.
> Queried entry [key=20, val=20]
> Queried entry [key=21, val=21]
> Queried entry [key=22, val=22]
> Queried entry [key=23, val=23]
> Queried entry [key=24, val=24]
> >>> Press 'Enter' to continue...
> {code}
> with 3 standalone nodes :
> {code}
> >>> Cache continuous query example started.
> Queried entry [key=20, val=20]
> Queried entry [key=21, val=21]
> Queried entry [key=22, val=22]
> Queried entry [key=23, val=23]
> Queried entry [key=24, val=24]
> Queried entry [key=25, val=25]
> Queried entry [key=26, val=26]
> Queried entry [key=27, val=27]
> Queried entry [key=28, val=28]
> >>> Press 'Enter' to continue...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6765) ODBC: Error when closing executed DML statement.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6765:


GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/2949

IGNITE-6765: Added ODBC test for closing cursor after DML execution



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6765

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2949.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2949


commit dd7e9e5d69c09f2a781fc177d12c3a6a47a5af1a
Author: Igor Sapego 
Date:   2017-10-31T12:08:07Z

IGNITE-6765: Added test




> ODBC: Error when closing executed DML statement.
> 
>
> Key: IGNITE-6765
> URL: https://issues.apache.org/jira/browse/IGNITE-6765
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: odbc
>Affects Versions: 2.2
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 2.4
>
>
> There is an error, on attempt to close executed DML statement:
> {code}
> SQLRETURN ret = SQLExecDirect(stmt, "UPDATE Person SET salary=1000 WHERE 
> _key=2" , SQL_NTS);
> assert(ret == SQL_SUCCESS);
> ret = SQLFreeStmt(stmt, SQL_CLOSE);
> assert(ret == SQL_SUCCESS);
> {code}
> The error message is "Failed to close statement: HY000: Failed to find query 
> with ID: "



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6511:


Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/2925


> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>Assignee: Igor Sapego
>  Labels: usability
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {{SqlGetDiagRec()}} returns wrong 
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead 
> of {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-6690.
--
Resolution: Fixed

> DiscoverySpi: Clientmode Ignite should not fail on handshake errors
> ---
>
> Key: IGNITE-6690
> URL: https://issues.apache.org/jira/browse/IGNITE-6690
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: discovery
> Fix For: 2.4
>
>
> Ignite in Client mode should not fail on handshake unmarshalling errors. It 
> should go to the next IP/port from ipFinder list
> http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6690:
--

[~alexey.tank2],
Thank you for your contribution. I've merged the changes to master.

> DiscoverySpi: Clientmode Ignite should not fail on handshake errors
> ---
>
> Key: IGNITE-6690
> URL: https://issues.apache.org/jira/browse/IGNITE-6690
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: discovery
> Fix For: 2.4
>
>
> Ignite in Client mode should not fail on handshake unmarshalling errors. It 
> should go to the next IP/port from ipFinder list
> http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6690:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2923


> DiscoverySpi: Clientmode Ignite should not fail on handshake errors
> ---
>
> Key: IGNITE-6690
> URL: https://issues.apache.org/jira/browse/IGNITE-6690
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: discovery
> Fix For: 2.4
>
>
> Ignite in Client mode should not fail on handshake unmarshalling errors. It 
> should go to the next IP/port from ipFinder list
> http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6357) ODBC: support multiple SQL statements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6357:


Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/2924


> ODBC: support multiple SQL statements
> -
>
> Key: IGNITE-6357
> URL: https://issues.apache.org/jira/browse/IGNITE-6357
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> See IGNITE-6046. We need to implement the same thing for ODBC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-6690:
--

TeamCity tests passed

> DiscoverySpi: Clientmode Ignite should not fail on handshake errors
> ---
>
> Key: IGNITE-6690
> URL: https://issues.apache.org/jira/browse/IGNITE-6690
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: discovery
> Fix For: 2.4
>
>
> Ignite in Client mode should not fail on handshake unmarshalling errors. It 
> should go to the next IP/port from ipFinder list
> http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6788) Ignite WAL reader fails on Tx marker record for persistent store with new style folder naming

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-6788 at 10/31/17 10:23 AM:
---

https://ci.ignite.apache.org/viewLog.html?buildId=920566;
https://github.com/apache/ignite/pull/2945
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-386


was (Author: dpavlov):
https://ci.ignite.apache.org/viewQueued.html?itemId=920566
https://github.com/apache/ignite/pull/2945
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-386

> Ignite WAL reader fails on Tx marker record for persistent store with new 
> style folder naming
> -
>
> Key: IGNITE-6788
> URL: https://issues.apache.org/jira/browse/IGNITE-6788
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.4
>
>
> After chaning paths generation and consistent ID to be UUID
> also after introduction of Tx Markers
> WAL records iterator begin to fail to deserialize consistentID from TX record 
> in mode when binary_meta and marshaller cache paths are not provided
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.TxRecordSerializer.readConsistentId(TxRecordSerializer.java:211)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.TxRecordSerializer.readTxRecord(TxRecordSerializer.java:114)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.readRecord(RecordDataV1Serializer.java:812)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer$1.readWithHeaders(RecordV1Serializer.java:96)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readWithCrc(RecordV1Serializer.java:230)
>   ... 18 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6313) transaction hangs while node left cluster

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-6313:
---
Attachment: TxDeadLockOnNodeRestart.java

[~ilantukh] tpre + trun initial reproducer, repeated successfully under windows 
OS and Ctrl+C grid kill. Additionally i wrote one more reproducer, take a look 
plz.

> transaction hangs while node left cluster
> -
>
> Key: IGNITE-6313
> URL: https://issues.apache.org/jira/browse/IGNITE-6313
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Stanilovsky Evgeny
>Assignee: Ilya Lantukh
> Attachments: TxDeadLockOnNodeRestart.java, 
> TxDeadLockOnNodeRestart.java, coord.stack, coord.tar.gz, node.stack, 
> node.tar.gz, run.py, tpre.tar.gz, trun.tar.gz
>
>
> in attached reproducer there are 2 projects, 
> first - tpre simple fills cache
> second - trun concurrently update cache values.
> expected behavior 100 or sometimes 99 numbers in output, but after several 
> grid autorestart python script we found grid have no active transactions ...
> try to find time for pure ignite reproducer, but for now it need be run like :
> sequentially start:
> *java -jar tpre-1.0-SNAPSHOT-jar-with-dependencies.jar 1000
> java -jar trun-1.0-SNAPSHOT-jar-with-dependencies.jar 1000 20 1
> run.py*
> console with *trun* process will soon output something like : BBB that 
> signals no transactions found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (IGNITE-6313) transaction hangs while node left cluster

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reopened IGNITE-6313:


> transaction hangs while node left cluster
> -
>
> Key: IGNITE-6313
> URL: https://issues.apache.org/jira/browse/IGNITE-6313
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Stanilovsky Evgeny
>Assignee: Ilya Lantukh
> Attachments: TxDeadLockOnNodeRestart.java, 
> TxDeadLockOnNodeRestart.java, coord.stack, coord.tar.gz, node.stack, 
> node.tar.gz, run.py, tpre.tar.gz, trun.tar.gz
>
>
> in attached reproducer there are 2 projects, 
> first - tpre simple fills cache
> second - trun concurrently update cache values.
> expected behavior 100 or sometimes 99 numbers in output, but after several 
> grid autorestart python script we found grid have no active transactions ...
> try to find time for pure ignite reproducer, but for now it need be run like :
> sequentially start:
> *java -jar tpre-1.0-SNAPSHOT-jar-with-dependencies.jar 1000
> java -jar trun-1.0-SNAPSHOT-jar-with-dependencies.jar 1000 20 1
> run.py*
> console with *trun* process will soon output something like : BBB that 
> signals no transactions found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6669) CacheStoreSessionListener#onSessionStart() #onSessionEnd() methods are called by GridCacheStoreManagerAdapter even if a store operation should not be performed.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6669:


.NET changes look ok to me.

> CacheStoreSessionListener#onSessionStart() #onSessionEnd() methods are called 
> by GridCacheStoreManagerAdapter even if a store operation should not be 
> performed.
> 
>
> Key: IGNITE-6669
> URL: https://issues.apache.org/jira/browse/IGNITE-6669
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Affects Versions: 1.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
> Attachments: Reproducer.java
>
>
> In the case of transactional cache, which is configured using {{CacheStore}} 
> and {{CacheJdbcStoreSessionListener}}, every update triggers 
> {{CacheStoreSessionListener # onSessionStart()}} that results in creating the 
> connection to an underlying database, even if read-through and write-through 
> modes are disabled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6799) Check of starvation in striped thread pool

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-6799:
-

 Summary: Check of starvation in striped thread pool
 Key: IGNITE-6799
 URL: https://issues.apache.org/jira/browse/IGNITE-6799
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Reporter: Vladislav Pyatkov


We have got false alarm like:

{noformat}
2017-10-30 14:01:40.308[WARN 
][grid-timeout-worker-#63%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.util.typedef.G]
 >>> Possible starvation in striped pool. 
2017-10-30 13:56:41.538[WARN 
][grid-timeout-worker-#63%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.util.typedef.G]
 >>> Possible starvation in striped pool. 
2017-10-30 13:46:40.488[WARN 
][grid-timeout-worker-#63%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.util.typedef.G]
 >>> Possible starvation in striped pool. 
2017-10-30 13:37:45.481[WARN 
][grid-timeout-worker-#63%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.util.typedef.G]
 >>> Possible starvation in striped pool. 
{noformat}

It will be on checkpoint usually, but that is false triggering. Because thread 
have not been active long time, but got active recently.

We should save last active state on stripe like it done with completedCntrs and 
rewrite condition:

{code}
completedCntrs[i] != -1 &&
completedCntrs[i] == completedCnt &&
actives[i] == active &&
active
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6217:
--

[~vozerov], the comments are fixed. Please take a look at the changes.

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6717) Hashcode/equals is not needed for custom keys serialized into a binary form

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6717:


[~dmagda] https://apacheignite-net.readme.io/v2.3/docs/serialization page 
updated.

> Hashcode/equals is not needed for custom keys serialized into a binary form
> ---
>
> Key: IGNITE-6717
> URL: https://issues.apache.org/jira/browse/IGNITE-6717
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> It turns out that hashCode/equals implementation is no longer required for 
> custom complex keys if a key is serialized to the binary form. Discussed here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-3-troubles-with-key-value-APIs-in-the-cluster-configured-with-DDL-td23501.html#a23506
> The marshaller calculates the hash code automatically. This info has to be 
> added to the binary marshaller page:
> https://apacheignite.readme.io/docs/binary-marshaller



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6357) ODBC: support multiple SQL statements

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6357:
--

[~isapego], looks good.

> ODBC: support multiple SQL statements
> -
>
> Key: IGNITE-6357
> URL: https://issues.apache.org/jira/browse/IGNITE-6357
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> See IGNITE-6046. We need to implement the same thing for ODBC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6798) Ignite start without WAL with no exceptions

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6798:


 Summary: Ignite start without WAL with no exceptions
 Key: IGNITE-6798
 URL: https://issues.apache.org/jira/browse/IGNITE-6798
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Critical


Ignite start without any WAL log files. Step to reproduce:
1) Start node with persistence (WAL_MODE != NONE)
2) Create cache with some data
3) Stop node
4) Delete WAL
5) Start node
Expected:
If last checkpoint was finished - start with error in log
If last checkpoint wasn't finished - LFS can be corrupted so, maybe, we 
shouldn't start at all (with some message like "if you really wan't to start 
with possible corrupt database just remove last CP_start marker)
Actual:
Start without any errors/warnings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6701) Do not deserialize previous value during indexes update

[Roman Kondakov (JIRA)]

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

Roman Kondakov reassigned IGNITE-6701:
--

Assignee: Roman Kondakov

> Do not deserialize previous value during indexes update
> ---
>
> Key: IGNITE-6701
> URL: https://issues.apache.org/jira/browse/IGNITE-6701
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> In GridH2Table.doUpdate all indexes are updated using BPlusTree.put method 
> which deserializes previous value, actually previous value is already 
> available in GridQueryProcessor.store/remove methods. Need try to change 
> GridH2Table.doUpdate to use BPlusTree.putx instead of BPlusTree.put.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6795) Web console: Make default file name for saving scan results more informative

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6795 at 10/31/17 6:56 AM:


Please test in branch ignite-6795.
Also test export in Demo mode.


was (Author: kuaw26):
Please test in branch ignite-6795.

> Web console: Make default file name for saving scan results more informative
> 
>
> Key: IGNITE-6795
> URL: https://issues.apache.org/jira/browse/IGNITE-6795
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently file name is '' + '-all' in case if I want to save all 
> result set. (export all)
> I suggest to use 'scan--all'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6795) Web console: Make default file name for saving scan results more informative

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6795:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Please test in branch ignite-6795.

> Web console: Make default file name for saving scan results more informative
> 
>
> Key: IGNITE-6795
> URL: https://issues.apache.org/jira/browse/IGNITE-6795
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently file name is '' + '-all' in case if I want to save all 
> result set. (export all)
> I suggest to use 'scan--all'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)