[jira] [Updated] (IGNITE-7739) Write about Spring Injection and IgniteSpringBean in documentation

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7739:

Fix Version/s: 2.5

> Write about Spring Injection and IgniteSpringBean in documentation
> --
>
> Key: IGNITE-7739
> URL: https://issues.apache.org/jira/browse/IGNITE-7739
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.5
>
>
> Currently there is no mention of IgniteSpringBean on readme.io
> We have section https://apacheignite.readme.io/docs/resource-injection but 
> it's totally not obvious how to make e.g. SpringResource work, what are 
> pre-requisites.
> Thing is, if Ignite creates Spring context (via Ignition), then Spring 
> injection would work out of box.
> If Spring context creates Ignite as a bean, that bean should be 
> IgniteSpringBean and not Ignite. Otherwise, Spring context and lifecycle 
> would not be visible to Ignite and injection won't work.
> On unrelated note, maybe we need support for Spring Boot already? See 
> https://habrahabr.ru/post/310672/



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

[jira] [Updated] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-7743:

Description: 
Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
{{indexedTypes}}), separate schema for this cache is created. Schema name is 
case sensitive, so to connect to it with JDBC driver, it's required to provide 
the name in quotes. Here is how it looks like in SqlLine:
{noformat}
./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
{noformat}
However, if name is provided without quotes, driver still connects, but then 
fails with a very unclear exception when a query is executed:
{noformat}
./bin/sqlline.sh -u 
jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
This is a huge usability issue. We should disallow connections to schema that 
does not exist, throw exception in this case. Exception should provide proper 
explanation how to connect properly.

  was:
Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
{{indexedTypes}}), separate schema for this cache is created. Schema name is 
case sensitive, so to connect to it with JDBC driver, it's required to provide 
the name in quotes. Here is how it looks like in SqlLine:
{noformat}
./bin/sqlline.sh -u 
jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"{noformat}


> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Updated] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-7743:

Component/s: sql

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Created] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7743:
---

 Summary: JDBC driver allows to connect to non existent schema
 Key: IGNITE-7743
 URL: https://issues.apache.org/jira/browse/IGNITE-7743
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.3
Reporter: Valentin Kulichenko
 Fix For: 2.5


Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
{{indexedTypes}}), separate schema for this cache is created. Schema name is 
case sensitive, so to connect to it with JDBC driver, it's required to provide 
the name in quotes. Here is how it looks like in SqlLine:
{noformat}
./bin/sqlline.sh -u 
jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"{noformat}



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

[jira] [Comment Edited] (IGNITE-3111) .NET: Configure SSL without Spring

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3111 at 2/16/18 8:40 PM:
-

* Removed unused members from ISslContextFactory
* Fixed namespaces
* Removed unused files
* Cleaned up tests
* Added .NET Core (Linux) tests

master: {{600542d53e22a80f8f2f3d6b640fd6d19c015d32}}


was (Author: ptupitsyn):
* Removed unused members from ISslContextFactory
* Fixed namespaces
* Removed unused files
* Cleaned up tests
* Added Linux tests

master: {{600542d53e22a80f8f2f3d6b640fd6d19c015d32}}

> .NET: Configure SSL without Spring
> --
>
> Key: IGNITE-3111
> URL: https://issues.apache.org/jira/browse/IGNITE-3111
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .net
> Fix For: 2.5
>
>
> User should be able to configure SLL in .NET terms without Spring and Java 
> KeyStore.
> See https://apacheignite.readme.io/docs/ssltls.



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

[jira] [Commented] (IGNITE-3111) .NET: Configure SSL without Spring

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3111:


* Removed unused members from ISslContextFactory
* Fixed namespaces
* Removed unused files
* Cleaned up tests
* Added Linux tests

master: {{600542d53e22a80f8f2f3d6b640fd6d19c015d32}}

> .NET: Configure SSL without Spring
> --
>
> Key: IGNITE-3111
> URL: https://issues.apache.org/jira/browse/IGNITE-3111
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .net
> Fix For: 2.5
>
>
> User should be able to configure SLL in .NET terms without Spring and Java 
> KeyStore.
> See https://apacheignite.readme.io/docs/ssltls.



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

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 2/16/18 7:30 PM:
---

[~vkulichenko] , hi !

Sorry, for delay. I have resolved conflicts, and rerun tests.

This new metric test was added : GridCacheNearAtomicMetricsSelfTest, and it 
shows "cache read" metric works incorrect(see testNearRead()). So, my question 
is, should i file a ticket for fixing this test?("cache read" metric in atomic 
cache)

 

Please, review the ticket.

 


was (Author: alexey kuznetsov):
[~vkulichenko] , hi !

Sorry, for delay. I have resolved conflicts, and rerun tests.

This new metric test was added : GridCacheNearAtomicMetricsSelfTest, and it 
shows "cache read" metric works incorrect(see testNearRead()). So, my question 
is, should i file a ticket for fixing this test("cache read" metric in atomic 
cache)

 

Please, review the ticket.

 

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-6846:
--

[~vkulichenko] , hi !

Sorry, for delay. I have resolved conflicts, and rerun tests.

This new metric test was added : GridCacheNearAtomicMetricsSelfTest, and it 
shows "cache read" metric works incorrect(see testNearRead()). So, my question 
is, should i file a ticket for fixing this test("cache read" metric in atomic 
cache)

 

Please, review the ticket.

 

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Comment Edited] (IGNITE-6994) Need to document PartitionLossPolicy

[Prachi Garg (JIRA)]

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

Prachi Garg edited comment on IGNITE-6994 at 2/16/18 7:25 PM:
--

Completed the TODOs. [~dmagda], Please review.


was (Author: pgarg):
Complete the TODOs. [~dmagda], Please review.

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Assigned] (IGNITE-6994) Need to document PartitionLossPolicy

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-6994:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Comment Edited] (IGNITE-7531) SQL: Create data load benchmarks

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov edited comment on IGNITE-7531 at 2/16/18 7:20 PM:
--

10M rows 3 servers, 1 client, 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec

turned on persistence
batched 1000 : 674 sec
copy csv: 169 sec


was (Author: pkouznet):
10M rows 3 servers, 1 client, 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec

turned on persistence
batched 1000 : 674 sec

> SQL: Create data load benchmarks
> 
>
> Key: IGNITE-7531
> URL: https://issues.apache.org/jira/browse/IGNITE-7531
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement a set of data loading benchmarks to better understand 
> how fast Ignite is able to consume data. This task consists of two steps:
> 1) Extend Yardstick capabilities
> 2) Create set of benchmarks
> 1) Yardstick
> Data load benchmark should be executed in single-shot mode: only one 
> iteration, only total execution time is needed, start callback for setup and 
> warmup, stop callback for cleanup. 
> Currently Yardstick cannot do that, so we need to extend it. Possibly, we can 
> control this through new {{boolean BenchmarkDriver.isSingleShot()}} method.
> 2) Benchmarks 
> At first let's focus on thin JDBC driver. The following cases should be 
> executed:
> 2.1) Normal INSERT
> 2.2) Batched INSERT
> 2.3) Streaming INSERT (when IGNITE-7253 is ready)
> 2.4) P. 1-3 with and without dynamically disabled WAL (ALTER TABLE ... 
> NOLOGGING)
> 2.5) P. 1-3 with additional indexes - either created before data load on 
> empty table, or after load on table with data.



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

[jira] [Issue Comment Deleted] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-6846:
-
Comment: was deleted

(was: [~vkulichenko] Hi!

Sorry, for delay. I have resolved conflicts, rerun my new tests locally and 
they passed.
And started Run All 
[tests|https://ci.ignite.apache.org/viewQueued.html?itemId=1047828=queuedBuildOverviewTab])

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Comment Edited] (IGNITE-7531) SQL: Create data load benchmarks

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov edited comment on IGNITE-7531 at 2/16/18 7:10 PM:
--

10M rows 3 servers, 1 client, 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec

turned on persistence
batched 1000 : 674 sec


was (Author: pkouznet):
10M rows 3 servers, 1 client, 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec

> SQL: Create data load benchmarks
> 
>
> Key: IGNITE-7531
> URL: https://issues.apache.org/jira/browse/IGNITE-7531
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement a set of data loading benchmarks to better understand 
> how fast Ignite is able to consume data. This task consists of two steps:
> 1) Extend Yardstick capabilities
> 2) Create set of benchmarks
> 1) Yardstick
> Data load benchmark should be executed in single-shot mode: only one 
> iteration, only total execution time is needed, start callback for setup and 
> warmup, stop callback for cleanup. 
> Currently Yardstick cannot do that, so we need to extend it. Possibly, we can 
> control this through new {{boolean BenchmarkDriver.isSingleShot()}} method.
> 2) Benchmarks 
> At first let's focus on thin JDBC driver. The following cases should be 
> executed:
> 2.1) Normal INSERT
> 2.2) Batched INSERT
> 2.3) Streaming INSERT (when IGNITE-7253 is ready)
> 2.4) P. 1-3 with and without dynamically disabled WAL (ALTER TABLE ... 
> NOLOGGING)
> 2.5) P. 1-3 with additional indexes - either created before data load on 
> empty table, or after load on table with data.



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

[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-7742:
---
Description: 
Some assertions were added in IGNITE-6423 

One of them fires here.

We check for 
assert cctx.shared().database().checkpointLockIsHeldByThread();
but we don't have this lock


{code:java}
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
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:2001)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:748){code}

Simple test fails
[^IgniteDbExpirePolicyTest.java] 



  was:
Some assertions were added in IGNITE-6423 

One of them fires here.

We check for 
assert cctx.shared().database().checkpointLockIsHeldByThread();
but we don't have this lock


{code:java}
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 

[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-7742:
---
Attachment: IgniteDbExpirePolicyTest.java

> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with 
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423 
> One of them fires here.
> We check for 
> assert 
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at 
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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:2001)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}



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

[jira] [Created] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-7742:
--

 Summary: AssertionError in IgniteCacheOffheapManagerImpl when 
Iterate Cache with expire policy and persistence
 Key: IGNITE-7742
 URL: https://issues.apache.org/jira/browse/IGNITE-7742
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.4
Reporter: Sergey Kosarev


Some assertions were added in IGNITE-6423 

One of them fires here.

We check for 
assert cctx.shared().database().checkpointLockIsHeldByThread();
but we don't have this lock


{code:java}
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
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:2001)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:748){code}






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

[jira] [Updated] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-:
---
Description: 
Most recent crashes
https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv
{noformat}
   Ignite PDS 1 [ tests 0 JVM CRASH ] 
 BPlusTreeReuseListPageMemoryImplTest.testEmptyCursors (last started) 
{noformat}

https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1

{noformat}
   Ignite PDS 1 [ tests 0 JVM CRASH ] 
 BPlusTreeReuseListPageMemoryImplTest.testEmptyCursors (last started) 
{noformat}

(older failure
http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)

Stacktrace indicates failure was in ignite code related to B+tree
{noformat}J 34156 C2 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
 (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
J 34634 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
J 34633 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
 (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 35053 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
{noformat}

  was:
Most recent crashes
https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv

https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1

{noformat}
   Ignite PDS 1 [ tests 0 JVM CRASH ] 
 BPlusTreeReuseListPageMemoryImplTest.testEmptyCursors (last started) 
{noformat}

(older failure
http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)

Stacktrace indicates failure was in ignite code related to B+tree
{noformat}J 34156 C2 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
 (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
J 34634 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
J 34633 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
 (81 bytes) @ 0x7f98d2091c94 

[jira] [Commented] (IGNITE-7452) Make Linear SVM example for multi - classification

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7452:


Github user zaleslaw closed the pull request at:

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


> Make Linear SVM example for multi - classification
> --
>
> Key: IGNITE-7452
> URL: https://issues.apache.org/jira/browse/IGNITE-7452
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Minor
>  Labels: ml
> Fix For: 2.5
>
>
> Add an example for Iris dataset 



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

[jira] [Commented] (IGNITE-6280) Cassandra ignores AffinityKeyMapped annotation in parent classes.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-6280:
--

[~irudyak],

The issue here is that Ignite have different behavior for keyA and keyB with 
using AffinityKeyMapped annotation
even if the annotation make no sense in such case.

>From user perspective, incorrect use case should end up with exception.

> Cassandra ignores AffinityKeyMapped annotation in parent classes.
> -
>
> Key: IGNITE-6280
> URL: https://issues.apache.org/jira/browse/IGNITE-6280
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Rudyak
>Priority: Major
> Attachments: CassandraConfigTest.java
>
>
> By default, using @AffinityKeyMapped annotation force Ignire to override user 
> _keyPersistence_ configuration that may cause confusing results.
> PFA repro attached.
> h3. Description
> 1. Let there is 2 keys A and B that has same fields with one difference. Key 
> A has affinity key in parent class. So, it looks like this.
> {code}
> class BaseKey {
> @AffinityKeyMapped
>  Object affinityKey
> }
> {code}
> {code}
> class A extends BaseKey {
>  int id;
> }
> {code}
> {code}
> class B {
> @AffinityKeyMapped
>  Object affinityKey;
>  int uid;
> }
> {code}
> 2. Let we make different affinity mapping for Cassandra store, that looks 
> like a valid case
> {code:xml}
> 
> 
>  
>  
>
> 
> {code}
> 3. We have different behavior for these similar cases that makes user 
> confused.
> For key A this will work fine and expected DDL will be generated.
> For key B we'll get different DDL as Ignite will remove "_uid_" field from 
> "_partitionKey_".
> So, we should either to not allow Ignite to override key mapping or force 
> Ignite to check if parent classes has @AffinityKeyMapped annotation.



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

[jira] [Updated] (IGNITE-7741) Fix javadoc for QR factorization

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-7741:
---
Priority: Minor  (was: Major)

> Fix javadoc for QR factorization
> 
>
> Key: IGNITE-7741
> URL: https://issues.apache.org/jira/browse/IGNITE-7741
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Priority: Minor
>
> Wrong javadoc for QR factorization.



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

[jira] [Created] (IGNITE-7741) Fix javadoc for QR factorization

[Yury Babak (JIRA)]

Yury Babak created IGNITE-7741:
--

 Summary: Fix javadoc for QR factorization
 Key: IGNITE-7741
 URL: https://issues.apache.org/jira/browse/IGNITE-7741
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


Wrong javadoc for QR factorization.



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

[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3345:
--

[~stalkxt] may I take this issue and implement it by my self?

> Implement support for optional key type in REST HTTP get command
> 
>
> Key: IGNITE-3345
> URL: https://issues.apache.org/jira/browse/IGNITE-3345
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Dorozhkin
>Priority: Major
>
> It seems that in current implementation 
> (https://apacheignite.readme.io/docs/rest-api#get)
> GET command could work only with String keys.
> We can add optional parameter "keyType" and implement support for common 
> built-in types such as Integer, Long, UUID,... and user classes that a valid 
> JavaBeans.
> Sample: http://host:port/ignite?cmd=get=1=myCache=Long



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

[jira] [Commented] (IGNITE-7489) Weird FillFactor metric fluctuation.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7489:


[~agoncharuk] please don't merge, we have some more things to improve here

> Weird FillFactor metric fluctuation.
> 
>
> Key: IGNITE-7489
> URL: https://issues.apache.org/jira/browse/IGNITE-7489
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: FillFactorTest.java
>
>
> For now there is no way to get Used\FreeMemory for region in bytes. 
> MemoryMetrics.getPagesFillFactor() javadoc says that the method return the 
> percentage of space that is still free and can be filled in.
> So, I'd think used memory can be calculated as 
> PhysicalMemoryPages*PageSize*FillFactor.
> I've tried to use this, but found weir thing.
>  
> PFA a repro.
> There is 2 node grid with no persistence configure. Topology is stable.
> Cache is populated with unique keys (no updates) and observe allocated data 
> pages metric grows constantly as expected.
> But the error look too large, used memory (and FillFactor as well) may 2-10+ 
> time differs.
> E.g. allocated pages, fillFactor, usedMem (bytes):(
>  node-0: 13789 0.851563 48096032
>  node-1: 14447 0.781250 46230400
> In next second:
> node-0: 13958 0.039063 2233280
>  node-1: 14624 0.347656 20824576
>  



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

[jira] [Created] (IGNITE-7740) IGFS caches returned by cache.context().queries().sqlMetadata()

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7740:


 Summary: IGFS caches returned by 
cache.context().queries().sqlMetadata() 
 Key: IGNITE-7740
 URL: https://issues.apache.org/jira/browse/IGNITE-7740
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov
Assignee: Vladimir Ozerov


IGFS are special caches not related to queries and should not returned by 

{code}

cache.context().queries().sqlMetadata();

{code}



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

[jira] [Created] (IGNITE-7739) Write about Spring Injection and IgniteSpringBean in documentation

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7739:
---

 Summary: Write about Spring Injection and IgniteSpringBean in 
documentation
 Key: IGNITE-7739
 URL: https://issues.apache.org/jira/browse/IGNITE-7739
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Ilya Kasnacheev


Currently there is no mention of IgniteSpringBean on readme.io

We have section https://apacheignite.readme.io/docs/resource-injection but it's 
totally not obvious how to make e.g. SpringResource work, what are 
pre-requisites.

Thing is, if Ignite creates Spring context (via Ignition), then Spring 
injection would work out of box.
If Spring context creates Ignite as a bean, that bean should be 
IgniteSpringBean and not Ignite. Otherwise, Spring context and lifecycle would 
not be visible to Ignite and injection won't work.

On unrelated note, maybe we need support for Spring Boot already? See 
https://habrahabr.ru/post/310672/



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

[jira] [Commented] (IGNITE-7737) SQL COPY: rename "batch_size" to "packet_size"

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7737:


Github user devozerov closed the pull request at:

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


> SQL COPY: rename "batch_size" to "packet_size"
> --
>
> Key: IGNITE-7737
> URL: https://issues.apache.org/jira/browse/IGNITE-7737
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7734) SQL COPY: support single quotes for file name

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov commented on IGNITE-7734:
-

Do we follow SQL standard on this? Or just support both single or double 
quotes? It looks like token groups should be introduced to SqlLexer for this.

> SQL COPY: support single quotes for file name
> -
>
> Key: IGNITE-7734
> URL: https://issues.apache.org/jira/browse/IGNITE-7734
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> Currently file name is used in COPY command as follows: \{{"/path/to/file"}}. 
> We need to support single-quoted case as well: \{{'/path/to/file'}}.



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

[jira] [Commented] (IGNITE-7537) SQL COPY command: implement CSV format options

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7537:


GitHub user gg-shq opened a pull request:

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

IGNITE-7537: [UNFINISHED] SQL COPY: CSV parsing options

The CSV parser code is not yet finished, however the rest of the code (SQL 
COPY command parameters) is close to completion.

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

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

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

https://github.com/apache/ignite/pull/3537.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 #3537


commit deb7994f0fd4233e3e0b699794b9066af87195c7
Author: gg-shq 
Date:   2018-01-19T12:13:37Z

IGNITE-6917: Intermediate commit

commit e7747a58c2cdacc6987d625a46d1f79a81863cd3
Author: gg-shq 
Date:   2018-01-19T17:21:50Z

IGNITE-6917: Intermediate commit

commit 6f37e6751285a96bdf757b392e1d4113bb47ee48
Author: gg-shq 
Date:   2018-01-19T17:30:22Z

IGNITE-6917: Intermediate commit

commit 49f0324c77d0bb3b4ec87317b1ecbde1bd6f34b1
Author: gg-shq 
Date:   2018-01-22T10:27:34Z

IGNITE-6917: Intermediate commit

commit a5bec61d41d8dc242cfbf11a7cf03c23bbbcd7c3
Author: gg-shq 
Date:   2018-01-22T12:25:04Z

IGNITE-6917: Intermediate commit

commit e18e18696fc92b93b17decf087721c693625ac36
Author: gg-shq 
Date:   2018-01-22T12:35:56Z

IGNITE-6917: Intermediate commit

commit 990c04919e181535e57290ee2516a9603657c160
Author: gg-shq 
Date:   2018-01-22T16:18:18Z

IGNITE-6917: Intermediate commit

commit 8b163410845a6e6233fa8a2746402651ccea3f69
Author: gg-shq 
Date:   2018-01-22T17:16:20Z

IGNITE-6917: Intermediate commit

commit faf762815ef58865c560d6de722be446e429c61d
Author: gg-shq 
Date:   2018-01-23T12:37:56Z

IGNITE-6917: Intermediate commit

commit f79343f04360b913b32403d5aa0defaf5d04b357
Author: gg-shq 
Date:   2018-01-23T12:40:34Z

IGNITE-6917: Intermediate commit

commit efc5d7ab9bad52aaad0872977495a158b0e47770
Author: gg-shq 
Date:   2018-01-23T13:50:04Z

IGNITE-6917: Added BATCH_SIZE parameter to COPY SQL command for internal 
testing. Adding tests.

commit b61db5de48d9a91a658f6133a2ad2544f358ebbf
Author: gg-shq 
Date:   2018-01-24T11:18:55Z

IGNITE-6917: Adding tests. Clarifying default columns set.

commit aa31488b74c74f881c247339a4b2bd31bf45b849
Author: gg-shq 
Date:   2018-01-24T19:00:17Z

IGNITE-6917: More tests, more logging, cleanups, streaming CSV decoder

commit 01125f4bb68bc4ae958cae1d2f8f7dee493fa55e
Author: gg-shq 
Date:   2018-01-25T11:54:29Z

IGNITE-6917: Javadoc, added BulkLoadCacheWriter.

commit 1a21cd91b3571a23d21bab7cb653478312178bb0
Author: gg-shq 
Date:   2018-01-25T12:29:03Z

IGNITE-6917: Javadoc, javadoc, javadoc.

commit a34060392bd5d86b0118fbd26127460d54f918c3
Author: gg-shq 
Date:   2018-01-25T12:29:57Z

IGNITE-6917: Fixed a syntax error added involuntarily in the previous 
commit.

commit ccaef2e349a728145c77c50d96d24e8a38ac35e1
Author: gg-shq 
Date:   2018-01-25T13:31:40Z

IGNITE-6917: Fixed charset decoder bugs, tests, handling of empty lines

commit b4cf0a4a4fb6cf3c6c35f09fe99ac5954541a679
Author: gg-shq 
Date:   2018-01-26T10:54:01Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-6917-1

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/sql/SqlParser.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java

commit 26694bc00b76895d4f22e8416af29000197230ec
Author: gg-shq 
Date:   2018-01-26T12:45:32Z

IGNITE-6917: Moved syntax tests to a separate file, moved truncated rows 
handling from UpdatePlan.processRow() to a different place, minor changes

commit 1d7a9f8818dff4c4bc6a8f9d509a23be394b3e59
Author: gg-shq 
Date:   2018-01-26T12:55:47Z

IGNITE-6917: Find input files by using IgniteUtils.resolveIgnitePath(), 
test fixes.

commit 58c9b2dc7190c149e9c9fa377a2581849bb41420
Author: gg-shq 
Date:   2018-01-26T12:58:58Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-6917-1

commit 47eace53c82770b076b26bbba87944c872a941ad
Author: gg-shq 
Date:   2018-01-26T13:06:11Z

IGNITE-6917: Javadoc, tidying up.

commit ba0f9c822a0873662a5505892956ca4e68d87e56
Author: gg-shq 
Date:   

[jira] [Commented] (IGNITE-7736) SQL COPY: streaming model for network packets instead of request-response model

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov commented on IGNITE-7736:
-

I think the best way to impement it would be to introduce some kind of sliding 
window protocol [1], like TCP window. So the item #4 in your list can be 
sliding window implementation.

We send a number of packets without waiting for an ACK. This number is called 
window size. Ideally:

{noformat}
window_size  = ceil(network_bandwidth * (network_rtt / 2 + 
server_single_packet_processing_time) / packet_size).
{noformat}

Then we wait for ACK for packet with id = (current_packet_id - window_size).

Since we the network bandwidth value is not directly available to us both at 
the client and the server sides we may calculate and adjust optimal window size 
on the client using round-trip time between sending a particular packet and 
receiving an ACK for it. So we can assume that:

{noformat}
bandwidth = packet_size * (current_packet_number - packet_X_number) / 
(packet_X_ack_receive_time - packet_X_sending_start_time)
{noformat}

[1] http://computing.dcu.ie/~humphrys/Notes/Networks/data.sliding.html

And a few thoughts about moving data to separate threads:

Some part of it is already implemented as part of IGNITE-7681 (see 
ignite-7681-2 branch): data conversion (surprisingly the most CPU-intensive 
part) and streaming are relayed to pool threads in the manner of sliding window.

However the parsing can be also parallelized: for a packet we skip characters 
until a line separator and start processing from it. Not processed heads and 
tails of the packets are processed later separately for each pair of 
consecutive packets. However this approach has problems with any kind of line 
numbering (such as auto-incremented line number, if we are about to introduce 
it).

> SQL COPY: streaming model for network packets instead of request-response 
> model
> ---
>
> Key: IGNITE-7736
> URL: https://issues.apache.org/jira/browse/IGNITE-7736
> Project: Ignite
>  Issue Type: Task
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> *Problem*
> Currently data transfer in COPY command is implemented as a series of 
> request-responses. When request is received, it is parsed synchronously and 
> passed to the streamer, then response is sent. This is not very efficient 
> approach:
> # We hardly could utilize long fat network channels efficiently as we spend a 
> lot of time waiting for a very small response (ack).
> # Parsing takes and adding data to the streamer takes time (especially if we 
> reached streamer buffer limitations and are blocked waiting for responses 
> from data nodes). During this period network is not utilized and file data is 
> not transferred further.
> *Solution*
> Let's fix the problem iteratively as follows:
> # Introduce asynchrony - when request is received, send the response 
> immediately before data processing
> # Then consider sending one ack for several requests instead of sending ack 
> for every request
> # When multiple simultaneous requests are enabled (previous point), consider 
> moving data processing to separate stream, so that we can read data from the 
> socket as fast as possible 



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6005:


Hi [~agura],

Kind reminder, please reply. Can we merge with improvement issue?

> [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
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> 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 
> 

[jira] [Commented] (IGNITE-7489) Weird FillFactor metric fluctuation.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7489:


Looks good to me, thank you, [~ilyak].

[~agoncharuk], could you please merge?

> Weird FillFactor metric fluctuation.
> 
>
> Key: IGNITE-7489
> URL: https://issues.apache.org/jira/browse/IGNITE-7489
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: FillFactorTest.java
>
>
> For now there is no way to get Used\FreeMemory for region in bytes. 
> MemoryMetrics.getPagesFillFactor() javadoc says that the method return the 
> percentage of space that is still free and can be filled in.
> So, I'd think used memory can be calculated as 
> PhysicalMemoryPages*PageSize*FillFactor.
> I've tried to use this, but found weir thing.
>  
> PFA a repro.
> There is 2 node grid with no persistence configure. Topology is stable.
> Cache is populated with unique keys (no updates) and observe allocated data 
> pages metric grows constantly as expected.
> But the error look too large, used memory (and FillFactor as well) may 2-10+ 
> time differs.
> E.g. allocated pages, fillFactor, usedMem (bytes):(
>  node-0: 13789 0.851563 48096032
>  node-1: 14447 0.781250 46230400
> In next second:
> node-0: 13958 0.039063 2233280
>  node-1: 14624 0.347656 20824576
>  



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

[jira] [Commented] (IGNITE-7737) SQL COPY: rename "batch_size" to "packet_size"

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov commented on IGNITE-7737:
-

I've found a couple of tiny cosmetic problems in the patch:

1. JdbcThinBulkLoadAbstractSelfTest.java:392: 
typo: packets instead of packets

2. SqlKeyword.java:46
PACKET_SIZE is not in the alphabet order (as the most of the keywords)

> SQL COPY: rename "batch_size" to "packet_size"
> --
>
> Key: IGNITE-7737
> URL: https://issues.apache.org/jira/browse/IGNITE-7737
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-:
---
Description: 
Most recent crashes
https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv

https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1

{noformat}
   Ignite PDS 1 [ tests 0 JVM CRASH ] 
 BPlusTreeReuseListPageMemoryImplTest.testEmptyCursors (last started) 
{noformat}

(older failure
http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)

Stacktrace indicates failure was in ignite code related to B+tree
{noformat}J 34156 C2 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
 (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
J 34634 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
J 34633 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
 (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 35053 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
{noformat}

  was:
Most recent crashes
https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv

https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1

(older failure
http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)

Stacktrace indicates failure was in ignite code related to B+tree
{noformat}J 34156 C2 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
 (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
J 34634 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
J 34633 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
 (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 

[jira] [Created] (IGNITE-7738) Allow 'multiple statements' in thin JDBC streaming mode

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7738:
---

 Summary: Allow 'multiple statements' in thin JDBC streaming mode
 Key: IGNITE-7738
 URL: https://issues.apache.org/jira/browse/IGNITE-7738
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Alexander Paschenko


We need to update thin JDBC protocol to let user run multiple statements via 
Statement.execute(String) when connection is in streamed mode. Currently in 
streaming mode the server always receives all SQL in batches and its batch 
processing logic does not allow multiple statements altogether. If we're able 
to recognize initial nature of the statement, we'll be able to act 
appropriately, and for this to be possible additional information must be 
passed with each query in the batch.



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

[jira] [Updated] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-:
---
Priority: Critical  (was: Major)

> Ignite PDS 1: JVM crash on teamcity (Rare)
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.5
>
> Attachments: crash_report, thread_dump
>
>
> Most recent crashes
> https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv
> https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1
> (older failure
> http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)
> Stacktrace indicates failure was in ignite code related to B+tree
> {noformat}J 34156 C2 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
>  (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
> J 34634 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
> J 34633 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
>  (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 35053 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
> {noformat}



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

[jira] [Updated] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-:
---
Fix Version/s: 2.5

> Ignite PDS 1: JVM crash on teamcity (Rare)
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.5
>
> Attachments: crash_report, thread_dump
>
>
> Most recent crashes
> https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv
> https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1
> (older failure
> http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)
> Stacktrace indicates failure was in ignite code related to B+tree
> {noformat}J 34156 C2 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
>  (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
> J 34634 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
> J 34633 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
>  (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 35053 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
> {noformat}



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

[jira] [Assigned] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-:
--

Assignee: Dmitriy Pavlov

> Ignite PDS 1: JVM crash on teamcity (Rare)
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test-fail
> Attachments: crash_report, thread_dump
>
>
> Most recent crashes
> https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv
> https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1
> (older failure
> http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)
> Stacktrace indicates failure was in ignite code related to B+tree
> {noformat}J 34156 C2 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
>  (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
> J 34634 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
> J 34633 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
>  (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
>  (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 35053 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
> {noformat}



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

[jira] [Updated] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-:
---
Description: 
Most recent crashes
https://ci.ignite.apache.org/viewLog.html?buildId=1095007=IgniteTests24Java8_IgnitePds1=buildResultsDiv

https://ci.ignite.apache.org/viewLog.html?buildId=1086130=buildResultsDiv=IgniteTests24Java8_IgnitePds1

(older failure
http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#)

Stacktrace indicates failure was in ignite code related to B+tree
{noformat}J 34156 C2 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
 (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
J 34634 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
J 34633 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
 (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 34888 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
 (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
J 35053 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
{noformat}

  was:

http://ci.ignite.apache.org/viewLog.html?buildId=675694=buildResultsDiv=Ignite20Tests_IgnitePds1#

Stacktrace indicates failure was in ignite code
{noformat}
[12:37:10][org.apache.ignite:ignite-core] 
[12:37:10][org.apache.ignite:ignite-core] Thread [name="main", id=1, 
state=RUNNABLE, blockCnt=254, waitCnt=281]
[12:37:10][org.apache.ignite:ignite-core] at 
sun.management.ThreadImpl.dumpThreads0(Native Method)
[12:37:10][org.apache.ignite:ignite-core] at 
sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:446)
[12:37:10][org.apache.ignite:ignite-core] at 
o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1272)
[12:37:10][org.apache.ignite:ignite-core] at 
o.a.i.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1937)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestCase.runBare(TestCase.java:141)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestResult$1.protect(TestResult.java:122)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestResult.runProtected(TestResult.java:142)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestResult.run(TestResult.java:125)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestCase.run(TestCase.java:129)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestSuite.runTest(TestSuite.java:255)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestSuite.run(TestSuite.java:250)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestSuite.runTest(TestSuite.java:255)
[12:37:10][org.apache.ignite:ignite-core] at 
junit.framework.TestSuite.run(TestSuite.java:250)
[12:37:10][org.apache.ignite:ignite-core] at 

[jira] [Commented] (IGNITE-7253) JDBC thin driver: introduce streaming mode

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-7253:
-

[~vozerov],

all done.

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



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

[jira] [Assigned] (IGNITE-7632) NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()

[Pavel Vinokurov (JIRA)]

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

Pavel Vinokurov reassigned IGNITE-7632:
---

Assignee: (was: Pavel Vinokurov)

> NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()
> ---
>
> Key: IGNITE-7632
> URL: https://issues.apache.org/jira/browse/IGNITE-7632
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Major
> Fix For: 2.4
>
>
> Occurs on destroying cache while rebuilding indices in progress
> {noformat}
> Partition eviction failed, this can cause grid hang.
> java.lang.NullPointerException: null
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics(IgniteCacheOffheapManagerImpl.java:1576)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1368)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1312)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:368)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:895)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> ...
> {noformat}



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

[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7717:


GitHub user Jokser opened a pull request:

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

IGNITE-7717 Update discovery caches on topologies after exchanges merge



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

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

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

https://github.com/apache/ignite/pull/3536.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 #3536


commit 054a71827b0329793afd48720caa084a530a49f9
Author: Pavel Kovalenko 
Date:   2018-02-16T13:36:10Z

IGNITE-7717 Update discovery caches on topologies after exchanges merge.




> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], 

[jira] [Commented] (IGNITE-7676) Add affinity version to snapshot plugin stub

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7676:


Github user asfgit closed the pull request at:

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


> Add affinity version to snapshot plugin stub
> 
>
> Key: IGNITE-7676
> URL: https://issues.apache.org/jira/browse/IGNITE-7676
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7632) NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7632:
--

[~pvinokurov] I am not sure the fix is correct. How can we make sure that 
internals of a non-null CacheAdapter will not be destroyed after we obtained a 
non-null reference to it?

[~Jokser] Can you please review if this issue is already fixed in IGNITE-6113 ?

> NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()
> ---
>
> Key: IGNITE-7632
> URL: https://issues.apache.org/jira/browse/IGNITE-7632
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Pavel Vinokurov
>Priority: Major
> Fix For: 2.4
>
>
> Occurs on destroying cache while rebuilding indices in progress
> {noformat}
> Partition eviction failed, this can cause grid hang.
> java.lang.NullPointerException: null
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics(IgniteCacheOffheapManagerImpl.java:1576)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1368)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1312)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:368)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:895)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> ...
> {noformat}



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

[jira] [Commented] (IGNITE-7699) BinaryMetadata exchange should not be triggered if metadata was not updated

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7699:


Github user asfgit closed the pull request at:

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


> BinaryMetadata exchange should not be triggered if metadata was not updated
> ---
>
> Key: IGNITE-7699
> URL: https://issues.apache.org/jira/browse/IGNITE-7699
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.5
>
>
> It was found that DiscoveryCustomEvent-based implementation of BinaryMetadata 
> exchange protocol triggers propose-accept process even when it is not needed.
> In some situations BinaryObjects may be built with exactly the same scheme 
> many times, and registering of BinaryMetatada only once is enough.
> However current implementation executes expensive propose-accept process for 
> each *addMeta* request even if requesting meta is the same.
> Implementation should be improved so that prop-ack process is executed only 
> if BinaryMetadata really changed.



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

[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-7717:
-

Cause of the problem:

Let's we have some existing topology and start several nodes in parallel.
1) We have several pending exchange futures (NODE_JOIN) in the queue. Each of 
the exchange futures has own discovery cache. Each discovery cache contains 
different state of the alive nodes and etc.
2) Pick and process first (earliest) future with the earliest state of 
discovery cache.
3) Update topology discovery cache (updateTopologies method) and do other 
exchange stuff.
4) After exchange is done we merge pending futures to the current and remove 
them from queue.
After that step we have valid node2part maps on all topologies, but have 
outdated discoveryCaches belong to the earliest (current) exchange future.

Possible fix:
After successful merge pending exchanges to the current, invoke 
'updateTopologies' method and update discovery caches with new version of 
topology.


> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> 

[jira] [Updated] (IGNITE-7676) Add affinity version to snapshot plugin stub

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-7676:
--
Fix Version/s: 2.5

> Add affinity version to snapshot plugin stub
> 
>
> Key: IGNITE-7676
> URL: https://issues.apache.org/jira/browse/IGNITE-7676
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7717:

Component/s: (was: persistence)
 cache

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



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

[jira] [Commented] (IGNITE-7191) JDBC: set socket buffer to 64k by default

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7191:
--

No improvement is observed. Closing the ticket

> JDBC: set socket buffer to 64k by default
> -
>
> Key: IGNITE-7191
> URL: https://issues.apache.org/jira/browse/IGNITE-7191
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
> Fix For: 2.5
>
>
> TCP socket buffer size can significantly affect user-visible performance 
> (actually, latency) for SQL queries, especially if Ignite cluster is run at 
> the remote hosts. 
> It is better to have 64k TCP socket buffer size (instead of default 8k) by 
> default to avoid possible delays in TCP transport.



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

[jira] [Updated] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7717:

Fix Version/s: (was: 2.5)

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



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

[jira] [Comment Edited] (IGNITE-7531) SQL: Create data load benchmarks

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov edited comment on IGNITE-7531 at 2/16/18 12:52 PM:
---

10M rows 3 servers, 1 client, 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec


was (Author: pkouznet):
10M rows 3 servers 1 client 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec

> SQL: Create data load benchmarks
> 
>
> Key: IGNITE-7531
> URL: https://issues.apache.org/jira/browse/IGNITE-7531
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement a set of data loading benchmarks to better understand 
> how fast Ignite is able to consume data. This task consists of two steps:
> 1) Extend Yardstick capabilities
> 2) Create set of benchmarks
> 1) Yardstick
> Data load benchmark should be executed in single-shot mode: only one 
> iteration, only total execution time is needed, start callback for setup and 
> warmup, stop callback for cleanup. 
> Currently Yardstick cannot do that, so we need to extend it. Possibly, we can 
> control this through new {{boolean BenchmarkDriver.isSingleShot()}} method.
> 2) Benchmarks 
> At first let's focus on thin JDBC driver. The following cases should be 
> executed:
> 2.1) Normal INSERT
> 2.2) Batched INSERT
> 2.3) Streaming INSERT (when IGNITE-7253 is ready)
> 2.4) P. 1-3 with and without dynamically disabled WAL (ALTER TABLE ... 
> NOLOGGING)
> 2.5) P. 1-3 with additional indexes - either created before data load on 
> empty table, or after load on table with data.



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

[jira] [Commented] (IGNITE-7531) SQL: Create data load benchmarks

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-7531:
-

10M rows 3 servers 1 client 1 jdbc application:

batched 1000 : 194 sec
copy csv : 174,5 sec

> SQL: Create data load benchmarks
> 
>
> Key: IGNITE-7531
> URL: https://issues.apache.org/jira/browse/IGNITE-7531
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement a set of data loading benchmarks to better understand 
> how fast Ignite is able to consume data. This task consists of two steps:
> 1) Extend Yardstick capabilities
> 2) Create set of benchmarks
> 1) Yardstick
> Data load benchmark should be executed in single-shot mode: only one 
> iteration, only total execution time is needed, start callback for setup and 
> warmup, stop callback for cleanup. 
> Currently Yardstick cannot do that, so we need to extend it. Possibly, we can 
> control this through new {{boolean BenchmarkDriver.isSingleShot()}} method.
> 2) Benchmarks 
> At first let's focus on thin JDBC driver. The following cases should be 
> executed:
> 2.1) Normal INSERT
> 2.2) Batched INSERT
> 2.3) Streaming INSERT (when IGNITE-7253 is ready)
> 2.4) P. 1-3 with and without dynamically disabled WAL (ALTER TABLE ... 
> NOLOGGING)
> 2.5) P. 1-3 with additional indexes - either created before data load on 
> empty table, or after load on table with data.



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

[jira] [Commented] (IGNITE-7699) BinaryMetadata exchange should not be triggered if metadata was not updated

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-7699:
-

TC status looks acceptable comparing to master branch: 
[pull/3523/head|https://ci.ignite.apache.org/viewLog.html?buildId=1096760;]

[~agoncharuk] could you please take a look at the change?

> BinaryMetadata exchange should not be triggered if metadata was not updated
> ---
>
> Key: IGNITE-7699
> URL: https://issues.apache.org/jira/browse/IGNITE-7699
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.5
>
>
> It was found that DiscoveryCustomEvent-based implementation of BinaryMetadata 
> exchange protocol triggers propose-accept process even when it is not needed.
> In some situations BinaryObjects may be built with exactly the same scheme 
> many times, and registering of BinaryMetatada only once is enough.
> However current implementation executes expensive propose-accept process for 
> each *addMeta* request even if requesting meta is the same.
> Implementation should be improved so that prop-ack process is executed only 
> if BinaryMetadata really changed.



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

[jira] [Resolved] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[Pavel Vinokurov (JIRA)]

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

Pavel Vinokurov resolved IGNITE-7718.
-
Resolution: Fixed

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



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

[jira] [Reopened] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[Pavel Vinokurov (JIRA)]

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

Pavel Vinokurov reopened IGNITE-7718:
-

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



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

[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7718:


GitHub user pvinokurov opened a pull request:

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

IGNITE-7718 Fixed deserialization of binary objects in singleton map …

…and set.

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

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

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

https://github.com/apache/ignite/pull/3534.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 #3534


commit c19d4e62db0a3db59617c4813d531283970025b6
Author: pvinokurov 
Date:   2018-02-16T12:23:37Z

IGNITE-7718 Fixed deserialization of binary objects in singleton map and 
set.




> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



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

[jira] [Commented] (IGNITE-7737) SQL COPY: rename "batch_size" to "packet_size"

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7737:


GitHub user devozerov opened a pull request:

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

IGNITE-7737



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

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

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

https://github.com/apache/ignite/pull/3533.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 #3533


commit 8a6e5a7c070968a410aec327c1530b06145c3a26
Author: devozerov 
Date:   2018-02-16T11:52:00Z

Done.




> SQL COPY: rename "batch_size" to "packet_size"
> --
>
> Key: IGNITE-7737
> URL: https://issues.apache.org/jira/browse/IGNITE-7737
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Created] (IGNITE-7737) SQL COPY: rename "batch_size" to "packet_size"

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7737:
---

 Summary: SQL COPY: rename "batch_size" to "packet_size"
 Key: IGNITE-7737
 URL: https://issues.apache.org/jira/browse/IGNITE-7737
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.5






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

[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-7682:
-

[~Roman_BRR], okay, I'll take a look. Thank you for report.

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Assignee: Igor Sapego
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Assigned] (IGNITE-7682) C++: LocalSize cache functions

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-7682:
---

Assignee: Igor Sapego

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Assignee: Igor Sapego
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Commented] (IGNITE-7720) Update ODBC cluster configuration: replace OdbcConfiguration with ClientConnectorConfiguration

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-7720:
-

[~dmagda], sure

> Update ODBC cluster configuration: replace OdbcConfiguration with 
> ClientConnectorConfiguration
> --
>
> Key: IGNITE-7720
> URL: https://issues.apache.org/jira/browse/IGNITE-7720
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.4
>
>
> https://apacheignite-sql.readme.io/docs/odbc-driver#section-cluster-configuration
> Please note that ODBC configuration is depricated. It is better to update 
> this page with 
> ClientConnectorConfiguration
> BTW, https://apacheignite-sql.readme.io/docs/jdbc-driver is already updated )
> {quote}
> /**
>  * ODBC configuration.
>  * 
>  * Deprecated as of Apache Ignite 2.1. Please use {@link 
> ClientConnectorConfiguration} and
>  * {@link 
> IgniteConfiguration#setClientConnectorConfiguration(ClientConnectorConfiguration)}
>  instead.
>  */
> @Deprecated
> public class OdbcConfiguration {
> {quote}



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

[jira] [Comment Edited] (IGNITE-7253) JDBC thin driver: introduce streaming mode

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-7253 at 2/16/18 11:07 AM:
---

[~vozerov],

2, 3 - the only need for batch size in these cases is to keep track of number 
of fake counters that we return. That is, if user has issued "addBatch" trice, 
we return that number of counters, each having value of zero. Just a weak 
attempt to create a visibility of JDBC compliance, nothing else.


was (Author: al.psc):
[~vozerov],

2, 3 - the only need for batch size in these cases is to keep track of number 
of fake counters that we remove. That is, if user has issued "addBatch" trice, 
we return that number of counters, each having value of zero. Just a weak 
attempt to create a visibility of JDBC compliance, nothing else.

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



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

[jira] [Created] (IGNITE-7736) SQL COPY: streaming model for network packets instead of request-response model

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7736:
---

 Summary: SQL COPY: streaming model for network packets instead of 
request-response model
 Key: IGNITE-7736
 URL: https://issues.apache.org/jira/browse/IGNITE-7736
 Project: Ignite
  Issue Type: Task
Reporter: Vladimir Ozerov
 Fix For: 2.5


*Problem*
Currently data transfer in COPY command is implemented as a series of 
request-responses. When request is received, it is parsed synchronously and 
passed to the streamer, then response is sent. This is not very efficient 
approach:
# We hardly could utilize long fat network channels efficiently as we spend a 
lot of time waiting for a very small response (ack).
# Parsing takes and adding data to the streamer takes time (especially if we 
reached streamer buffer limitations and are blocked waiting for responses from 
data nodes). During this period network is not utilized and file data is not 
transferred further.

*Solution*
Let's fix the problem iteratively as follows:
# Introduce asynchrony - when request is received, send the response 
immediately before data processing
# Then consider sending one ack for several requests instead of sending ack for 
every request
# When multiple simultaneous requests are enabled (previous point), consider 
moving data processing to separate stream, so that we can read data from the 
socket as fast as possible 



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

[jira] [Created] (IGNITE-7735) SQL COPY: expose streamer options to user

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7735:
---

 Summary: SQL COPY: expose streamer options to user
 Key: IGNITE-7735
 URL: https://issues.apache.org/jira/browse/IGNITE-7735
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.5


COPY command uses cache streamer underneath. We need to expose usual streamer 
options (per-node-buffer-size, per-node-parallel-ops, allow-overwrite, etc) to 
the user.



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

[jira] [Created] (IGNITE-7734) SQL COPY: support single quotes for file name

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7734:
---

 Summary: SQL COPY: support single quotes for file name
 Key: IGNITE-7734
 URL: https://issues.apache.org/jira/browse/IGNITE-7734
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.5


Currently file name is used in COPY command as follows: \{{"/path/to/file"}}. 
We need to support single-quoted case as well: \{{'/path/to/file'}}.



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

[jira] [Created] (IGNITE-7733) SQL COPY: native API support

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7733:
---

 Summary: SQL COPY: native API support
 Key: IGNITE-7733
 URL: https://issues.apache.org/jira/browse/IGNITE-7733
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.5


Currently COPY command can only be executed from within thin JDBC driver. Need 
to add native API support as well.



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

[jira] [Created] (IGNITE-7732) SQL COPY: ODBC support

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7732:
---

 Summary: SQL COPY: ODBC support
 Key: IGNITE-7732
 URL: https://issues.apache.org/jira/browse/IGNITE-7732
 Project: Ignite
  Issue Type: Task
  Components: odbc, sql
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.5


Support COPY command for ODBC driver in the same way it is done for JDBC.



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

[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7731:

Fix Version/s: 2.5

> ClassCastException at restarted node if killed during checkpoint
> 
>
> Key: IGNITE-7731
> URL: https://issues.apache.org/jira/browse/IGNITE-7731
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ksenia Rybakova
>Priority: Major
> Fix For: 2.5
>
> Attachments: 
> 120728_id11_172.25.1.49_cache-random-benchmark-2-backup.log, 
> 121729_id11-1_172.25.1.49cache-random-benchmark-2-backup.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During failover test restarted node fails to start with the following 
> exception:
> {noformat}
> [2018-02-15 12:17:46,388][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
> [startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
>  endMarker=null]
> [2018-02-15 12:17:46,389][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
> [lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
> lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
> forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
> [2018-02-15 12:17:46,389][WARN 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
> the middle of checkpoint. Will restore memory state and finish checkpoint on 
> node start.
> [2018-02-15 
> 12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49], 
> sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500], 
> discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183, 
> loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38, 
> nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006], 
> nodeId=b8684b5c, evt=NODE_JOINED]
> java.lang.ClassCastException: 
> org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast 
> to 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This happens if node was killed during checkpoint (it seems only during the 
> first one).
> Load conifg:
>  * Yardstick with CacheRandomOperationBenchmark
>  * 12 client nodes, 24 server nodes, 12 hosts (2 per host). The issue is also 
> reproduced when restarted node is 1 per host.
>  * Several caches with different configs: pds/in memory, tx/atomic, 
> with/without eviction etc. No dynamic caches. Complete configs are attached.
>  * 1 node is restarted periodically.
> Logs of restarted node are attached.
>  



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

[jira] [Commented] (IGNITE-7192) JDBC: support FQDN to multiple IPs during connection establishment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7192:


Github user asfgit closed the pull request at:

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


> JDBC: support FQDN to multiple IPs during connection establishment
> --
>
> Key: IGNITE-7192
> URL: https://issues.apache.org/jira/browse/IGNITE-7192
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: pull-request-available
>
> Thin JDBC driver may have FQDN (host name) at a connection string.
> Currently, it resolves this FQDN to one IP and tries to connect to this IP 
> only.
> It is better to try to connect to multiple IPs one-by-one if DNS returns 
> multiple A-records (FQDN can be resolved to several IPs) until successful 
> connection. It could give a simple fallback option for the JDBC thin driver 
> users.
> A similar functionality is already implemented in ODBC driver.



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

[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7731:

Description: 
During failover test restarted node fails to start with the following exception:
{noformat}
[2018-02-15 12:17:46,388][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
[startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
 endMarker=null]
[2018-02-15 12:17:46,389][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
[lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
[2018-02-15 12:17:46,389][WARN 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
the middle of checkpoint. Will restore memory state and finish checkpoint on 
node start.
[2018-02-15 
12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49], 
sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500], 
discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183, 
loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38, 
nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006], 
nodeId=b8684b5c, evt=NODE_JOINED]
java.lang.ClassCastException: 
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast to 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:748)

{noformat}
This happens if node was killed during checkpoint (it seems only during the 
first one).

Load conifg:
 * Yardstick with CacheRandomOperationBenchmark
 * 12 client nodes, 24 server nodes, 12 hosts (2 per host). The issue is also 
reproduced when restarted node is 1 per host.
 * Several caches with different configs: pds/in memory, tx/atomic, 
with/without eviction etc. No dynamic caches. Complete configs are attached.
 * 1 node is restarted periodically.

Logs of restarted node are attached.

 

  was:
During failover test restarted node fails to start with the following exception:
{noformat}
[2018-02-15 12:17:46,388][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
[startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
 endMarker=null]
[2018-02-15 12:17:46,389][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
[lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
[2018-02-15 12:17:46,389][WARN 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
the middle of checkpoint. Will restore memory state and finish checkpoint on 
node start.
[2018-02-15 
12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 

[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7731:

Attachment: 121729_id11-1_172.25.1.49cache-random-benchmark-2-backup.log
120728_id11_172.25.1.49_cache-random-benchmark-2-backup.log

> ClassCastException at restarted node if killed during checkpoint
> 
>
> Key: IGNITE-7731
> URL: https://issues.apache.org/jira/browse/IGNITE-7731
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: 
> 120728_id11_172.25.1.49_cache-random-benchmark-2-backup.log, 
> 121729_id11-1_172.25.1.49cache-random-benchmark-2-backup.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During failover test restarted node fails to start with the following 
> exception:
> {noformat}
> [2018-02-15 12:17:46,388][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
> [startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
>  endMarker=null]
> [2018-02-15 12:17:46,389][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
> [lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
> lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
> forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
> [2018-02-15 12:17:46,389][WARN 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
> the middle of checkpoint. Will restore memory state and finish checkpoint on 
> node start.
> [2018-02-15 
> 12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49], 
> sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500], 
> discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183, 
> loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38, 
> nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006], 
> nodeId=b8684b5c, evt=NODE_JOINED]
> java.lang.ClassCastException: 
> org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast 
> to 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This happens if node was killed during checkpoint (it seems only during the 
> first one).
> Load conifg:
>  * Yardstick with CacheRandomOperationBenchmark
>  * 12 client nodes, 24 server nodes, 12 hosts (2 per host). The issue is also 
> reproduced when restarted node is 1 per host.
>  * Several caches with different configs: pds/in memory, tx/atomic, 
> with/without eviction etc. No dynamic caches. Complete configs are attached.
>  * 1 node is restarted periodically.
> Logs of restarted node are attached.
>  



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

[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7731:

Description: 
During failover test restarted node fails to start with the following exception:
{noformat}
[2018-02-15 12:17:46,388][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
[startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
 endMarker=null]
[2018-02-15 12:17:46,389][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
[lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
[2018-02-15 12:17:46,389][WARN 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
the middle of checkpoint. Will restore memory state and finish checkpoint on 
node start.
[2018-02-15 
12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49], 
sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500], 
discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183, 
loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38, 
nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006], 
nodeId=b8684b5c, evt=NODE_JOINED]
java.lang.ClassCastException: 
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast to 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:748)

{noformat}
This happens if node was killed during checkpoint (it seems only during the 
first one).

Load conifg:
 * Yardstick with CacheRandomOperationBenchmark
 * 12 client nodes, 24 server nodes, 12 hosts (2 per host). The issue is also 
reproduced when restarted node is 1 per host.
 * Several caches with different configs: pds/in memory, tx/atomic, 
with/without eviction etc. No dynamic caches. Complete configs are attached.
 * 1 node is restarted periodically.

  was:
During failover test restarted node fails to start with the following exception:

{noformat}

[2018-02-15 12:17:46,388][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
[startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
 endMarker=null]
[2018-02-15 12:17:46,389][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
[lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
[2018-02-15 12:17:46,389][WARN 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
the middle of checkpoint. Will restore memory state and finish checkpoint on 
node start.
[2018-02-15 
12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, 

[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7731:

Attachment: run-load.xml
run-load.properties
ignite-base-load-config.xml

> ClassCastException at restarted node if killed during checkpoint
> 
>
> Key: IGNITE-7731
> URL: https://issues.apache.org/jira/browse/IGNITE-7731
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-base-load-config.xml, run-load.properties, 
> run-load.xml
>
>
> During failover test restarted node fails to start with the following 
> exception:
> {noformat}
> [2018-02-15 12:17:46,388][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
> [startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
>  endMarker=null]
> [2018-02-15 12:17:46,389][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
> [lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
> lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
> forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
> [2018-02-15 12:17:46,389][WARN 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
> the middle of checkpoint. Will restore memory state and finish checkpoint on 
> node start.
> [2018-02-15 
> 12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49], 
> sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500], 
> discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183, 
> loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38, 
> nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006], 
> nodeId=b8684b5c, evt=NODE_JOINED]
> java.lang.ClassCastException: 
> org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast 
> to 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This happens if node was killed during checkpoint (it seems only during the 
> first one).
> Load conifg:
>  * Yardstick with CacheRandomOperationBenchmark
>  * 12 client nodes, 23 server nodes, 12 hosts (2 per host, but restarted 
> server is 1 per host)
>  * Several caches with different configs: pds/in memory, tx/atomic, 
> with/without eviction etc. No dynamic caches. Complete configs are attached.
>  * 1 node is restarted periodically.



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

[jira] [Assigned] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-7320:
--

Assignee: Alexander Kalinin  (was: Andrey Novikov)

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
> Attachments: Lk1YqS (1).jpg
>
>




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

[jira] [Commented] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-7320:


Not working under safari 11.

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Andrey Novikov
>Priority: Minor
> Attachments: Lk1YqS (1).jpg
>
>




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

[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7731:

Affects Version/s: 2.3
  Description: 
During failover test restarted node fails to start with the following exception:

{noformat}

[2018-02-15 12:17:46,388][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
[startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
 endMarker=null]
[2018-02-15 12:17:46,389][INFO 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
[lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
[2018-02-15 12:17:46,389][WARN 
][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in 
the middle of checkpoint. Will restore memory state and finish checkpoint on 
node start.
[2018-02-15 
12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38, 
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49], 
sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500], 
discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183, 
loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38, 
nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006], 
nodeId=b8684b5c, evt=NODE_JOINED]
java.lang.ClassCastException: 
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast to 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:748)

{noformat}

This happens if node was killed during checkpoint (it seems only during the 
first one).

Load conifg:
 * Yardstick with CacheRandomOperationBenchmark
 * 12 client nodes, 23 server nodes, 12 hosts (2 per host, but restarted server 
is 1 per host)
 * Several caches with different configs: pds/in memory, tx/atomic, 
with/without eviction etc. No dynamic caches. Complete configs are attached.
 * 1 node is restarted periodically.
  Summary: ClassCastException at restarted node if killed during 
checkpoint  (was: Restarted node can)

> ClassCastException at restarted node if killed during checkpoint
> 
>
> Key: IGNITE-7731
> URL: https://issues.apache.org/jira/browse/IGNITE-7731
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ksenia Rybakova
>Priority: Major
>
> During failover test restarted node fails to start with the following 
> exception:
> {noformat}
> [2018-02-15 12:17:46,388][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status 
> [startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
>  endMarker=null]
> [2018-02-15 12:17:46,389][INFO 
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state 
> [lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false], 
> lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151, 
> forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
> [2018-02-15 

[jira] [Updated] (IGNITE-7434) Thin client Java API - cache query API

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7434:
-
Description: 
Implement cache query thin client Java API including unit and system tests and 
samples.

Cache
         query(qry: Query): QueryCursor

> Thin client Java API - cache query API
> --
>
> Key: IGNITE-7434
> URL: https://issues.apache.org/jira/browse/IGNITE-7434
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement cache query thin client Java API including unit and system tests 
> and samples.
> Cache
>          query(qry: Query): QueryCursor



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

[jira] [Updated] (IGNITE-7434) Thin client Java API - cache query API

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7434:
-
Environment: (was: Implement cache query thin client Java API including 
unit and system tests and samples.

Cache
        query(qry: Query): QueryCursor)

> Thin client Java API - cache query API
> --
>
> Key: IGNITE-7434
> URL: https://issues.apache.org/jira/browse/IGNITE-7434
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>




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

[jira] [Created] (IGNITE-7731) Restarted node can

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-7731:
---

 Summary: Restarted node can
 Key: IGNITE-7731
 URL: https://issues.apache.org/jira/browse/IGNITE-7731
 Project: Ignite
  Issue Type: Bug
Reporter: Ksenia Rybakova






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

[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions

[Roman Bastanov (JIRA)]

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

Roman Bastanov commented on IGNITE-7682:


{quote}
[~Roman_BRR], what about Java API? Does it behave the same?

{quote}
The behavior on Java and C++ is different.

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions

[Roman Bastanov (JIRA)]

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

Roman Bastanov commented on IGNITE-7682:


Java node and C++ node started with same Spring config.
I use replicated cache.

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Comment Edited] (IGNITE-7682) C++: LocalSize cache functions

[Roman Bastanov (JIRA)]

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

Roman Bastanov edited comment on IGNITE-7682 at 2/16/18 9:07 AM:
-

Same code on Java works fine:
{code:java}
IgniteCache cache = igniteNode.cache(cache_name);
QueryCursor> cursor = cache.query(new ScanQuery().setLocal(true));
//-\/Debug\/
System.out.println("[T] ^-- cache.localSizeLong():" + cache.localSizeLong());
{code}

And result is size of local cache(cache size on this node)


was (Author: roman_brr):
Same code on Java works fine:
{code:java}
IgniteCache cache = igniteNode.cache(cache_name);
QueryCursor> cursor = cache.query(new ScanQuery().setLocal(true));
//-\/Debug\/
System.out.println("[T] ^-- cache.localSizeLong():" + cache.localSizeLong());
{code}

And result is size of local cashe(cache size on this node)

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Comment Edited] (IGNITE-7682) C++: LocalSize cache functions

[Roman Bastanov (JIRA)]

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

Roman Bastanov edited comment on IGNITE-7682 at 2/16/18 9:06 AM:
-

Same code on Java works fine:
{code:java}
IgniteCache cache = igniteNode.cache(cache_name);
QueryCursor> cursor = cache.query(new ScanQuery().setLocal(true));
//-\/Debug\/
System.out.println("[T] ^-- cache.localSizeLong():" + cache.localSizeLong());
{code}

And result is size of local cashe(cache size on this node)


was (Author: roman_brr):
Same code on Java works fine:{code:java}
IgniteCache cache = igniteNode.cache(cache_name);
QueryCursor> cursor = cache.query(new ScanQuery().setLocal(true));
//-\/Debug\/
System.out.println("[T] ^-- cache.localSizeLong():" + cache.localSizeLong());
{code}

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions

[Roman Bastanov (JIRA)]

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

Roman Bastanov commented on IGNITE-7682:


Same code on Java works fine:{code:java}
IgniteCache cache = igniteNode.cache(cache_name);
QueryCursor> cursor = cache.query(new ScanQuery().setLocal(true));
//-\/Debug\/
System.out.println("[T] ^-- cache.localSizeLong():" + cache.localSizeLong());
{code}

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Commented] (IGNITE-7192) JDBC: support FQDN to multiple IPs during connection establishment

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7192:


Latest tests results: https://ci.ignite.apache.org/viewLog.html?buildId=1096565;

> JDBC: support FQDN to multiple IPs during connection establishment
> --
>
> Key: IGNITE-7192
> URL: https://issues.apache.org/jira/browse/IGNITE-7192
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: pull-request-available
>
> Thin JDBC driver may have FQDN (host name) at a connection string.
> Currently, it resolves this FQDN to one IP and tries to connect to this IP 
> only.
> It is better to try to connect to multiple IPs one-by-one if DNS returns 
> multiple A-records (FQDN can be resolved to several IPs) until successful 
> connection. It could give a simple fallback option for the JDBC thin driver 
> users.
> A similar functionality is already implemented in ODBC driver.



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

[jira] [Commented] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-7320:
---

[~anovikov] [~Dmitriyff] Please review. Branch - ignite-7320

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Andrey Novikov
>Priority: Minor
> Attachments: Lk1YqS (1).jpg
>
>




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

[jira] [Assigned] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7320:
-

Assignee: Andrey Novikov  (was: Pavel Konstantinov)

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Andrey Novikov
>Priority: Minor
> Attachments: Lk1YqS (1).jpg
>
>




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

[jira] [Commented] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7694:
--

Merged to master

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> This is a regression from
> The test hangs because there is an assertion happened after the client 
> reconnects to the cluster:
> {code}
> [2018-02-13 
> 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The reason for the assertion is that the client does not clear {{lastAffVer}} 
> field when disconnected, and cluster is restarted when the client is in the 
> disconnected state.



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