[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-2766:
-

[~ilyak], I believe that if cache with corresponding name still exists after 
restart (either because it's configured statically on server startup, or 
because persistence is used), proxy should continue to provide access to this 
cache. Configuration will be changed rarely in this case, but even if it does 
change, I don't see much harm. If there are any specific scenarios that would 
not work properly with this approach, can you please share them?

If cache doesn't exist after restart, exception is obviously correct behavior, 
although the message should be more clear I think.

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Updated] (IGNITE-7482) Cursor in TextQuery fetches all data in first call to next() or hasNext()

[Zbyszek B (JIRA)]

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

Zbyszek B updated IGNITE-7482:
--
Description: 
In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query in 
line 285 one executes query: 
 docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
 TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
used to implement cursor advancing. This causes the issues with 10 mln. 
entities  when (depending on term) execution takes way above 7 sec. to retrieve 
first row, hence making it impossible to use TextQuery to implement 
auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.

  was:
In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query in 
line 285 one executes query: 
 docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
 TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
used to implement cursor advancing. This causes the issues with 10 mln. 
entities  when (depending on term) execution takes way above 7 sec. to retrieve 
first row, hence making this impossible to use TextQuery to implement 
auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.


> Cursor in TextQuery fetches all data in first call to next() or hasNext()
> -
>
> Key: IGNITE-7482
> URL: https://issues.apache.org/jira/browse/IGNITE-7482
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Zbyszek B
>Priority: Major
>
> In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query 
> in line 285 one executes query: 
>  docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
> fetched and deserialised regardless the size of the cursor.
>  TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
> used to implement cursor advancing. This causes the issues with 10 mln. 
> entities  when (depending on term) execution takes way above 7 sec. to 
> retrieve first row, hence making it impossible to use TextQuery to implement 
> auto-complete.
> See 
> [http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
>  for more details.



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

[jira] [Updated] (IGNITE-7482) Cursor in TextQuery fetches all data in first call to next() or hasNext()

[Zbyszek B (JIRA)]

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

Zbyszek B updated IGNITE-7482:
--
Description: 
In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query in 
line 285 one executes query: 
 docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
 TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
used to implement cursor advancing. This causes the issues with 10 mln. 
entities  when (depending on term) execution takes way above 7 sec. to retrieve 
first row, hence making this impossible to use TextQuery to implement 
auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.

  was:
In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query in 
line 285 one executes query: 
 docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
 TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
used to implement cursor advancing. This causes the issues with 10 mln. 
entities  when (depending 
 on term) execution takes way above 7 sec. to retrieve first row, hence making 
this impossible to use TextQuery to implement auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.


> Cursor in TextQuery fetches all data in first call to next() or hasNext()
> -
>
> Key: IGNITE-7482
> URL: https://issues.apache.org/jira/browse/IGNITE-7482
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Zbyszek B
>Priority: Major
>
> In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query 
> in line 285 one executes query: 
>  docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
> fetched and deserialised regardless the size of the cursor.
>  TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
> used to implement cursor advancing. This causes the issues with 10 mln. 
> entities  when (depending on term) execution takes way above 7 sec. to 
> retrieve first row, hence making this impossible to use TextQuery to 
> implement auto-complete.
> See 
> [http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
>  for more details.



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

[jira] [Updated] (IGNITE-7482) Cursor in TextQuery fetches all data in first call to next() or hasNext()

[Zbyszek B (JIRA)]

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

Zbyszek B updated IGNITE-7482:
--
Description: 
In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query in 
line 285 one executes query: 
 docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
 TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
used to implement cursor advancing. This causes the issues with 10 mln. 
entities  when (depending 
 on term) execution takes way above 7 sec. to retrieve first row, hence making 
this impossible to use TextQuery to implement auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.

  was:
In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query 
in line 285 one executes query 
docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not used 
to implement cursor advancing. This causes the issues with 10 mln. entities  
when (depending 
on term) execution takes way above 7 sec. to retrieve first row, hence making 
this impossible to use TextQuery to implement auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.


> Cursor in TextQuery fetches all data in first call to next() or hasNext()
> -
>
> Key: IGNITE-7482
> URL: https://issues.apache.org/jira/browse/IGNITE-7482
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Zbyszek B
>Priority: Major
>
> In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query 
> in line 285 one executes query: 
>  docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
> fetched and deserialised regardless the size of the cursor.
>  TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not 
> used to implement cursor advancing. This causes the issues with 10 mln. 
> entities  when (depending 
>  on term) execution takes way above 7 sec. to retrieve first row, hence 
> making this impossible to use TextQuery to implement auto-complete.
> See 
> [http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
>  for more details.



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

[jira] [Created] (IGNITE-7482) Cursor in TextQuery fetches all data in first call to next() or hasNext()

[Zbyszek B (JIRA)]

Zbyszek B created IGNITE-7482:
-

 Summary: Cursor in TextQuery fetches all data in first call to 
next() or hasNext()
 Key: IGNITE-7482
 URL: https://issues.apache.org/jira/browse/IGNITE-7482
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.3
Reporter: Zbyszek B


In org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex#query 
in line 285 one executes query 
docs = searcher.search(query, Integer.MAX_VALUE)  what causes all data to be 
fetched and deserialised regardless the size of the cursor.
TopDocs searchAfter(final ScoreDoc after, Query query, int numHits) is not used 
to implement cursor advancing. This causes the issues with 10 mln. entities  
when (depending 
on term) execution takes way above 7 sec. to retrieve first row, hence making 
this impossible to use TextQuery to implement auto-complete.

See 
[http://apache-ignite-users.70518.x6.nabble.com/Cursor-in-TextQuery-first-hasNex-is-slow-td19265.html]
 for more details.



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

[jira] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov edited comment on IGNITE-6711 at 1/19/18 5:19 PM:
---

[~avinogradov], it looks more elegant now, after you removed redundant mapping 
from data regions to their allocation counters.


was (Author: andrey-kuznetsov):
[~avinogradov], it look more elegant now, after you removed redundant mapping 
from data regions to their allocation counters.

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6711:
--

[~avinogradov], it look more elegant now, after you removed redundant mapping 
from data regions to their allocation counters.

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Created] (IGNITE-7481) Suspended transaction rollbacs incorrectly

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7481:


 Summary: Suspended transaction rollbacs incorrectly  
 Key: IGNITE-7481
 URL: https://issues.apache.org/jira/browse/IGNITE-7481
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


When we suspend transaction, and then timeout occures , transaction would be 
rollbacked incorrectly.
One of incorrect behaviors : rollback\end tx metrics are not incremented.
Thre reason is that transactionMap is cleared when we suspend transaction.
We need not clear transactionMap.




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

[jira] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6711 at 1/19/18 4:30 PM:
---

[~andrey-kuznetsov]

I've refactored code, please check changes at 
[https://github.com/apache/ignite/pull/3409]

https://reviews.ignite.apache.org/ignite/review/IGNT-CR-469


was (Author: avinogradov):
[~andrey-kuznetsov]

I've refactored code, please check changes at 
https://github.com/apache/ignite/pull/3409

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6711 at 1/19/18 4:30 PM:
---

[~andrey-kuznetsov]

I've refactored code, please check changes at 
https://github.com/apache/ignite/pull/3409


was (Author: avinogradov):
I've refactored 

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6711:
--

I've refactored 

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6711:


GitHub user anton-vinogradov opened a pull request:

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

IGNITE-6711 DataRegionMetrics#totalAllocatedPages is not valid after …

…node restart

Signed-off-by: Anton Vinogradov 

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

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

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

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


commit 7ae5135ec7e5e496a10526b380f078316d527ab5
Author: Anton Vinogradov 
Date:   2018-01-19T16:27:50Z

IGNITE-6711 DataRegionMetrics#totalAllocatedPages is not valid after node 
restart

Signed-off-by: Anton Vinogradov 




> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



--
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=16332465#comment-16332465
 ] 

Alexey Popov commented on IGNITE-7191:
--

[~ptupitsyn] , I run some benchmarks and check wireshark logs with different 
socket size options.

0 (default) works as ~ 256k with a good network at Win client and Linux server. 
So, it seems that this improvement is not required for modern OSs.

I will double check the results later.

> 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] [Commented] (IGNITE-7477) Ignite.NET does not work on Java 9

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7477:


1) JNI options can't contain spaces. Spaces should be replaced with {{=}}.
2) Java 8 fails to start with these new options. We should detect version.

> Ignite.NET does not work on Java 9
> --
>
> Key: IGNITE-7477
> URL: https://issues.apache.org/jira/browse/IGNITE-7477
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Ignite.NET does not work properly on Java 9 (IGNITE-6730).
> Some additional JVM settings are required:
> {code}
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
> java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
> java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
> jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
> {code}



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

[jira] [Commented] (IGNITE-7278) Node failed to recover partition from WAL on unstable topology

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7278:


GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-7278-2



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

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

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

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


commit 9755dd25022082be9ce7e175aeeab57e4a614373
Author: Dmitriy Govorukhin 
Date:   2018-01-19T15:12:54Z

IGNITE-7278 fix page corruption on node restart

commit 2c2345fb97a2e8d7c0da7711b3c5198ee076dc69
Author: Dmitriy Govorukhin 
Date:   2018-01-19T15:16:58Z

Merge branch 'master' into ignite-7278-2




> Node failed to recover partition from WAL on unstable topology
> --
>
> Key: IGNITE-7278
> URL: https://issues.apache.org/jira/browse/IGNITE-7278
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Dmitriy Govorukhin
>Priority: Blocker
> Fix For: 2.4
>
> Attachments: page_corrupted2.tar.gz
>
>
> The use case is:
> -Grid with partitioned cache with 2 backups (or replicated)
> -Node-1 is killed in the middle of checkpoint and started again.
> -Node-1 detects unfinished checkpoint and tries to recover it.
> -At this point Node-2 is killed while node-1 recovering is in progress.
> -Node-1 fails with AssertionError.
> PFA logs, parsed WAL, reproducer.
> Can be reproduced with IgnitePdsContinuousRestartTest with minor changes,
> we have to have 2 nodes flapping and kill nodes ungracefully.



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

[jira] [Commented] (IGNITE-7475) Improve VerifyBackupPartitionsTask to calculate partition hashes in multiple threads

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-7475:


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

> Improve VerifyBackupPartitionsTask to calculate partition hashes in multiple 
> threads
> 
>
> Key: IGNITE-7475
> URL: https://issues.apache.org/jira/browse/IGNITE-7475
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
>
> Currently, compute task VerifyBackupPartitionsTask calculates all hashes in 
> ComputeJob#execute caller thread. Using multiple threads can bring 
> significant speedup.



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

[jira] [Commented] (IGNITE-7475) Improve VerifyBackupPartitionsTask to calculate partition hashes in multiple threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7475:


GitHub user glukos opened a pull request:

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

IGNITE-7475 Improve VerifyBackupPartitionsTask to calculate partition 
hashes in multiple threads



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

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

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

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


commit 6192ef51d2b57c1c65f75a737a64050f5a0c
Author: Ivan Rakov 
Date:   2018-01-19T11:59:03Z

IGNITE-7475 Improve VerifyBackupPartitionsTask to calculate partition 
hashes in multiple threads

commit e852187626430b7e67a11ae15e59406db0406be4
Author: Ivan Rakov 
Date:   2018-01-19T13:07:29Z

IGNITE-7475 Fixed not returning emptyMap

commit 5ab65c4ff5d04e5c2b126c9546643b9ada2db5f5
Author: Ivan Rakov 
Date:   2018-01-19T14:01:17Z

IGNITE-7475 Added cancellation for failed computation




> Improve VerifyBackupPartitionsTask to calculate partition hashes in multiple 
> threads
> 
>
> Key: IGNITE-7475
> URL: https://issues.apache.org/jira/browse/IGNITE-7475
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
>
> Currently, compute task VerifyBackupPartitionsTask calculates all hashes in 
> ComputeJob#execute caller thread. Using multiple threads can bring 
> significant speedup.



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

[jira] [Commented] (IGNITE-6341) Use direct IO or libaio for file page store where applicable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6341:


Github user dspavlov closed the pull request at:

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


> Use direct IO or libaio for file page store where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for page store because once data buffer 
> is serialized, we can write it as disk pages (this will also make it easier 
> if we decide to open file as a block device).



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

[jira] [Created] (IGNITE-7480) Select for BINARY type field returns 'strange' value.

[Alex Volkov (JIRA)]

Alex Volkov created IGNITE-7480:
---

 Summary: Select for BINARY type field returns 'strange' value.
 Key: IGNITE-7480
 URL: https://issues.apache.org/jira/browse/IGNITE-7480
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.2
Reporter: Alex Volkov


Steps to reproduce:
 # Connect to grid using console client and dbc:ignite:thin driver.
 # Run these sql statements:

{code:java}
CREATE TABLE tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, '00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, 'ffccaa');
SELECT * FROM tmp_table_binary;
{code}
Here is output from H2:
{code:java}
SELECT * FROM tmp_table_binary;

KEY_FIELD   FIELD1  
1   00ffaa
2   ffccaa
{code}
And this one is from grid:
{code}
 0: jdbc:ignite:thin://127.0.0.1/> CREATE TABLE tmp_table_binary (key_field INT 
PRIMARY KEY,field1 BINARY);
No rows affected (0.155 seconds)
0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO tmp_table_binary (key_field, 
field1) values(1, '00ffaa');
1 row affected (0.089 seconds)
0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO tmp_table_binary (key_field, 
field1) values(2, 'ffccaa');
1 row affected (0.009 seconds)
0: jdbc:ignite:thin://127.0.0.1/> SELECT * FROM tmp_table_binary;
+++
|   KEY_FIELD| FIELD1 |
+++
| 1  | [B@6219232f|
| 2  | [B@605514f9|
+++
2 rows selected (0.09 seconds)
0: jdbc:ignite:thin://127.0.0.1/> {code}



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

[jira] [Created] (IGNITE-7479) NOT NULL constraints for complex PK

[Alex Volkov (JIRA)]

Alex Volkov created IGNITE-7479:
---

 Summary: NOT NULL constraints for complex PK
 Key: IGNITE-7479
 URL: https://issues.apache.org/jira/browse/IGNITE-7479
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Alex Volkov


According to SQL ANSI 99 spec (11.7  point 5)

If the < unique specification > specifies PRIMARY KEY, then for each < column 
name > in the explicit or implicit < unique column list > for which NOT NULL is 
not specified, NOT NULL is implicit in the < column definition >.

But now we have violation:

 
{code:java}
0: jdbc:ignite:thin://127.0.0.1:10800/> create table 
tmp_table_age_name_wage_complex_pk (key_field INT,AGE INT,field1 VARCHAR,field2 
INT,PRIMARY KEY (key_field, AGE, field1));
SQL: create table tmp_table_age_name_wage_complex_pk (key_field INT,AGE 
INT,field1 VARCHAR,field2 INT,PRIMARY KEY (key_field, AGE, field1))
No rows affected (0.129 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> insert into 
tmp_table_age_name_wage_complex_pk (key_field,AGE,field1,field2) values (11, 
null,'John',3);
SQL: insert into tmp_table_age_name_wage_complex_pk 
(key_field,AGE,field1,field2) values (11, null,'John',3)
1 row affected (0.121 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> select * from 
tmp_table_age_name_wage_complex_pk;
SQL: select * from tmp_table_age_name_wage_complex_pk
IN IncrementalRows 4
+++++
|   KEY_FIELD|  AGE   | 
FIELD1 | FIELD2 |
+++++
| 11 | null   | John
   | 3  |
+++++
1 row selected (0.04 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> 
{code}
The same SQL script with H2 BD got:

 
{code:java}
create table tmp_table_age_name_wage_complex_pk (key_field INT,AGE INT,field1 
VARCHAR,field2 INT,PRIMARY KEY (key_field, AGE, field1));
Update count: 0
(1 ms)

insert into tmp_table_age_name_wage_complex_pk (key_field,AGE,field1,field2) 
values (11, null,'John',3);
NULL not allowed for column "AGE"; SQL statement:
insert into tmp_table_age_name_wage_complex_pk (key_field,AGE,field1,field2) 
values (11, null,'John',3) [23502-195] 23502/23502
{code}



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

[jira] [Updated] (IGNITE-7479) NOT NULL constraints for complex PK

[Alex Volkov (JIRA)]

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

Alex Volkov updated IGNITE-7479:

Affects Version/s: 2.2

> NOT NULL constraints for complex PK
> ---
>
> Key: IGNITE-7479
> URL: https://issues.apache.org/jira/browse/IGNITE-7479
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.2
>Reporter: Alex Volkov
>Priority: Minor
>
> According to SQL ANSI 99 spec (11.7  point 5)
> If the < unique specification > specifies PRIMARY KEY, then for each < column 
> name > in the explicit or implicit < unique column list > for which NOT NULL 
> is not specified, NOT NULL is implicit in the < column definition >.
> But now we have violation:
>  
> {code:java}
> 0: jdbc:ignite:thin://127.0.0.1:10800/> create table 
> tmp_table_age_name_wage_complex_pk (key_field INT,AGE INT,field1 
> VARCHAR,field2 INT,PRIMARY KEY (key_field, AGE, field1));
> SQL: create table tmp_table_age_name_wage_complex_pk (key_field INT,AGE 
> INT,field1 VARCHAR,field2 INT,PRIMARY KEY (key_field, AGE, field1))
> No rows affected (0.129 seconds)
> 0: jdbc:ignite:thin://127.0.0.1:10800/> insert into 
> tmp_table_age_name_wage_complex_pk (key_field,AGE,field1,field2) values (11, 
> null,'John',3);
> SQL: insert into tmp_table_age_name_wage_complex_pk 
> (key_field,AGE,field1,field2) values (11, null,'John',3)
> 1 row affected (0.121 seconds)
> 0: jdbc:ignite:thin://127.0.0.1:10800/> select * from 
> tmp_table_age_name_wage_complex_pk;
> SQL: select * from tmp_table_age_name_wage_complex_pk
> IN IncrementalRows 4
> +++++
> |   KEY_FIELD|  AGE   |   
>   FIELD1 | FIELD2 |
> +++++
> | 11 | null   | John  
>  | 3  |
> +++++
> 1 row selected (0.04 seconds)
> 0: jdbc:ignite:thin://127.0.0.1:10800/> 
> {code}
> The same SQL script with H2 BD got:
>  
> {code:java}
> create table tmp_table_age_name_wage_complex_pk (key_field INT,AGE INT,field1 
> VARCHAR,field2 INT,PRIMARY KEY (key_field, AGE, field1));
> Update count: 0
> (1 ms)
> insert into tmp_table_age_name_wage_complex_pk (key_field,AGE,field1,field2) 
> values (11, null,'John',3);
> NULL not allowed for column "AGE"; SQL statement:
> insert into tmp_table_age_name_wage_complex_pk (key_field,AGE,field1,field2) 
> values (11, null,'John',3) [23502-195] 23502/23502
> {code}



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

[jira] [Comment Edited] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova edited comment on IGNITE-7403 at 1/19/18 1:52 PM:


[~dsetrakyan] [~dmagda]  take a look please.  


was (Author: vabramova):
[~dsetrakyan] [~dmagda]  take a look please.  !What_v3.png!

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Comment Edited] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova edited comment on IGNITE-7403 at 1/19/18 1:52 PM:


[~dsetrakyan] [~dmagda]  take a look please.  !What_v3.png!


was (Author: vabramova):
[~dsetrakyan] [~dmagda]  take a look please.

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Commented] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova commented on IGNITE-7403:
---

[~dsetrakyan] [~dmagda]  take a look please.

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Updated] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-7403:
--
Attachment: What_v3.png

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Commented] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7117:


Github user asfgit closed the pull request at:

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


> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Resolved] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7117.

Resolution: Fixed

> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Commented] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7117:


Cherry-picked to ignite-2.4: {{25e91b60694c589d8bf50c63a0d898ca4180b428}}.

> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Commented] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7117:


Merged to master: {{c305b91318789150ac898dd8bd74d944baf4e90d}}.

> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Created] (IGNITE-7478) Too many HistoryAffinityAssignments in HistAffAssignmentsCache

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7478:


 Summary: Too many HistoryAffinityAssignments in 
HistAffAssignmentsCache
 Key: IGNITE-7478
 URL: https://issues.apache.org/jira/browse/IGNITE-7478
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Alexander Belyak


Get throuble with GC, found over 26k instances of

org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment with 
about 12Gb of: ArrayList->Object[]->ArrayList->Object[] but can't find 
ClusterNode objects there!



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

[jira] [Commented] (IGNITE-7477) Ignite.NET does not work on Java 9

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7477:


Note: we still compile Ignite on Java 8, but should be able to run under Java 9.

> Ignite.NET does not work on Java 9
> --
>
> Key: IGNITE-7477
> URL: https://issues.apache.org/jira/browse/IGNITE-7477
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Ignite.NET does not work properly on Java 9 (IGNITE-6730).
> Some additional JVM settings are required:
> {code}
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
> java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
> java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
> jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
> {code}



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

[jira] [Updated] (IGNITE-7477) Ignite.NET does not work on Java 9

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7477:
---
Description: 
Ignite.NET does not work properly on Java 9 (IGNITE-6730).
Some additional JVM settings are required:

{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
{code}

  was:
When jars are compiled with Java 9 (IGNITE-6730), Ignite.NET does not work 
properly.
Some additional JVM settings are required:

{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
{code}


> Ignite.NET does not work on Java 9
> --
>
> Key: IGNITE-7477
> URL: https://issues.apache.org/jira/browse/IGNITE-7477
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Ignite.NET does not work properly on Java 9 (IGNITE-6730).
> Some additional JVM settings are required:
> {code}
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
> java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
> java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
> jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
> {code}



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

[jira] [Updated] (IGNITE-7477) Ignite.NET does not work on Java 9

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7477:
---
Description: 
When jars are compiled with Java 9 (IGNITE-6730), Ignite.NET does not work 
properly.
Some additional JVM settings are required:

{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
{code}

  was:
When jars are compiled with Java 9, Ignite.NET does not work properly.
Some additional JVM settings are required:

{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
{code}


> Ignite.NET does not work on Java 9
> --
>
> Key: IGNITE-7477
> URL: https://issues.apache.org/jira/browse/IGNITE-7477
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> When jars are compiled with Java 9 (IGNITE-6730), Ignite.NET does not work 
> properly.
> Some additional JVM settings are required:
> {code}
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
> java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
> java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
> jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
> {code}



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

[jira] [Created] (IGNITE-7477) Ignite.NET does not work on Java 9

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7477:
--

 Summary: Ignite.NET does not work on Java 9
 Key: IGNITE-7477
 URL: https://issues.apache.org/jira/browse/IGNITE-7477
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


When jars are compiled with Java 9, Ignite.NET does not work properly.
Some additional JVM settings are required:

{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports 
java.base/sun.nio.ch=ALL-UNNAMED --add-exports 
java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports 
jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
{code}



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

[jira] [Resolved] (IGNITE-7473) .NET: "Could not load file or assembly ConfigurationManager" error on Linux

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7473.

Resolution: Won't Fix

> .NET: "Could not load file or assembly ConfigurationManager" error on Linux
> ---
>
> Key: IGNITE-7473
> URL: https://issues.apache.org/jira/browse/IGNITE-7473
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Steps to reproduce:
> {code}
> dotnet new console
> dotnet add package Apache.Ignite
> nano Program.cs  # Add Ignition.Start() line and a namespace import
> dotnet run
> {code}
> Error:
> {code}
> Unhandled Exception: System.IO.FileNotFoundException: Could not load file or 
> assembly 'System.Configuration.ConfigurationManager, Version=0.0.0.0, 
> Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the 
> file specified.
> {code}
> Works on Windows, does not work on Linux.
> {{ Version="4.4.0" />}} is required to fix the issue.
> However, {{ConfigurationManager}} is not necessary for code configuration, we 
> should be able to start without it.



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

[jira] [Comment Edited] (IGNITE-7473) .NET: "Could not load file or assembly ConfigurationManager" error on Linux

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7473 at 1/19/18 1:02 PM:
-

Looks like there is no way to fix this issue in code. Core CLR attempts to load 
that assembly right at the start, not lazily. No code is executed before that.
See https://github.com/dotnet/standard/issues/506.


was (Author: ptupitsyn):
Looks like there is no way to fix this issue in code. Core CLR attempts to load 
that assembly right at the start.
See https://github.com/dotnet/standard/issues/506.

> .NET: "Could not load file or assembly ConfigurationManager" error on Linux
> ---
>
> Key: IGNITE-7473
> URL: https://issues.apache.org/jira/browse/IGNITE-7473
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Steps to reproduce:
> {code}
> dotnet new console
> dotnet add package Apache.Ignite
> nano Program.cs  # Add Ignition.Start() line and a namespace import
> dotnet run
> {code}
> Error:
> {code}
> Unhandled Exception: System.IO.FileNotFoundException: Could not load file or 
> assembly 'System.Configuration.ConfigurationManager, Version=0.0.0.0, 
> Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the 
> file specified.
> {code}
> Works on Windows, does not work on Linux.
> {{ Version="4.4.0" />}} is required to fix the issue.
> However, {{ConfigurationManager}} is not necessary for code configuration, we 
> should be able to start without it.



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

[jira] [Commented] (IGNITE-7473) .NET: "Could not load file or assembly ConfigurationManager" error on Linux

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7473:


Looks like there is no way to fix this issue in code. Core CLR attempts to load 
that assembly right at the start.
See https://github.com/dotnet/standard/issues/506.

> .NET: "Could not load file or assembly ConfigurationManager" error on Linux
> ---
>
> Key: IGNITE-7473
> URL: https://issues.apache.org/jira/browse/IGNITE-7473
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Steps to reproduce:
> {code}
> dotnet new console
> dotnet add package Apache.Ignite
> nano Program.cs  # Add Ignition.Start() line and a namespace import
> dotnet run
> {code}
> Error:
> {code}
> Unhandled Exception: System.IO.FileNotFoundException: Could not load file or 
> assembly 'System.Configuration.ConfigurationManager, Version=0.0.0.0, 
> Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the 
> file specified.
> {code}
> Works on Windows, does not work on Linux.
> {{ Version="4.4.0" />}} is required to fix the issue.
> However, {{ConfigurationManager}} is not necessary for code configuration, we 
> should be able to start without it.



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

[jira] [Commented] (IGNITE-7454) Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7454:


Github user asfgit closed the pull request at:

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


> Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203
> -
>
> Key: IGNITE-7454
> URL: https://issues.apache.org/jira/browse/IGNITE-7454
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.4
>
>
> Wrong package in IgniteExamplesMLTestSuite after it was moved per 
> IGNITE-7203: \{{org.apache.ignite.ml.testsuites}}. Also, it is not added to 
> the list in {{IgniteExamplesSelfTestSuite{{ which is supposed to run all 
> examples self-tests.
> Change to correct package: \{{org.apache.ignite.testsuites}} and add to main 
> testsuite.
> For the sake of completeness, a bunch of newer ml benchmarks (done per 
> IGNITE-7214 and IGNITE-7097) were forgotten to be moved in yardstick module 
> when merging to master. These should be fixed (moved to proper folder).



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

[jira] [Updated] (IGNITE-7476) Server node will join with failure gathering metrics

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-7476:

Description: 
Sometimes server node will fail with the following trace:
{code:java}
SEVERE: TcpDiscoverSpi's message worker thread failed abnormally. Stopping the 
node in order to prevent cluster wide instability.
java.lang.NullPointerException
    at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1149)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5022)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2690)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2491)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6675)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2574)
    at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62){code}
Two problems here:
 * Uncaught exception in cacheMetrics() leads to unconditional failure of node, 
because it happens to be in discovery thread. Should probably wrap all 
non-trivial code include try-catch.
 * Lack of proper locking when destroying cache (see also IGNITE-6580, 
IGNITE-7278 and IGNITE-7165)

 

  was:
Sometimes server node will fail with the following trace:
{code:java}
SEVERE: TcpDiscoverSpi's message worker thread failed abnormally. Stopping the 
node in order to prevent cluster wide instability.
java.lang.NullPointerException
    at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1149)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5022)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2690)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2491)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6675)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2574)
    at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62){code}
Two problems here:
 * Uncaught exception in cacheMetrics() leads to unconditional failure of node, 
because it happens to be in discovery thread. Should probably wrap all 
non-trivial code include try-catch.
 * Lack of proper locking when destroying cache (see also IGNITE-6423 and 
IGNITE-7165)

 


> Server node will join with failure gathering metrics
> 
>
> Key: IGNITE-7476
> URL: https://issues.apache.org/jira/browse/IGNITE-7476
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Kasnacheev
>Priority: Critical
>
> Sometimes server node will fail with the following trace:
> {code:java}
> SEVERE: TcpDiscoverSpi's message worker thread failed abnormally. Stopping 
> the node in order to prevent cluster wide instability.
> java.lang.NullPointerException
>     at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1149)
>     at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5022)
>     at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2690)
>     at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2491)
>     at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6675)
>     at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2574)
>     at 
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62){code}
> Two problems here:
>  * Uncaught exception in cacheMetrics() leads to unconditional failure of 
> node, because it happens to be in discovery thread. Should probably wrap all 
> non-trivial code include try-catch.
>  * Lack of proper locking when destroying cache (see also IGNITE-6580, 
> IGNITE-7278 and IGNITE-7165)
>  



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

[jira] [Commented] (IGNITE-6810) ODBC: Add secure connection support

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6810:
--

[~isapego], java part is OK with me.

> ODBC: Add secure connection support
> ---
>
> Key: IGNITE-6810
> URL: https://issues.apache.org/jira/browse/IGNITE-6810
> Project: Ignite
>  Issue Type: New Feature
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc
> Fix For: 2.5
>
> Attachments: new-ui.png
>
>
> Need to add support of SSL/TLS for ODBC.



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

[jira] [Created] (IGNITE-7476) Server node will join with failure gathering metrics

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7476:
---

 Summary: Server node will join with failure gathering metrics
 Key: IGNITE-7476
 URL: https://issues.apache.org/jira/browse/IGNITE-7476
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Kasnacheev


Sometimes server node will fail with the following trace:
{code:java}
SEVERE: TcpDiscoverSpi's message worker thread failed abnormally. Stopping the 
node in order to prevent cluster wide instability.
java.lang.NullPointerException
    at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1149)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5022)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2690)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2491)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6675)
    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2574)
    at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62){code}
Two problems here:
 * Uncaught exception in cacheMetrics() leads to unconditional failure of node, 
because it happens to be in discovery thread. Should probably wrap all 
non-trivial code include try-catch.
 * Lack of proper locking when destroying cache (see also IGNITE-6423 and 
IGNITE-7165)

 



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

[jira] [Created] (IGNITE-7475) Improve VerifyBackupPartitionsTask to calculate partition hashes in multiple threads

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-7475:
--

 Summary: Improve VerifyBackupPartitionsTask to calculate partition 
hashes in multiple threads
 Key: IGNITE-7475
 URL: https://issues.apache.org/jira/browse/IGNITE-7475
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Rakov
Assignee: Ivan Rakov


Currently, compute task VerifyBackupPartitionsTask calculates all hashes in 
ComputeJob#execute caller thread. Using multiple threads can bring significant 
speedup.



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

[jira] [Created] (IGNITE-7474) Exception on accessing sys cache when node joins topology with service

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7474:
---

 Summary: Exception on accessing sys cache when node joins topology 
with service
 Key: IGNITE-7474
 URL: https://issues.apache.org/jira/browse/IGNITE-7474
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.3
Reporter: Ilya Kasnacheev


Sometimes when node joins to a cluster with service configured, it will get the 
following exception:
{code:java}
Exception in thread "sys-#1071" java.lang.IllegalArgumentException: Cache is 
not configured: ignite-sys-cache
    at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3423)
    at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:770)
    at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:742)
    at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:696)
    at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1110)
    at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1600(GridContinuousProcessor.java:103)
    at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$7.onMessage(GridContinuousProcessor.java:755)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:126)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2751)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1515)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:126)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1484)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
{code}
Seems to be a race condition. I will try to provide test case later.



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

[jira] [Updated] (IGNITE-6917) SQL: implement COPY command for efficient data loading

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-6917:

Description: 
Inspired by Postgres [1]

Common use case - bulk data load through JDBC/ODBC interface. Currently it is 
only possible to execute single commands one by one. We already can batch them 
to improve performance, but there is still big room for improvement.

We should think of a completely new command - {{COPY}}. It will accept a file 
(or input stream in general case) on the client side, then transfer data to the 
cluster, and then execute update inside the cluster, e.g. through streamer.

First of all we need to create quick and dirty prototype to assess potential 
performance improvement. It speedup is confirmed, we should build base 
implementation which will accept only files. But at the same time we should 
understand how it will evolve in future: multiple file formats (probably 
including Hadoop formarts, e.g. Parquet), escape characters, input streams, 
etc..

[1] [https://www.postgresql.org/docs/9.6/static/sql-copy.html]
h1. Proposed syntax

Curent implementation:
{noformat}
COPY 
FROM "file.name"
INTO .
[(col-name, ...)]
FORMAT  -- Only CSV format is supported in the current 
release
{noformat}
We may want to gradually add features to this command in future to have 
something like this:
{noformat}
COPY
FROM 'file.name' [CHARSET ]
INTO . [CREATE [IF NOT EXISTS]]
[(REPLACE|IGNORE|ABORT ON [])) EXISTING ROWS]
[(col-name [] [NULLABLE] [ESCAPES], ...) [MATCH HEADER]]
FORMAT (csv|tsv|...)

-- CSV format options:
[COLSEP='column-separator']
[ROWSEP='row-separators']
[QUOTE='quote-char']
[ESCAPE='escape-char']
[NULL='null-sequence']

[ROWS -]
--or--
[SKIP ROWS ] [MAX ROWS ]

[COLS -]
--or--
[SKIP COLS ] [MAX COLS ]

[MATCH HEADER ROW]
[BATCH ( ROWS |  (KB|MB|GB))]
[LOCK (TABLE|ROWS)]
[NOLOGGING] 
{noformat}

h1. Implementation decisions and notes

h2. Parsing

* We support CSV format described in RFC 4180.
* Custom row and column separators, quoting characters are currently hardcoded
* Escape sequences, line comment characters are currently not supported
* We may want to support fixed-length formats (via format descriptors) in future

h2. File handling

* File character set to be supported in future
* Skipped/imported row number (or first/last line or skip header option), 
skipped/imported column number (or first/last column): to be supported in future
* Line start pattern (as in MySQL): no support planned
* We currently support only client-side import. No server-side file import.
* We may want to support client-side stdin import in future.
* We do not handle importing multiple files from single command
* We don't benefit from any kind of pre-sorting pre-partitioning data on client 
side.
* We don't include any any metadata, such as line number from client side.

h3. Transferring data

* We send file data via batches. In future we will support batch size 
(specified with rows per batch or data block size 
per batch).
* We may want to implement data compression in future.
* We connect to single node in JDBC driver (no multi-node connections).

h3. Cache/tables/column handling

* We don't create table in the bulk load command
* We may want to have and option for reading header row, which contains column 
names to match columns
* In future we may wish to support COLUMNS (col1, _, col2, _, col3) syntax, 
where '_' marker means a skipped column (MySQL uses '@dummy' for this)

h3. Data types

* Data types are converted as if they were supplied to INSERT SQL command.
* We may want type conversion (automatic, custom using sql function, custom via 
Java code, string auto-trimming) in future.
* We will support optional null sequence ("\N") later
* We may want to allow user to specify what to do if the same record exists 
(e.g., ignore record, replace it, report error with a max. error counter before 
failing the command)
* We don't currently support any generated/autoincremented row IDs or any 
custom generators.
* We don't support any filtering/conditional expressions
* We don't support any files/recordsets/tables with multiple conversion errors 
generated during import.

h3. Transactional / MVCC / other
* We don't use transactions
* We don't create locks on rows or tables.
* We don't try to minimize any indexing overhead (it's up to the user)
* We may want to minimize WAL impact in future via NOLOGGING option.

h3. Miscellanea

* We don't supply an utility to load data
* We don't currently supply any java loaders (as in PG and MSSQL) that stream 
data (not neccessary from file)
* Security-related questions are out of scope of this JIRA
* We don't have triggers and constraints in Apache Ignite

h1. Implementations from other vendors
h2. PostgreSQL
{noformat}
COPY table_name [ ( column_name [, ...] ) ]

[jira] [Updated] (IGNITE-6917) SQL: implement COPY command for efficient data loading

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-6917:

Description: 
Inspired by Postgres [1]

Common use case - bulk data load through JDBC/ODBC interface. Currently it is 
only possible to execute single commands one by one. We already can batch them 
to improve performance, but there is still big room for improvement.

We should think of a completely new command - {{COPY}}. It will accept a file 
(or input stream in general case) on the client side, then transfer data to the 
cluster, and then execute update inside the cluster, e.g. through streamer.

First of all we need to create quick and dirty prototype to assess potential 
performance improvement. It speedup is confirmed, we should build base 
implementation which will accept only files. But at the same time we should 
understand how it will evolve in future: multiple file formats (probably 
including Hadoop formarts, e.g. Parquet), escape characters, input streams, 
etc..

[1] [https://www.postgresql.org/docs/9.6/static/sql-copy.html]
h1. Proposed syntax

Curent implementation:
{noformat}
COPY 
FROM "file.name"
INTO .
[ (col-name, ...)]
FORMAT  -- Only CSV format is supported in the current 
release
{noformat}
We may want to gradually add features to this command in future to have 
something like this:
{noformat}
COPY
FROM 'file.name' [CHARSET ]
INTO . [CREATE [IF NOT EXISTS]]
[(REPLACE|IGNORE|ABORT ON [])) EXISTING ROWS]
[(col-name [] [NULLABLE] [ESCAPES], ...) [MATCH HEADER]]
FORMAT (csv|tsv|...)

-- CSV format options:
[COLSEP='column-separator']
[ROWSEP='row-separators']
[QUOTE='quote-char']
[ESCAPE='escape-char']
[NULL='null-sequence']

[ROWS -]
--or--
[SKIP ROWS ] [MAX ROWS ]

[COLS -]
--or--
[SKIP COLS ] [MAX COLS ]

[MATCH HEADER ROW]
[BATCH ( ROWS |  (KB|MB|GB))]
[LOCK (TABLE|ROWS)]
[NOLOGGING] 
{noformat}

h1. Implementation decisions and notes

h2. Parsing

* We support CSV format described in RFC 4180.
* Custom row and column separators, quoting characters are currently hardcoded
* Escape sequences, line comment characters are currently not supported
* We may want to support fixed-length formats (via format descriptors) in future

h2. File handling

* File character set to be supported in future
* Skipped/imported row number (or first/last line or skip header option), 
skipped/imported column number (or first/last column): to be supported in future
* Line start pattern (as in MySQL): no support planned
* We currently support only client-side import. No server-side file import.
* We may want to support client-side stdin import in future.
* We do not handle importing multiple files from single command
* We don't benefit from any kind of pre-sorting pre-partitioning data on client 
side.
* We don't include any any metadata, such as line number from client side.

h3. Transferring data

* We send file data via batches. In future we will support batch size 
(specified with rows per batch or data block size 
per batch).
* We may want to implement data compression in future.
* We connect to single node in JDBC driver (no multi-node connections).

h3. Cache/tables/column handling

* We don't create table in the bulk load command
* We may want to have and option for reading header row, which contains column 
names to match columns
* In future we may wish to support COLUMNS (col1, _, col2, _, col3) syntax, 
where '_' marker means a skipped column (MySQL uses '@dummy' for this)

h3. Data types

* Data types are converted as if they were supplied to INSERT SQL command.
* We may want type conversion (automatic, custom using sql function, custom via 
Java code, string auto-trimming) in future.
* We will support optional null sequence ("\N") later
* We may want to allow user to specify what to do if the same record exists 
(e.g., ignore record, replace it, report error with a max. error counter before 
failing the command)
* We don't currently support any generated/autoincremented row IDs or any 
custom generators.
* We don't support any filtering/conditional expressions
* We don't support any files/recordsets/tables with multiple conversion errors 
generated during import.

h3. Transactional / MVCC / other
* We don't use transactions
* We don't create locks on rows or tables.
* We don't try to minimize any indexing overhead (it's up to the user)
* We may want to minimize WAL impact in future via NOLOGGING option.

h3. Miscellanea

* We don't supply an utility to load data
* We don't currently supply any java loaders (as in PG and MSSQL) that stream 
data (not neccessary from file)
* Security-related questions are out of scope of this JIRA
* We don't have triggers and constraints in Apache Ignite

h1. Implementations from other vendors
h2. PostgreSQL
{noformat}
COPY table_name [ ( column_name [, ...] ) ]

[jira] [Commented] (IGNITE-7024) Introduce some kind of network compression

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita commented on IGNITE-7024:
-

Test's result for more details.
When SSL turn on: 
Throughput real case:
||Type||MsgSize||MsgPerSecond||RealMbitsPerSecond||EffectiveMbitsPerSecond||CompressionRatio||
|Ssl|1000|12434.04 ∈ [11453.98 : 13597.52]|107.13 ∈ [98.69 : 117.16]|99.47 ∈ 
[91.63 : 108.78]|1.01|
|SslLZ4|1000|12260.02 ∈ [11162.28 : 13597.23]|64.83 ∈ [59.03 : 71.90]|98.08 ∈ 
[89.30 : 108.78]|1.74|
|SslZSTD|1000|10922.77 ∈ [9995.12 : 12040.24]|42.38 ∈ [38.78 : 46.72]|87.38 ∈ 
[79.96 : 96.32]|2.50|
|SslDeflater|1000|9573.60 ∈ [8880.29 : 10384.33]|32.24 ∈ [29.91 : 34.97]|76.59 
∈ [71.04 : 83.07]|2.98|
|Ssl|2000|10376.92 ∈ [9607.20 : 11280.72]|173.09 ∈ [160.25 : 188.16]|166.03 ∈ 
[153.72 : 180.49]|1.00|
|SslLZ4|2000|10939.95 ∈ [9992.80 : 12085.45]|101.26 ∈ [92.49 : 111.86]|175.04 ∈ 
[159.88 : 193.37]|1.87|
|SslZSTD|2000|9064.78 ∈ [8309.85 : 9970.59]|50.26 ∈ [46.07 : 55.28]|145.04 ∈ 
[132.96 : 159.53]|3.29|
|SslDeflater|2000|7364.64 ∈ [6844.94 : 7969.74]|38.00 ∈ [35.32 : 41.12]|117.83 
∈ [109.52 : 127.52]|3.57|
|Ssl|3000|7895.27 ∈ [7334.58 : 8548.78]|194.35 ∈ [180.55 : 210.44]|189.49 ∈ 
[176.03 : 205.17]|1.00|
|SslLZ4|3000|9727.40 ∈ [8858.76 : 10784.92]|128.64 ∈ [117.15 : 142.62]|233.46 ∈ 
[212.61 : 258.84]|1.91|
|SslZSTD|3000|8275.49 ∈ [7585.25 : 9103.94]|57.53 ∈ [52.73 : 63.29]|198.61 ∈ 
[182.05 : 218.49]|3.83|
|SslDeflater|3000|6791.48 ∈ [6333.30 : 7321.14]|47.21 ∈ [44.03 : 50.90]|163.00 
∈ [152.00 : 175.71]|3.83|
|Ssl|5000|5465.96 ∈ [5080.05 : 5915.34]|222.01 ∈ [206.33 : 240.26]|218.64 ∈ 
[203.20 : 236.61]|1.00|
|SslLZ4|5000|6425.34 ∈ [5898.79 : 7055.10]|137.61 ∈ [126.33 : 151.09]|257.01 ∈ 
[235.95 : 282.20]|1.93|
|SslZSTD|5000|6175.36 ∈ [5690.16 : 6751.03]|62.69 ∈ [57.77 : 68.54]|247.01 ∈ 
[227.61 : 270.04]|4.22|
|SslDeflater|5000|4922.25 ∈ [4606.83 : 5284.03]|51.23 ∈ [47.95 : 55.00]|196.89 
∈ [184.27 : 211.36]|4.11|
|Ssl|1|3546.55 ∈ [3291.77 : 3844.08]|286.14 ∈ [265.58 : 310.14]|283.72 ∈ 
[263.34 : 307.53]|1.00|
|SslLZ4|1|4314.30 ∈ [3952.27 : 4749.34]|182.41 ∈ [167.10 : 200.80]|345.14 ∈ 
[316.18 : 379.95]|1.92|
|SslZSTD|1|4218.97 ∈ [3891.14 : 4607.13]|75.77 ∈ [69.88 : 82.74]|337.52 ∈ 
[311.29 : 368.57]|4.63|
|SslDeflater|1|2444.24 ∈ [2290.03 : 2620.72]|47.03 ∈ [44.06 : 50.42]|195.54 
∈ [183.20 : 209.66]|4.31|
|Ssl|3|1314.17 ∈ [1223.03 : 1420.00]|317.02 ∈ [295.03 : 342.55]|315.40 ∈ 
[293.53 : 340.80]|1.00|
|SslLZ4|3|1696.90 ∈ [1559.00 : 1861.55]|211.19 ∈ [194.03 : 231.68]|407.26 ∈ 
[374.16 : 446.77]|1.94|
|SslZSTD|3|1817.29 ∈ [1678.92 : 1980.50]|88.47 ∈ [81.73 : 96.41]|436.15 ∈ 
[402.94 : 475.32]|5.00|
|SslDeflater|3|1101.61 ∈ [1034.52 : 1178.00]|59.27 ∈ [55.66 : 63.38]|264.39 
∈ [248.29 : 282.72]|4.52|
|Ssl|6|953.59 ∈ [888.05 : 1029.57]|459.95 ∈ [428.34 : 496.60]|457.72 ∈ 
[426.26 : 494.20]|1.00|
|SslLZ4|6|1235.80 ∈ [1133.05 : 1359.05]|307.50 ∈ [281.93 : 338.16]|593.18 ∈ 
[543.86 : 652.34]|1.93|
|SslZSTD|6|1325.92 ∈ [1224.18 : 1446.10]|128.41 ∈ [118.56 : 140.05]|636.44 
∈ [587.61 : 694.13]|4.99|
|SslDeflater|6|826.40 ∈ [777.07 : 882.42]|88.71 ∈ [83.41 : 94.72]|396.67 ∈ 
[372.99 : 423.56]|4.50|
|Ssl|10|602.58 ∈ [518.65 : 718.92]|484.47 ∈ [416.99 : 578.00]|482.06 ∈ 
[414.92 : 575.13]|1.00|
|SslLZ4|10|895.29 ∈ [822.77 : 981.83]|372.12 ∈ [341.97 : 408.09]|716.23 ∈ 
[658.21 : 785.46]|1.93|
|SslZSTD|10|957.23 ∈ [884.54 : 1042.94]|155.76 ∈ [143.93 : 169.71]|765.78 ∈ 
[707.63 : 834.35]|4.94|
|SslDeflater|10|551.96 ∈ [519.03 : 589.35]|99.14 ∈ [93.23 : 105.86]|441.57 
∈ [415.22 : 471.48]|4.47|
|Ssl|50|191.65 ∈ [178.44 : 206.98]|769.86 ∈ [716.78 : 831.43]|766.60 ∈ 
[713.75 : 827.92]|1.00|
|SslLZ4|50|239.46 ∈ [220.09 : 262.56]|498.21 ∈ [457.92 : 546.28]|957.82 ∈ 
[880.36 : 1050.23]|1.92|
|SslZSTD|50|251.98 ∈ [232.86 : 274.51]|202.90 ∈ [187.51 : 221.05]|1007.90 ∈ 
[931.45 : 1098.03]|4.97|
|SslDeflater|50|140.10 ∈ [131.75 : 149.57]|124.74 ∈ [117.30 : 
133.18]|560.38 ∈ [526.99 : 598.29]|4.50|
|Ssl|100|88.52 ∈ [82.50 : 95.49]|711.13 ∈ [662.76 : 767.12]|708.14 ∈ 
[659.97 : 763.89]|1.00|
|SslLZ4|100|125.46 ∈ [115.32 : 137.56]|522.53 ∈ [480.29 : 572.91]|1003.68 ∈ 
[922.55 : 1100.46]|1.92|
|SslZSTD|100|127.87 ∈ [117.55 : 140.19]|205.79 ∈ [189.17 : 225.60]|1022.99 
∈ [940.40 : 1121.48]|4.97|
|SslDeflater|100|73.22 ∈ [68.91 : 78.11]|130.17 ∈ [122.50 : 138.86]|585.76 
∈ [551.26 : 624.87]|4.50|
|Ssl|500|20.03 ∈ [18.62 : 21.67]|804.48 ∈ [747.91 : 870.31]|801.12 ∈ 
[744.78 : 866.68]|1.00|
|SslLZ4|500|24.94 ∈ [22.92 : 27.35]|519.13 ∈ [477.07 : 569.33]|997.54 ∈ 
[916.71 : 1093.99]|1.92|
|SslZSTD|500|25.85 ∈ [23.87 : 28.20]|207.78 ∈ [191.83 : 226.63]|1034.08 ∈ 
[954.69 : 1127.87]|4.98|
|SslDeflater|500|14.68 ∈ [13.79 : 15.70]|130.38 ∈ [122.45 : 139.41]|587.31 
∈ [551.59 : 627.98]|4.50|
|Ssl|1000|9.88 ∈ [9.19 

[jira] [Commented] (IGNITE-7024) Introduce some kind of network compression

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7024:


GitHub user NSAmelchev reopened a pull request:

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

IGNITE-7024



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

$ git pull https://github.com/NSAmelchev/ignite comress-with-ssl

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

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


commit 11424e9eeefc8fe1b8575623c18a8d565a376ab9
Author: NSAmelchev 
Date:   2017-11-28T14:25:13Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit ba4086e282b1a78fac6e0e9832eb02d6f428250f
Author: NSAmelchev 
Date:   2017-11-10T07:42:24Z

draft

commit 15566a4f91bdcad117ef2b76b202531ae2ad91e4
Author: NSAmelchev 
Date:   2017-11-20T13:15:40Z

compressV2.

commit f7162f96b36f2756ecf63000192ee7facbce0e77
Author: NSAmelchev 
Date:   2017-11-21T13:24:46Z

change size of buffers

commit bcc43b501700958fce927250b1b76bfb2511a328
Author: NSAmelchev 
Date:   2017-11-28T11:07:38Z

draft

commit 6a5df699fea2a5cf53a097571c7206720fbbcd29
Author: NSAmelchev 
Date:   2017-11-30T07:37:52Z

some fix

commit 6343f08f2e74054cbe0c656c4d7a933a165e023d
Author: NSAmelchev 
Date:   2017-12-06T16:54:58Z

some fix

commit ea687fb1b299cacc432f96c1b894a40108a4a6b8
Author: NSAmelchev 
Date:   2017-12-07T11:20:44Z

some fix

commit f0496708fc39de787b0eedf5343bc8565fb46e68
Author: NSAmelchev 
Date:   2017-12-07T11:48:44Z

for tests

commit ceb0ce44e5882f295c9b75ee2e7d5feae7ae519c
Author: NSAmelchev 
Date:   2017-12-08T07:18:43Z

proceedSessionOpened on not_handshaking

commit 655a85a7f72fdac5f98dab241140359da303bfdd
Author: NSAmelchev 
Date:   2017-12-08T14:30:48Z

default disable compresss and ssl

commit 106d0608bace7b80e0d328abef4f0b53068a1930
Author: NSAmelchev 
Date:   2017-12-11T16:20:06Z

refactor TcpCommunicationSpi

commit db037e2bca7db4c2d34395e537c7d7c22f9e06b1
Author: Alexander Menshikov 
Date:   2017-12-06T14:38:13Z

remove some null checks

commit c8d2f2fb16f501c34fe6fa079e5518035bfe35d3
Author: Alexander Menshikov 
Date:   2017-12-07T17:34:01Z

refactoring...

commit 0e58441a820974629b08b03f9e14d78d7e234806
Author: Alexander Menshikov 
Date:   2017-12-07T17:59:13Z

refactoring

commit db5b8b1c9cb44f361b75d55fd2a5c49b5f5ca1c7
Author: Alexander Menshikov 
Date:   2017-12-07T18:57:31Z

pam-pam)

commit 87f708013498e52af26afb47a92024e4cc86ad52
Author: Alexander Menshikov 
Date:   2017-12-08T09:46:33Z

add optimization for no-filters mode

commit 8f155640ffc9fd039efc5ff756338ed2fb911777
Author: Alexander Menshikov 
Date:   2017-12-08T10:58:02Z

fix bug

commit 5a69ae1cb0fb32cc607dc42c6c7944677a27eb99
Author: Alexander Menshikov 
Date:   2017-12-11T18:12:02Z

Fix bugs

commit a5fb4a0e0b55545005008c32a4fa5242192c5fc4
Author: Alexander Menshikov 
Date:   2017-12-12T12:11:56Z

refactoring

commit ac86ba1661705d17fa8dd7f15042c762c4ba7a31
Author: NSAmelchev 
Date:   2017-12-12T12:18:16Z

Merge pull request #17 from NSAmelchev/ignite-net-compress-2

Ignite net compress 2

commit 745f518963ede54e17f563a961d4cf0e5d783393
Author: NSAmelchev 
Date:   2017-12-12T13:36:46Z

some refactor

commit 3e1a372b6ec75cd10e99890977f6bcaedf15479a
Author: NSAmelchev 
Date:   2017-12-13T10:00:21Z

workaround for ssl deadlock on close and receive

commit 56f01874eb4fe1efbf9cf6579b12593660a81ceb
Author: NSAmelchev 
Date:   2017-12-13T15:48:49Z

use new format in deflater. Add small msg flag to gzip

commit 111d4e0caddda948a1be484b25f227d1e01e2add
Author: Alexander Menshikov 
Date:   2017-12-13T16:27:20Z

add benchmarks

commit f14aa409f8326b088caab84979cfc6d41d1b18aa
Author: NSAmelchev 
Date:   2017-12-14T08:34:41Z

Merge remote-tracking branch 'origin/test-comress-with-ssl' into 
comress-with-ssl

commit 054e14caa0df0875f642d10c74a6a65551a914db
Author: NSAmelchev 
Date:   2017-12-14T12:45:58Z

reuse deflateBaos

commit deb771ce916a53a6380892fc97af2eba2370ec4f
Author: NSAmelchev 
Date:   2017-12-14T13:14:00Z

optimize gzip

commit 0eb9f6e4af822d07c4ebd250e7106e4d617618fa
Author: NSAmelchev 
Date:   

[jira] [Created] (IGNITE-7473) .NET: "Could not load file or assembly ConfigurationManager" error on Linux

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7473:
--

 Summary: .NET: "Could not load file or assembly 
ConfigurationManager" error on Linux
 Key: IGNITE-7473
 URL: https://issues.apache.org/jira/browse/IGNITE-7473
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


Steps to reproduce:

{code}
dotnet new console
dotnet add package Apache.Ignite
nano Program.cs  # Add Ignition.Start() line and a namespace import
dotnet run
{code}

Error:
{code}
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or 
assembly 'System.Configuration.ConfigurationManager, Version=0.0.0.0, 
Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the 
file specified.
{code}

Works on Windows, does not work on Linux.
{{}} is required to fix the issue.

However, {{ConfigurationManager}} is not necessary for code configuration, we 
should be able to start without it.



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

[jira] [Commented] (IGNITE-7278) Node failed to recover partition from WAL on unstable topology

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-7278:
-

We have located at least one reason for "Failed to get page IO instance" errors:
{code:java}
Failed to get page store for the given cache ID (cache has not been started): 
-244919260
 at 
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:619)
 at 
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:272)
 at 
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:259)
 at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:613){code}
There looks to be 2 thing wrong:
 * Insufficient locking on cache delete.
 * Exceptions in acquirePage leading to data corruption on disk.

> Node failed to recover partition from WAL on unstable topology
> --
>
> Key: IGNITE-7278
> URL: https://issues.apache.org/jira/browse/IGNITE-7278
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Dmitriy Govorukhin
>Priority: Blocker
> Fix For: 2.4
>
> Attachments: page_corrupted2.tar.gz
>
>
> The use case is:
> -Grid with partitioned cache with 2 backups (or replicated)
> -Node-1 is killed in the middle of checkpoint and started again.
> -Node-1 detects unfinished checkpoint and tries to recover it.
> -At this point Node-2 is killed while node-1 recovering is in progress.
> -Node-1 fails with AssertionError.
> PFA logs, parsed WAL, reproducer.
> Can be reproduced with IgnitePdsContinuousRestartTest with minor changes,
> we have to have 2 nodes flapping and kill nodes ungracefully.



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

[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-2766:
-

"Client node was reconnected after it was already considered failed by the 
server topology (this could happen after all servers restarted or due to a long 
network outage between the client and servers). All continuous queries and 
remote event listeners created by this client will be unsubscribed, consider 
listening to EVT_CLIENT_NODE_RECONNECTED event to restore them."

I guess that means cache proxies are no longer good either.

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Created] (IGNITE-7472) Exchange initiated by custom disco events could hang in case of coordinator leave

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7472:
---

 Summary: Exchange initiated by custom disco events could hang in 
case of coordinator leave
 Key: IGNITE-7472
 URL: https://issues.apache.org/jira/browse/IGNITE-7472
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Vladimir Ozerov
 Fix For: 2.5


Reproducer: {{WalModeChangeAdvancedSelfTest.testServerRestartCoordinator}}

WAL mode change operation initiates an exchange through custom discovery event. 
The test does the following:
1) Initiate constant flow of such events from one node
2) Constantly stops current coordinator node and start another one sever node 

Debug shows the following:
1) Remaining client nodes is on exchange X, waiting for new coordinator to send 
affinity message
2) New coordinator is on exchange [X+1], waiting for client to send partition 
message



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

[jira] [Updated] (IGNITE-6386) Introduction of distributed neural networks.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6386:

Fix Version/s: (was: 2.5)
   2.4

> Introduction of distributed neural networks.
> 
>
> Key: IGNITE-6386
> URL: https://issues.apache.org/jira/browse/IGNITE-6386
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>Priority: Major
>  Labels: important
> Fix For: 2.4
>
>
> We want to have deep learning algorithms and for this we need to implement 
> neural network over Apache Ignite. Currently we think about using 
> [dl4j|https://deeplearning4j.org] as backend but in this case we cannot  
> train one model over multiple nodes efficiently. Also we will think about 
> integration/connector with dl4j.



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

[jira] [Resolved] (IGNITE-6744) Java 9: create TC infrastructure to run unit tests

[Peter Ivanov (JIRA)]

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

Peter Ivanov resolved IGNITE-6744.
--
Resolution: Fixed

Prepare [Ignite Tests 2.4+ \[Java 
9\]|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java9] 
build.

> Java 9: create TC infrastructure to run unit tests
> --
>
> Key: IGNITE-6744
> URL: https://issues.apache.org/jira/browse/IGNITE-6744
> Project: Ignite
>  Issue Type: Task
>  Components: build
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.4
>
>
> We need to be able to test Ignite on both Java 7/8 and Java 9 on out CI 
> server.



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

[jira] [Assigned] (IGNITE-6744) Java 9: create TC infrastructure to run unit tests

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6744:
---

Assignee: Peter Ivanov

> Java 9: create TC infrastructure to run unit tests
> --
>
> Key: IGNITE-6744
> URL: https://issues.apache.org/jira/browse/IGNITE-6744
> Project: Ignite
>  Issue Type: Task
>  Components: build
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.4
>
>
> We need to be able to test Ignite on both Java 7/8 and Java 9 on out CI 
> server.



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

[jira] [Assigned] (IGNITE-7064) Web console: implement mechanism to manage E2E tests environment

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7064:
-

Assignee: Ilya Borisov  (was: Alexander Kalinin)

> Web console: implement mechanism to manage E2E tests environment
> 
>
> Key: IGNITE-7064
> URL: https://issues.apache.org/jira/browse/IGNITE-7064
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> Most of E2E tests require complex DB/web-agent/Ignite cluster state 
> management. Let's implement tools to help with that, maybe something easy at 
> first, like DB state. Web console backend already has a similar mechanism we 
> can reuse.



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

[jira] [Comment Edited] (IGNITE-7064) Web console: implement mechanism to manage E2E tests environment

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin edited comment on IGNITE-7064 at 1/19/18 9:36 AM:


[~Klaster_1] Devnotes update with instructions on how to run tests and 
environment separately. Please review.


was (Author: alexdel):
[~Klaster_1] Devnotes update with instructions on how to run tests and 
environment separately.

> Web console: implement mechanism to manage E2E tests environment
> 
>
> Key: IGNITE-7064
> URL: https://issues.apache.org/jira/browse/IGNITE-7064
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> Most of E2E tests require complex DB/web-agent/Ignite cluster state 
> management. Let's implement tools to help with that, maybe something easy at 
> first, like DB state. Web console backend already has a similar mechanism we 
> can reuse.



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

[jira] [Commented] (IGNITE-7064) Web console: implement mechanism to manage E2E tests environment

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-7064:
---

[~Klaster_1] Devnotes update with instructions on how to run tests and 
environment separately.

> Web console: implement mechanism to manage E2E tests environment
> 
>
> Key: IGNITE-7064
> URL: https://issues.apache.org/jira/browse/IGNITE-7064
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> Most of E2E tests require complex DB/web-agent/Ignite cluster state 
> management. Let's implement tools to help with that, maybe something easy at 
> first, like DB state. Web console backend already has a similar mechanism we 
> can reuse.



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

[jira] [Commented] (IGNITE-3690) Log Message Glossary

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin commented on IGNITE-3690:


As it was discussed on dev list 
(http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-not-friendly-for-Monitoring-tt20802.html#none)
let's split this activity into two steps and reserver next error ranges for the 
domains:
 
-- the phase 1
1. 1-10499 UnExpected, UnKnown 
2. 10500-12499 Cluster and Topology
  10500-10599 Discovery
  10600-10699 Segmentation
  10700-10799 Node Startup
  10800-10899 Communication
  10900-10999 Queue
  11000-11099 Activate, startup process
  11100-11199 Base line topology
  11200-11299 Marshaller
  11300-11399 Metadata
  11400-11499 Topology Validate
3. 12500-14199 Cache and Storage
  12500-12599 Partition map exchange
  12600-12699 Balancing
  12700-12799 Long-running transactions
  12800-12899 Checkpoint
  12900-12999 Create cache
  13000-13099 Destroy cache
  13100-13199 Data loading & streaming
4. 14200-15699 SQL
  14200-14299 Long-running queries
  14300-14399 Parsing
  14400-14499 Queries
  14500-14599 Scan Queries
  14600-14699 SqlLine
5. 15700-17099 Compute
  15700-15799 Deployment
  15800-15899 spi.checkpoint
  15900-15999 spi.collision
  11600-16099 Job Schedule

-- the phase 2
6. 17100-19199 Service
7. 19200-21199 Security
8. 21200-23199 ML
9. 23200-25199 Integrations
10. 25200-27199 WebConsole
11. 27200-29199 Vendor-Specific
  27200-27299 GG

FYI: [~dmagda]

> Log Message Glossary
> 
>
> Key: IGNITE-3690
> URL: https://issues.apache.org/jira/browse/IGNITE-3690
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> It's time for Ignite to create a page which lists ALL the log messages, their 
> common causes and potential solutions.
> Probably it makes sense to assign an unique ID for the most well-know errors 
> so that a user is able to look up an error in the glossary quicker.



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

[jira] [Commented] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7117:


Fixed: rely solely on {{libs/ignite-core-*.jar}} presence for binary releases 
and {{modules/core/src/main/java/org/apache/ignite}} for source release.
Waiting for TC, need to check on different platforms (win/linux, .NET/.NET 
Core/Mono).

> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Comment Edited] (IGNITE-2766) Cache instance is closed when client disconnects

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev edited comment on IGNITE-2766 at 1/19/18 9:28 AM:
--

No, I still don't get it.

-New Ignite cluster just doesn't have the 'TEST' cache.-

Even if it did, it would be a different cache (if not for persistence). 
Eventually with a different cache config. I will try to update the test with a 
working example.


was (Author: ilyak):
No, I still don't get it.

New Ignite cluster just doesn't have the 'TEST' cache.

Even if it did, it would be a different cache (if not for persistence). 
Eventually with a different cache config. I will try to update the test with a 
working example.

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-2766:
-

No, I still don't get it.

New Ignite cluster just doesn't have the 'TEST' cache.

Even if it did, it would be a different cache (if not for persistence). 
Eventually with a different cache config. I will try to update the test with a 
working example.

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Comment Edited] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7117 at 1/19/18 9:26 AM:
-

GitHub user ptupitsyn opened a pull request:

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

IGNITE-7117 .NET: Improve IgniteHome resolver



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

$ git pull https://github.com/ptupitsyn/ignite ignite-7117

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

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


was (Author: githubbot):
GitHub user ptupitsyn opened a pull request:

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

IGNITE-7117 .NET: Improve IgniteHome resolver



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

$ git pull https://github.com/ptupitsyn/ignite ignite-7117

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

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


commit e575d58f1bccd0a928e0a281c397a4dbaa737f8f
Author: Pavel Tupitsyn 
Date:   2018-01-19T08:40:18Z

IGNITE-7117 .NET: Classpath resolver relies on Java examples

commit 899295efc9c63b7876c143e37d05d6fe28e47392
Author: Pavel Tupitsyn 
Date:   2018-01-19T09:05:09Z

wip

commit 177fc20087f450fce1e00e1e8b51b3ea0b6b0252
Author: Pavel Tupitsyn 
Date:   2018-01-19T09:18:51Z

Add source release resolver




> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-2766:
-

Yes, now I can see what is the real issue. It is as follows:
{code:java}
Exception in thread "main" java.lang.IllegalStateException: class 
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to 
perform cache operation (cache is stopped): TEST
    at 
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
    at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
    at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:659)
    at ReconnectClient.main(ReconnectClient.java:36)
Caused by: class 
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to 
perform cache operation (cache is stopped): TEST
    ... 4 more{code}
while IgniteClientDisconnectedException is expected!

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Commented] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7117:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-7117 .NET: Improve IgniteHome resolver



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

$ git pull https://github.com/ptupitsyn/ignite ignite-7117

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

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


commit e575d58f1bccd0a928e0a281c397a4dbaa737f8f
Author: Pavel Tupitsyn 
Date:   2018-01-19T08:40:18Z

IGNITE-7117 .NET: Classpath resolver relies on Java examples

commit 899295efc9c63b7876c143e37d05d6fe28e47392
Author: Pavel Tupitsyn 
Date:   2018-01-19T09:05:09Z

wip

commit 177fc20087f450fce1e00e1e8b51b3ea0b6b0252
Author: Pavel Tupitsyn 
Date:   2018-01-19T09:18:51Z

Add source release resolver




> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Updated] (IGNITE-7337) Spark Data Frames: support saving a data frame in Ignite

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7337:

Fix Version/s: (was: 2.4)
   2.5

> Spark Data Frames: support saving a data frame in Ignite
> 
>
> Key: IGNITE-7337
> URL: https://issues.apache.org/jira/browse/IGNITE-7337
> Project: Ignite
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Once Ignite data source for Spark is implemented, we need to add an ability 
> to store a data frame in Ignite. Most likely if should be enough to provide 
> implementation for the following traits:
> * {{InsertableRelation}}
> * {{CreatableRelationProvider}}



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

[jira] [Updated] (IGNITE-5849) Introduce ignite node persistent meta-store

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-5849:
-
Labels: IEP-4 Phase-1 important  (was: IEP-4 important)

> Introduce ignite node persistent meta-store
> ---
>
> Key: IGNITE-5849
> URL: https://issues.apache.org/jira/browse/IGNITE-5849
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: IEP-4, Phase-1, important
> Fix For: 2.4
>
>
> As persistence feature is being developed, we will have a need for a 
> component, which reliably stores arbitrary metadata about node and cluster.
> We already have reserved partition IDs for this purpose, all we need to do is 
> to extend the partition store abstraction to store non-cache objects and make 
> sure this new store participates in all common recovery procedures.



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

[jira] [Updated] (IGNITE-5849) Introduce ignite node persistent meta-store

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-5849:
-
Labels: IEP-13 important  (was: important)

> Introduce ignite node persistent meta-store
> ---
>
> Key: IGNITE-5849
> URL: https://issues.apache.org/jira/browse/IGNITE-5849
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: IEP-4, important
> Fix For: 2.4
>
>
> As persistence feature is being developed, we will have a need for a 
> component, which reliably stores arbitrary metadata about node and cluster.
> We already have reserved partition IDs for this purpose, all we need to do is 
> to extend the partition store abstraction to store non-cache objects and make 
> sure this new store participates in all common recovery procedures.



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

[jira] [Updated] (IGNITE-5849) Introduce ignite node persistent meta-store

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-5849:
-
Labels: IEP-4 important  (was: IEP-13 important)

> Introduce ignite node persistent meta-store
> ---
>
> Key: IGNITE-5849
> URL: https://issues.apache.org/jira/browse/IGNITE-5849
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: IEP-4, important
> Fix For: 2.4
>
>
> As persistence feature is being developed, we will have a need for a 
> component, which reliably stores arbitrary metadata about node and cluster.
> We already have reserved partition IDs for this purpose, all we need to do is 
> to extend the partition store abstraction to store non-cache objects and make 
> sure this new store participates in all common recovery procedures.



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

[jira] [Updated] (IGNITE-7047) NPE from org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7047:

Fix Version/s: (was: 2.4)
   2.5

> NPE from 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn
> 
>
> Key: IGNITE-7047
> URL: https://issues.apache.org/jira/browse/IGNITE-7047
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
> Fix For: 2.5
>
>
> NPE happens sometimes at heavy load after receiving 
> GridDhtTxOnePhaseCommitAckRequest, no more details
> ERROR 11/25/17 17:39:28 [::sys-stripe-2-#3%null%] cache.GridCacheIoManager> 
> Failed processing message [senderId=0393e394-09a9-4c02-b33e-fb4d99c3539f, 
> msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersi
> on [topVer=123129570, order=1511649564004, nodeOrder=2]], 
> super=GridCacheMessage [msgId=95, depInfo=null, err=null, skipPrepare=false]]]
> java.lang.NullPointerException
> at 
> org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
> at java.lang.Thread.run(Thread.java:745)
> ERROR 11/25/17 17:39:28 [::sys-stripe-14-#15%null%] cache.GridCacheIoManager> 
> Failed processing message [senderId=52c4ced0-49f3-4075-9b2f-7d619adf6d33, 
> msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion 
> [topVer=123129570, order=1511649564004, nodeOrder=4]], super=GridCacheMessage 
> [msgId=97, depInfo=null, err=null, skipPrepare=false]]]
> java.lang.NullPointerException
> at 
> org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Updated] (IGNITE-6692) Select query on a client with unused field throws an exception.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6692:

Fix Version/s: (was: 2.4)
   2.5

> Select query on a client with unused field throws an exception.
> ---
>
> Key: IGNITE-6692
> URL: https://issues.apache.org/jira/browse/IGNITE-6692
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.2
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgniteClientQueryTest.java
>
>
> Steps to reproduce:
> 1. Run one server, one client.
> 2. Execute next queries on a client:
> {{CREATE TABLE t1 (name VARCHAR(1), unused LONG, PRIMARY KEY(name))}}
> {{INSERT INTO t1 (name) values ('A')}}
> 3. Run select that throws an exception: 
> {{SELECT name FROM t1 ORDER BY name, unused}}
> Test is in attachment. 



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

[jira] [Commented] (IGNITE-6692) Select query on a client with unused field throws an exception.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6692:
-

Duplicates IGNITE-7293 which is targeted for 2.5 release (some unexplained 
hangs in IGFS/Hadoop modules appeared in response to the change).

> Select query on a client with unused field throws an exception.
> ---
>
> Key: IGNITE-6692
> URL: https://issues.apache.org/jira/browse/IGNITE-6692
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.2
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgniteClientQueryTest.java
>
>
> Steps to reproduce:
> 1. Run one server, one client.
> 2. Execute next queries on a client:
> {{CREATE TABLE t1 (name VARCHAR(1), unused LONG, PRIMARY KEY(name))}}
> {{INSERT INTO t1 (name) values ('A')}}
> 3. Run select that throws an exception: 
> {{SELECT name FROM t1 ORDER BY name, unused}}
> Test is in attachment. 



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

[jira] [Updated] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5874:

Fix Version/s: (was: 2.4)
   2.5

> Store TTL expire times in B+ tree on per-partition basis
> 
>
> Key: IGNITE-5874
> URL: https://issues.apache.org/jira/browse/IGNITE-5874
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgnitePdsWithTtlTest.java
>
>
> TTL expire times for entries are stored in PendingEntriesTree, which is 
> singleton for cache. When expiration occurs, all system threads iterate 
> through the tree in order to remove expired entries. Iterating through single 
> tree causes contention and perfomance loss. 
> Related performance issue: https://issues.apache.org/jira/browse/IGNITE-5793
> We should keep instance of PendingEntriesTree for each partition, like we do 
> for CacheDataTree.



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

[jira] [Updated] (IGNITE-7347) Warning about page eviction, when persistence for different data region is enabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7347:

Fix Version/s: (was: 2.4)
   2.5

> Warning about page eviction, when persistence for different data region is 
> enabled
> --
>
> Key: IGNITE-7347
> URL: https://issues.apache.org/jira/browse/IGNITE-7347
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Trivial
> Fix For: 2.5
>
>
> Consider the following configuration:
> {noformat}
> 
> 
> 
> 
>  class="org.apache.ignite.configuration.DataRegionConfiguration">
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.configuration.DataRegionConfiguration">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {noformat}
> It leads to the following warning on start: *Page eviction mode for 
> \[B_Region\] memory region is ignored because Ignite Native Persistence is 
> enabled*.
> But page eviction is actually applied and work as expected.



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

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

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-6217:
-

{quote}Yes we need this{quote}
Added

{quote}I suggest to remove configuration for select ALL range for all SELECT 
benchmarks{quote}
Removed

The last thing before merge is to check these benchmarks on multi-host 
environment

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



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6802:

Fix Version/s: (was: 2.4)
   2.5

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



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

[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6445:

Fix Version/s: (was: 2.4)
   2.5

> IgniteTxManager.txLocksInfo method misses locks
> ---
>
> Key: IGNITE-6445
> URL: https://issues.apache.org/jira/browse/IGNITE-6445
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Fix For: 2.5
>
>
> In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) 
> misses locks.
> For example:
> # In case of a configuration with near cache, entries are created for the 
> near cache and for the ordinal cache. For each entry, their own MVCC 
> candidates are created.
> # For non-custom objects of type (Integer, etc.), the entry stored in 
> "GridNearTxLocal" is not associated with MVCC candidates with which the same 
> entity is associated in another format stored in "GridDhtTxLocal"



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

[jira] [Updated] (IGNITE-6521) Review default JVM options for better performance

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6521:

Fix Version/s: (was: 2.4)
   2.5

> Review default JVM options for better performance
> -
>
> Key: IGNITE-6521
> URL: https://issues.apache.org/jira/browse/IGNITE-6521
> Project: Ignite
>  Issue Type: Improvement
>  Components: general, visor
>Affects Versions: 2.1
>Reporter: Alexandr Kuramshin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>
> Non-optimal recommendations are present in ignite startup scrips
> {noformat}
> ::
> :: Uncomment the following GC settings if you see spikes in your throughput 
> due to Garbage Collection.
> ::
> :: set JVM_OPTS=%JVM_OPTS% -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
> -XX:+UseTLAB -XX:NewSize=128m -XX:MaxNewSize=128m
> :: set JVM_OPTS=%JVM_OPTS% -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=1024 
> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60
> {noformat}
> Some utilities (like Visor) are hanged up in continuous GCs when connected to 
> large clusters (above one hundred nodes). Even after using large heap (about 
> 32 Gb).
> I'd like to propose to remove this lines and modify default JVM_OPTS as 
> follows
> {noformat}
> set JVM_OPTS=-Xms1g -Xmx8g -XX:+UseG1GC -server -XX:+AggressiveOpts 
> -XX:MaxPermSize=256m
> {noformat}



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

[jira] [Updated] (IGNITE-6324) transactional cache data partially available after crash.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6324:

Fix Version/s: (was: 2.4)
   2.5

> transactional cache data partially available after crash.
> -
>
> Key: IGNITE-6324
> URL: https://issues.apache.org/jira/browse/IGNITE-6324
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.9, 2.1
>Reporter: Stanilovsky Evgeny
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
> Attachments: InterruptCommitedThreadTest.java
>
>
> If InterruptedException raise in client code during pds store operations we 
> can obtain inconsistent cache after restart. 



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6612:

Fix Version/s: (was: 2.4)
   2.5

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



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

[jira] [Updated] (IGNITE-4188) Savepoints support inside of Ignite Transactions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4188:

Fix Version/s: (was: 2.4)
   2.5

> Savepoints support inside of Ignite Transactions
> 
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.5
>
>
> A savepoint is a special mark inside a transaction that allows all commands 
> that are executed after it was established to be rolled back, restoring the 
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs 
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1); 
> SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (2); 
> ROLLBACK TO SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (3); 
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted 
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as 
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
> 
> tx.savepoint("mysavepoint");
> 
> c.put(2, 2);
> 
> tx.rollbackToSavepoint("mysavepoint");
> 
> c.put(3, 3);
> 
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with 
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the 
> savepoints have to differ from each other. If the current transaction has a 
> savepoint with the same name, the old savepoint is deleted and a new one is 
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done 
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the 
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC 
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html



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

[jira] [Updated] (IGNITE-6666) BinaryObjectImpl.writeFieldByOrder method does not support TIME

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-:

Fix Version/s: (was: 2.4)
   2.5

> BinaryObjectImpl.writeFieldByOrder method does not support TIME
> ---
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.2
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.5
>
>
> The variable totalLen is not define for TIME in method 
> BinaryObjectImpl.writeFieldByOrder.



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

[jira] [Assigned] (IGNITE-6666) BinaryObjectImpl.writeFieldByOrder method does not support TIME

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-:
---

Assignee: Vladimir Ozerov  (was: Amelchev Nikita)

> BinaryObjectImpl.writeFieldByOrder method does not support TIME
> ---
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.2
>Reporter: Amelchev Nikita
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> The variable totalLen is not define for TIME in method 
> BinaryObjectImpl.writeFieldByOrder.



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

[jira] [Commented] (IGNITE-6666) BinaryObjectImpl.writeFieldByOrder method does not support TIME

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-:
-

Moving to AI 2.5 due to scope freeze. Will review in the nearest time.

> BinaryObjectImpl.writeFieldByOrder method does not support TIME
> ---
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.2
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.4
>
>
> The variable totalLen is not define for TIME in method 
> BinaryObjectImpl.writeFieldByOrder.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6502:

Fix Version/s: (was: 2.4)
   2.5

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



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

[jira] [Updated] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5852:

Fix Version/s: (was: 2.4)
   2.5

> Cache affinity should be calculated wrt baseline topology
> -
>
> Key: IGNITE-5852
> URL: https://issues.apache.org/jira/browse/IGNITE-5852
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: IEP-4, Phase-1
> Fix For: 2.5
>
>
> After we have an API for baseline topology management, we need to provide a 
> way to operate when real topology differs from the baseline. To facilitate 
> this, we need to calculate the affinity on the set of nodes which is an 
> intersection of the baseline topology and current topology



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6531:

Fix Version/s: (was: 2.4)
   2.5

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



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5789:

Fix Version/s: (was: 2.4)
   2.5

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



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

[jira] [Updated] (IGNITE-5504) Failures in GridTcpCommunicationSpiRecoverySelfTest

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5504:

Fix Version/s: (was: 2.4)
   2.5

> Failures in GridTcpCommunicationSpiRecoverySelfTest
> ---
>
> Key: IGNITE-5504
> URL: https://issues.apache.org/jira/browse/IGNITE-5504
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vladimir Ozerov
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> Reproducible only on TeamCity.
> Affected tests:
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1}}
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead2}}
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead3}}
> Root cause:
> {code}
> [2017-06-14 18:16:30,016][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Failed to wait for session close
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1(GridTcpCommunicationSpiRecoverySelfTest.java:333)
> 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:1992)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:131)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1907)
> at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Commented] (IGNITE-7248) "Schema not found" error when setting streaming mode for JDBC driver

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7248:


Github user asfgit closed the pull request at:

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


> "Schema not found" error when setting streaming mode for JDBC driver
> 
>
> Key: IGNITE-7248
> URL: https://issues.apache.org/jira/browse/IGNITE-7248
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.4
>
>
> Using JDBC "thick" driver in streaming mode fails with a "Schema not found" 
> erorr:
> {code}
> Connection connection = 
> DriverManager.getConnection("jdbc:ignite:cfg://streaming=true:cache=CACHE@file:/path-to-ignite-config.xml");
> {code}
> using connection to create a table works fine but this exception is generated 
> when using the connection to execute INSER INTO...
> {code}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to set schema for DB connection for thread [schema=]
> org.h2.jdbc.JdbcSQLException: Schema  not found; SQL statement:
> SET SCHEMA "" [90079-195]
> {code}
> See [User 
> List|http://apache-ignite-users.70518.x6.nabble.com/Cannot-insert-data-into-table-using-JDBC-tc17477.html]
>  for more details



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

[jira] [Assigned] (IGNITE-7248) "Schema not found" error when setting streaming mode for JDBC driver

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-7248:
---

Assignee: Taras Ledkov  (was: Vladimir Ozerov)

> "Schema not found" error when setting streaming mode for JDBC driver
> 
>
> Key: IGNITE-7248
> URL: https://issues.apache.org/jira/browse/IGNITE-7248
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.4
>
>
> Using JDBC "thick" driver in streaming mode fails with a "Schema not found" 
> erorr:
> {code}
> Connection connection = 
> DriverManager.getConnection("jdbc:ignite:cfg://streaming=true:cache=CACHE@file:/path-to-ignite-config.xml");
> {code}
> using connection to create a table works fine but this exception is generated 
> when using the connection to execute INSER INTO...
> {code}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to set schema for DB connection for thread [schema=]
> org.h2.jdbc.JdbcSQLException: Schema  not found; SQL statement:
> SET SCHEMA "" [90079-195]
> {code}
> See [User 
> List|http://apache-ignite-users.70518.x6.nabble.com/Cannot-insert-data-into-table-using-JDBC-tc17477.html]
>  for more details



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

[jira] [Updated] (IGNITE-7248) "Schema not found" error when setting streaming mode for JDBC driver

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7248:

Component/s: jdbc

> "Schema not found" error when setting streaming mode for JDBC driver
> 
>
> Key: IGNITE-7248
> URL: https://issues.apache.org/jira/browse/IGNITE-7248
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.4
>
>
> Using JDBC "thick" driver in streaming mode fails with a "Schema not found" 
> erorr:
> {code}
> Connection connection = 
> DriverManager.getConnection("jdbc:ignite:cfg://streaming=true:cache=CACHE@file:/path-to-ignite-config.xml");
> {code}
> using connection to create a table works fine but this exception is generated 
> when using the connection to execute INSER INTO...
> {code}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to set schema for DB connection for thread [schema=]
> org.h2.jdbc.JdbcSQLException: Schema  not found; SQL statement:
> SET SCHEMA "" [90079-195]
> {code}
> See [User 
> List|http://apache-ignite-users.70518.x6.nabble.com/Cannot-insert-data-into-table-using-JDBC-tc17477.html]
>  for more details



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

[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6772:


Github user asfgit closed the pull request at:

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


> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real 
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT 
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1, 
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and 
> "orgs-sql".Organization.Name = ?
>   at 
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
>   at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
>   at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL 
> from Person1, "orgs-sql".Organization where Person.OrgId = 
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
>   at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
>   ... 2 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL 
> from Person1, "orgs-sql".Organization where Person.OrgId = 
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
>   ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL 
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1, 
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and 
> "orgs-sql".Organization.Name = ? [42102-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.command.Parser.readTableOrView(Parser.java:5506)
>   at org.h2.command.Parser.readTableFilter(Parser.java:1260)
>   at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
>   at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
>   at org.h2.command.Parser.parseSelectSub(Parser.java:1934)
>   at org.h2.command.Parser.parseSelectUnion(Parser.java:1749)
>   at org.h2.command.Parser.parseSelect(Parser.java:1737)
>   at org.h2.command.Parser.parsePrepared(Parser.java:448)
>   at org.h2.command.Parser.parse(Parser.java:320)
>   at org.h2.command.Parser.parse(Parser.java:292)
>   at org.h2.command.Parser.prepareCommand(Parser.java:257)
>   at org.h2.engine.Session.prepareLocal(Session.java:573)
>   at org.h2.engine.Session.prepareCommand(Session.java:514)
>   at 

[jira] [Updated] (IGNITE-7112) Non informative "Failed to wait for partition map exchange" message.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7112:

Fix Version/s: (was: 2.4)
   2.5

> Non informative "Failed to wait for partition map exchange" message.
> 
>
> Key: IGNITE-7112
> URL: https://issues.apache.org/jira/browse/IGNITE-7112
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Stanilovsky Evgeny
>Assignee: Semen Boikov
>Priority: Minor
> Fix For: 2.5
>
>
> Eventually can be observed "Failed to wait for partition map exchange" with 
> no further detalization info, due to code below.
> {code:java}
> final long futTimeout = 2 * cctx.gridConfig().getNetworkTimeout();
> long nextDumpTime = 0;
> while (true) {
> try {
> resVer = exchFut.get(futTimeout, TimeUnit.MILLISECONDS);
> break;
> }
> catch (IgniteFutureTimeoutCheckedException ignored) {
> U.warn(diagnosticLog, "Failed to wait for partition map exchange [" +
> ...
> if (nextDumpTime <= U.currentTimeMillis()) {
> try {
> dumpDebugInfo(exchFut);
> }
> catch (Exception e) {
> U.error(diagnosticLog, "Failed to dump debug information: " + e, e);
> }
> nextDumpTime = U.currentTimeMillis() + nextDumpTimeout(dumpCnt++, 
> futTimeout);
> }
> {code}



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

[jira] [Updated] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes

[Vladimir Ozerov (JIRA)]

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

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

> Need to make sure that scan query returns consistent results on topology 
> changes
> 
>
> Key: IGNITE-584
> URL: https://issues.apache.org/jira/browse/IGNITE-584
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: 1.9, 2.0, 2.1
>Reporter: Artem Shutak
>Assignee: Semen Boikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
> Attachments: tc1.png
>
>
> Consistent results on topology changes was implemented for sql queries, but 
> looks like it still does not work for scan queries.
> This affects 'cache set' tests since set uses scan query for set iteration 
> (to be unmuted on TC): 
> GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and 
> testNodeJoinsAndLeavesCollocated; 
> Also see todos here GridCacheSetFailoverAbstractSelfTest



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

[jira] [Assigned] (IGNITE-7471) Use soft reference for checkpoint entry contents to avoid excessive memory usage

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7471:


Assignee: Dmitriy Govorukhin  (was: Alexey Goncharuk)

> Use soft reference for checkpoint entry contents to avoid excessive memory 
> usage
> 
>
> Key: IGNITE-7471
> URL: https://issues.apache.org/jira/browse/IGNITE-7471
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Assigned] (IGNITE-7471) Use soft reference for checkpoint entry contents to avoid excessive memory usage

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7471:


Assignee: Alexey Goncharuk

> Use soft reference for checkpoint entry contents to avoid excessive memory 
> usage
> 
>
> Key: IGNITE-7471
> URL: https://issues.apache.org/jira/browse/IGNITE-7471
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Created] (IGNITE-7471) Use soft reference for checkpoint entry contents to avoid excessive memory usage

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7471:


 Summary: Use soft reference for checkpoint entry contents to avoid 
excessive memory usage
 Key: IGNITE-7471
 URL: https://issues.apache.org/jira/browse/IGNITE-7471
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






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

[jira] [Updated] (IGNITE-7471) Use soft reference for checkpoint entry contents to avoid excessive memory usage

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7471:
-
Fix Version/s: 2.4

> Use soft reference for checkpoint entry contents to avoid excessive memory 
> usage
> 
>
> Key: IGNITE-7471
> URL: https://issues.apache.org/jira/browse/IGNITE-7471
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Updated] (IGNITE-7471) Use soft reference for checkpoint entry contents to avoid excessive memory usage

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7471:
-
Affects Version/s: 2.1

> Use soft reference for checkpoint entry contents to avoid excessive memory 
> usage
> 
>
> Key: IGNITE-7471
> URL: https://issues.apache.org/jira/browse/IGNITE-7471
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Updated] (IGNITE-6386) Introduction of distributed neural networks.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6386:

Fix Version/s: (was: 2.4)
   2.5

> Introduction of distributed neural networks.
> 
>
> Key: IGNITE-6386
> URL: https://issues.apache.org/jira/browse/IGNITE-6386
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>Priority: Major
>  Labels: important
> Fix For: 2.5
>
>
> We want to have deep learning algorithms and for this we need to implement 
> neural network over Apache Ignite. Currently we think about using 
> [dl4j|https://deeplearning4j.org] as backend but in this case we cannot  
> train one model over multiple nodes efficiently. Also we will think about 
> integration/connector with dl4j.



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