[jira] [Commented] (IGNITE-7170) Fix javadoc MemoryConfiguration (20% instead of 80%)

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-7170:
--

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

> Fix javadoc MemoryConfiguration (20% instead of 80%)
> 
>
> Key: IGNITE-7170
> URL: https://issues.apache.org/jira/browse/IGNITE-7170
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Trivial
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> org.apache.ignite.configuration.MemoryConfiguration#setDefaultMemoryPolicySize
>  - has wrong javadoc - there is info about 80%.
> It should be 20% 



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

[jira] [Resolved] (IGNITE-7170) Fix javadoc MemoryConfiguration (20% instead of 80%)

[Nikolay Tikhonov (JIRA)]

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

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

> Fix javadoc MemoryConfiguration (20% instead of 80%)
> 
>
> Key: IGNITE-7170
> URL: https://issues.apache.org/jira/browse/IGNITE-7170
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Trivial
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> org.apache.ignite.configuration.MemoryConfiguration#setDefaultMemoryPolicySize
>  - has wrong javadoc - there is info about 80%.
> It should be 20% 



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

[jira] [Updated] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-7090:
-
Component/s: data structures

> Semaphore Stuck when no acquirers to assign permit
> --
>
> Key: IGNITE-7090
> URL: https://issues.apache.org/jira/browse/IGNITE-7090
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures
>Affects Versions: 2.1, 2.4
>Reporter: Tim Onyschak
> Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java
>
>
> If no acquirers are available to take permit of semaphore, the permit never 
> gets release and any further acquirerers will wait forever. 



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

[jira] [Comment Edited] (IGNITE-6971) Ignite Logger type & logging file config indication

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6971 at 12/4/17 3:27 PM:
---

[~alexey.tank2],
Thank you for your contribution! I have only one comment. Let's check that will 
print to log by {{PlatformLogger}} implementation.


was (Author: ntikhonov):
[~alexey.tank2],
Thank you for your contribution! I've only one comment. Let's check that will 
print to log by {{PlatformLogger}} implementation.

> Ignite Logger type & logging file config indication
> ---
>
> Key: IGNITE-6971
> URL: https://issues.apache.org/jira/browse/IGNITE-6971
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please see 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html



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

[jira] [Commented] (IGNITE-6971) Ignite Logger type & logging file config indication

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6971:
--

[~alexey.tank2],
Thank you for your contribution! I've only one comment. Let's check that will 
print in log by {{PlatformLogger}} implementation.

> Ignite Logger type & logging file config indication
> ---
>
> Key: IGNITE-6971
> URL: https://issues.apache.org/jira/browse/IGNITE-6971
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please see 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html



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

[jira] [Comment Edited] (IGNITE-6971) Ignite Logger type & logging file config indication

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6971 at 12/4/17 1:15 PM:
---

[~alexey.tank2],
Thank you for your contribution! I've only one comment. Let's check that will 
print to log by {{PlatformLogger}} implementation.


was (Author: ntikhonov):
[~alexey.tank2],
Thank you for your contribution! I've only one comment. Let's check that will 
print in log by {{PlatformLogger}} implementation.

> Ignite Logger type & logging file config indication
> ---
>
> Key: IGNITE-6971
> URL: https://issues.apache.org/jira/browse/IGNITE-6971
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please see 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html



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

[jira] [Commented] (IGNITE-6955) Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6955:
--

[~alexey.tank2],
Thank for your contribution! Merged to master.

> Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4
> 
>
> Key: IGNITE-6955
> URL: https://issues.apache.org/jira/browse/IGNITE-6955
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please update com.google.code.simple-spring-memcached:spymemcached to 2.8.4 
> version.
> This version does not have "netty" dependencies



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

[jira] [Commented] (IGNITE-6828) Confusing messages "SLF4J: Failed to load class" at Ignite start

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6828:
--

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

> Confusing messages "SLF4J: Failed to load class" at Ignite start
> 
>
> Key: IGNITE-6828
> URL: https://issues.apache.org/jira/browse/IGNITE-6828
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Trivial
> Fix For: 2.4
>
>
> How to reproduce:
> 1. build Ignite
> 2. go to examples\
> 3. run: mvn exec:java 
> -Dexec.mainClass="org.apache.ignite.examples.ExampleNodeStartup"
> you will see the following confusing output:
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
> details.
> SLF4J dependency comes from org.springframework.data:spring-data-commons:
> [INFO] +- org.apache.ignite:ignite-spring-data:jar:2.3.0-SNAPSHOT:compile
> [INFO] |  +- (org.apache.ignite:ignite-core:jar:2.3.0-SNAPSHOT:compile - 
> omitted for duplicate)
> [INFO] |  +- (org.apache.ignite:ignite-indexing:jar:2.3.0-SNAPSHOT:compile - 
> omitted for duplicate)
> [INFO] |  +- 
> org.springframework.data:spring-data-commons:jar:1.13.1.RELEASE:compile
> [INFO] |  |  +- (org.springframework:spring-core:jar:4.3.7.RELEASE:compile - 
> omitted for duplicate)
> [INFO] |  |  +- (org.springframework:spring-beans:jar:4.3.7.RELEASE:compile - 
> omitted for duplicate)
> [INFO] |  |  +- org.slf4j:slf4j-api:jar:1.7.24:compile
> [INFO] |  |  \- org.slf4j:jcl-over-slf4j:jar:1.7.24:runtime
> [INFO] |  | \- (org.slf4j:slf4j-api:jar:1.7.24:runtime - omitted for 
> duplicate)
> [INFO] |  \- (org.apache.ignite:ignite-spring:jar:2.3.0-SNAPSHOT:compile - 
> omitted for duplicate)
> We should remove this dependency because it is confusing and does not affects 
> to Ignite logging functionality
> Dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Confusing-slf4j-error-messages-td24334.html



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

[jira] [Commented] (IGNITE-6971) Ignite Logger type & logging file config indication

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6971:
--

[~alexey.tank2],
Thank you for your contribution! I've reviewed your change and have the 
follwoing notes:

* Log4JLogger#cfg should not be static. It isn't thread safe.
* Need to make this information visible when quite mode in {{false}};

> Ignite Logger type & logging file config indication
> ---
>
> Key: IGNITE-6971
> URL: https://issues.apache.org/jira/browse/IGNITE-6971
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please see 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html



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

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

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-2766:
--

[~ilyak],
I've checked and merged your test improvment. Thank you for your contribution!

> 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
>
> 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
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

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

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Comment Edited] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6949 at 11/23/17 2:34 PM:


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

Anyway, ML module needs to serious review. I've found code style issues and 
rude exception handling. For example
{noformat}
org.apache.ignite.ml.util.Utils#copy
...
catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
{noformat}

[~chief], could you handle this?


was (Author: ntikhonov):
[~zaleslaw],
Thank you for your contribution! I've merged the changes to master. 

Anyway, ML module needs to serious review. I've found code style issues and 
rude exception handling. For example
{{noformat}}
org.apache.ignite.ml.util.Utils#copy
...
catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
{{noformat}}

[~chief], could you handle this?

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Commented] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6949:
--

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

Anyway, ML module needs to serious review. I've found code style issues and 
rude exception handling. For example
{{noformat}}
org.apache.ignite.ml.util.Utils#copy
...
catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
{{noformat}}

[~chief], could you handle this?

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Commented] (IGNITE-6984) Make cache creation slightly more verbose.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6984:
--

[~amashenkov],
Thank you for your contribution! It's really helpful for reading logs. I've 
fixed minor code style of issues and merged to master.

> Make cache creation slightly more verbose.
> --
>
> Key: IGNITE-6984
> URL: https://issues.apache.org/jira/browse/IGNITE-6984
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.4
>
>
> For now we do not print cacheId on cache start, but use cacheId instead of 
> name everywhere in logs.
> So, it is hard to investigate issues in production.
> Also actual number of backups can be helpful when restoring cache from 
> persistence.
> Lets, add cacheId and number of backups to the "cache start" message.



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

[jira] [Commented] (IGNITE-6955) Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6955:
--

[~avinogradov],
I don't have any expertise in this area. AFAIK you're committer and PMC too. 
Please, do it yourself.

> Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4
> 
>
> Key: IGNITE-6955
> URL: https://issues.apache.org/jira/browse/IGNITE-6955
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please update com.google.code.simple-spring-memcached:spymemcached to 2.8.4 
> version.
> This version does not have "netty" dependencies



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

[jira] [Comment Edited] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6949 at 11/21/17 10:29 AM:
-

[~zaleslaw],
Thank you for your contribution! I've looked at the changes and still see some 
code style issues. For example 
* extra space in imports (SparseBlockDistributedMatrix file);
* CacheUtils#reduce has incorrect alignments;

[~chief],
Please, double check this changes again and help [~zaleslaw] with it. 


was (Author: ntikhonov):
[~zaleslaw],
Thank you for your contribution! I've looked at the changes and still see some 
code style issues. For example 
* extra space in imports (SparseBlockDistributedMatrix file);
* CacheUtils#reduce has incorrect alignments;
[~chief],
Please, double check this changes again and help [~zaleslaw] with it. 

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Commented] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6949:
--

[~zaleslaw],
Thank you for your contribution! I've looked at the changes and still see some 
code style issues. For example 
* extra space in imports (SparseBlockDistributedMatrix file);
* CacheUtils#reduce has incorrect alignments;
[~chief],
Please, double check this changes again and help [~zaleslaw] with it. 

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Resolved] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Nikolay Tikhonov (JIRA)]

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

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

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5195:
--

[~mcherkas],
Thank you for your contribution! Looks good for me. Merged to master.

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

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

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6252:
--

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


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



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

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

[Nikolay Tikhonov (JIRA)]

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

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

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



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

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

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6690:
--

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

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



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

[jira] [Resolved] (IGNITE-6774) Java doc is broken: "LUDecomposition.java:40: warning - Tag @see: missing final '>'"

[Nikolay Tikhonov (JIRA)]

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

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

Thank you for your contribution! I've merged the changes to master.

> Java doc is broken: "LUDecomposition.java:40: warning - Tag @see: missing 
> final '>'"
> 
>
> Key: IGNITE-6774
> URL: https://issues.apache.org/jira/browse/IGNITE-6774
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: ml
>Affects Versions: 2.1
>Reporter: Ksenia Rybakova
>Assignee: Mikhail Cherkasov
>
> Java doc is broken in the build
> {noformat}
> [WARNING] Javadoc Warnings
> [WARNING] 
> /var/lib/teamcity/data/work/6ae9d4bd0822354f/incubator-ignite/modules/ml/src/main/java/org/apache/ignite/ml/math/decompositions/LUDecomposition.java:40:
>  warning - Tag @see: missing final '>': " href="http://en.wikipedia.org/wiki/LU_decomposition;>Wikipedia
> [WARNING] TODO: Maybe we should make this class (and other decompositions) 
> Externalizable."
> {noformat}



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

[jira] [Commented] (IGNITE-6654) Ignite client can hang in case IgniteOOM on server

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6654:
--

[~mcherkas],
Thank you for your contribution! I've merged to master.

> Ignite client can hang in case IgniteOOM on server
> --
>
> Key: IGNITE-6654
> URL: https://issues.apache.org/jira/browse/IGNITE-6654
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, general
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>
> Ignite client can hang in case IgniteOOM on server



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

[jira] [Commented] (IGNITE-6639) Ignite node can try to join to itself

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6639:
--

[~mcherkas],
Thank you for your contribution! I've merged to master.

> Ignite node can try to join to itself
> -
>
> Key: IGNITE-6639
> URL: https://issues.apache.org/jira/browse/IGNITE-6639
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-6555) When a CacheStore with a @SpringResource annotated field is configured Ignite fails to start via igniteSpringBean

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6555:
--

[~asfedotov],
Thank for your contirbution! I've merged the changes to master.

> When a CacheStore with a @SpringResource annotated field is configured Ignite 
> fails to start via igniteSpringBean
> -
>
> Key: IGNITE-6555
> URL: https://issues.apache.org/jira/browse/IGNITE-6555
> Project: Ignite
>  Issue Type: Bug
>  Components: spring
>Affects Versions: 2.2
>Reporter: Alexandr Fedotov
>Assignee: Alexandr Fedotov
>  Labels: 2.2, regresion
> Fix For: 2.4
>
>
> When a CacheStore with a @SpringResource annotated field is configured Ignite 
> fails to start via igniteSpringBean.
> Example configuration leading to the failure is as follows
> {code:java}
> public class SpringIgniteCacheStore extends CacheStoreAdapter 
> implements Serializable {
> @SpringResource(resourceClass = SomeDao.class)
> public transient SomeDao someDao;
> ...
> }
> @Configuration
> public class IgniteSpringConfig {
>@Bean
> public IgniteSpringBean igniteSpringBean() {
> IgniteSpringBean igniteSpringBean = new IgniteSpringBean();
> ...
> return igniteSpringBean;
> }
> ...
> }
> {code}



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

[jira] [Resolved] (IGNITE-6660) Python Redis example fails for python 3 run

[Nikolay Tikhonov (JIRA)]

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

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

[~oleg-ostanin],
Thank you for your contribution! I've merged your changes to master.

> Python Redis example fails for python 3 run
> ---
>
> Key: IGNITE-6660
> URL: https://issues.apache.org/jira/browse/IGNITE-6660
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: examples
>Affects Versions: 1.8, 1.9, 2.0, 2.1, 2.2
>Reporter: Sergey Kozlov
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> Looks like python redis example fails due to design python 2. But for python 
> 3 run raised the following error:
> {noformat}
>   File 
> "/var/lib/teamcity/data/work/17028f058b6ef75f/i2test/var/suite-examples/gg-pro-fab/examples/redis/redis-example.py",
>  line 32
> print 'Value for "k1": %s' % r.get('k1')
>  ^
> SyntaxError: invalid syntax
> {noformat}
> The suggested fix is to put brackets for print calls: 
> -{{print 'Value for "k1": %s' % r.get('k1')}}-
> {{print('Value for "k1": %s' % r.get('k1'))}}



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

[jira] [Commented] (IGNITE-6660) Python Redis example fails for python 3 run

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6660:
--

[~oleg-ostanin],
Thank you for your contribution! Let's make this example compatibility with 
second version python too. For it need to add just one import. Please, look at 
a post on 
[SO|https://stackoverflow.com/questions/32032697/how-to-use-from-future-import-print-function].

> Python Redis example fails for python 3 run
> ---
>
> Key: IGNITE-6660
> URL: https://issues.apache.org/jira/browse/IGNITE-6660
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: examples
>Affects Versions: 1.8, 1.9, 2.0, 2.1, 2.2
>Reporter: Sergey Kozlov
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> Looks like python redis example fails due to design python 2. But for python 
> 3 run raised the following error:
> {noformat}
>   File 
> "/var/lib/teamcity/data/work/17028f058b6ef75f/i2test/var/suite-examples/gg-pro-fab/examples/redis/redis-example.py",
>  line 32
> print 'Value for "k1": %s' % r.get('k1')
>  ^
> SyntaxError: invalid syntax
> {noformat}
> The suggested fix is to put brackets for print calls: 
> -{{print 'Value for "k1": %s' % r.get('k1')}}-
> {{print('Value for "k1": %s' % r.get('k1'))}}



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

[jira] [Commented] (IGNITE-6362) NPE in Log4J2Logger

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6362:
--

[~alexey.tank2],
Thank for you contribution! Looks good to me. I've merged to master.

> NPE in Log4J2Logger
> ---
>
> Key: IGNITE-6362
> URL: https://issues.apache.org/jira/browse/IGNITE-6362
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> When I start a node with {{Log4J2Logger}} configured and verbose mode 
> ({{-DIGNITE_QUIET=false}}, it fails with NPE:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.(LoggerConfig.java:145)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(LoggerConfig.java:523)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.createConsoleLogger(Log4J2Logger.java:380)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.addConsoleAppenderIfNeeded(Log4J2Logger.java:338)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.(Log4J2Logger.java:145)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
>   ... 34 more
> {noformat}
> This is caused by the fact that {{Log4J2Logger#createConsoleLogger}} method 
> invokes {{LoggerConfig.createLogger}} providing {{null}} as {{Configuration}} 
> object, which unconditionally causes NPE. Need to provide some default 
> configuration instead.



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

[jira] [Comment Edited] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6234 at 10/10/17 2:57 PM:


[~KristoffSC] and [~mcherkas],
Thank guys for your contribution! I've merged your changes to master (4385f12 
commit).
Thanks!


was (Author: ntikhonov):
[~KristoffSC], [~mcherkas],
Thank guys for your contribution! I've merged your changes to master (4385f12 
commit).
Thanks!

> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Comment Edited] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6234 at 10/10/17 2:57 PM:


[~KristoffSC], [~mcherkas],
Thank guys for your contribution! I've merged your changes to master (4385f12 
commit).
Thanks!


was (Author: ntikhonov):
[~KristoffSC], [~mcherkas]!
Thank guys for your contribution! I've merged your changes to master (4385f12 
commit).
Thanks!

> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Commented] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6234:
--

[~KristoffSC], [~mcherkas]!
Thank guys for your contribution! I've merged your changes to master (4385f12 
commit).
Thanks!

> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> 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 
> 

[jira] [Comment Edited] (IGNITE-5608) SQL scripts execution capability

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-5608 at 10/9/17 4:50 PM:
---

[~oleg-ostanin],
Thank you for your contribution! I've reviewed the changes. I have only one 
comment. Let's to use space instead of equals sign. For example:
{code}ignitesql.sh -ch=127.0.0.1 -p=10800 -s=MySchema -dj=true -ej=true 
-ssb=0{code}
I guess the following command looks more consistency with other cli tools:
{code}ignitesql.sh 127.0.0.1 -p 10800 -s MySchema -dj -ej -ssb 0{code}


was (Author: ntikhonov):
[~oleg-ostanin],
Thank you for your contribution! I've reviewed the changes. I have only one 
comment. Let's to use space instead of equals sign. For example:
{code}ignitesql.sh -ch=127.0.0.1 -p=10800 -s=MySchema -dj=true -ej=true 
-ssb=0{code}
I guess the following command looks more consistency with other cli tools:
{code}ignitesql.sh 127.0.0.1 -s MySchema -dj true -ej -ssb 0{code}

> SQL scripts execution capability
> 
>
> Key: IGNITE-5608
> URL: https://issues.apache.org/jira/browse/IGNITE-5608
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> There should be a way to feed an SQL script to Ignite and execute it right 
> away. A script can consist of DDL command that will define cluster and SQL 
> configuration as well as of DML commands that, for instance, preload data 
> into Ignite.



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

[jira] [Commented] (IGNITE-5608) SQL scripts execution capability

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5608:
--

[~oleg-ostanin],
Thank you for your contribution! I've reviewed the changes. I have only one 
comment. Let's to use space instead of equals sign. For example:
{code}ignitesql.sh -ch=127.0.0.1 -p=10800 -s=MySchema -dj=true -ej=true 
-ssb=0{code}
I guess the following command looks more consistency with other cli tools:
{code}ignitesql.sh 127.0.0.1 -s MySchema -dj true -ej -ssb 0{code}

> SQL scripts execution capability
> 
>
> Key: IGNITE-5608
> URL: https://issues.apache.org/jira/browse/IGNITE-5608
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> There should be a way to feed an SQL script to Ignite and execute it right 
> away. A script can consist of DDL command that will define cluster and SQL 
> configuration as well as of DML commands that, for instance, preload data 
> into Ignite.



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

[jira] [Comment Edited] (IGNITE-6362) NPE in Log4J2Logger

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6362 at 10/5/17 12:34 PM:


[~alexey.tank2],
If we already tested this cases then this tests should be removed. I don't see 
any profit, only waste CPU.


was (Author: ntikhonov):
[~alexey.tank2],
If we already have tested this cases then this tests should be removed. I don't 
see any profit, only waste CPU.

> NPE in Log4J2Logger
> ---
>
> Key: IGNITE-6362
> URL: https://issues.apache.org/jira/browse/IGNITE-6362
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> When I start a node with {{Log4J2Logger}} configured and verbose mode 
> ({{-DIGNITE_QUIET=false}}, it fails with NPE:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.(LoggerConfig.java:145)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(LoggerConfig.java:523)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.createConsoleLogger(Log4J2Logger.java:380)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.addConsoleAppenderIfNeeded(Log4J2Logger.java:338)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.(Log4J2Logger.java:145)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
>   ... 34 more
> {noformat}
> This is caused by the fact that {{Log4J2Logger#createConsoleLogger}} method 
> invokes {{LoggerConfig.createLogger}} providing {{null}} as {{Configuration}} 
> object, which unconditionally causes NPE. Need to provide some default 
> configuration instead.



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

[jira] [Commented] (IGNITE-6362) NPE in Log4J2Logger

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6362:
--

[~alexey.tank2],
Thank you for your contribution! I've looked at your changes and have the 
following minor comments:
* Why did you add Depricated annotation on tests?
* It looks that we missed suite for log4j2 on TC. Let's to recovery it.

> NPE in Log4J2Logger
> ---
>
> Key: IGNITE-6362
> URL: https://issues.apache.org/jira/browse/IGNITE-6362
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> When I start a node with {{Log4J2Logger}} configured and verbose mode 
> ({{-DIGNITE_QUIET=false}}, it fails with NPE:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.(LoggerConfig.java:145)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(LoggerConfig.java:523)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.createConsoleLogger(Log4J2Logger.java:380)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.addConsoleAppenderIfNeeded(Log4J2Logger.java:338)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.(Log4J2Logger.java:145)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
>   ... 34 more
> {noformat}
> This is caused by the fact that {{Log4J2Logger#createConsoleLogger}} method 
> invokes {{LoggerConfig.createLogger}} providing {{null}} as {{Configuration}} 
> object, which unconditionally causes NPE. Need to provide some default 
> configuration instead.



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

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

[Nikolay Tikhonov (JIRA)]

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

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

[~Maxim Neverov],
Thank you for your contribution! I've merged this chagnes to master.

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



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

[jira] [Resolved] (IGNITE-6487) During exchange affinity may return more backups than set

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-6487.
--
Resolution: Won't Fix

It's expected behaviour. See lateAffinityAssigment.

> During exchange affinity may return more backups than set 
> --
>
> Key: IGNITE-6487
> URL: https://issues.apache.org/jira/browse/IGNITE-6487
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Dmitry Karachentsev
> Attachments: GridCacheRebalanceBackupsTest.java
>
>
> Reproducer is in attachment.



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

[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-425:
-

[~NIzhikov],
Thank you for your contribution! I've reviewed your changes and have the 
following comments:
* Need to add more informative javadoc for TransformedEventListener class. Also 
don't forget to add apache header;
* Let's add a correct assertion instead of removed {{assert locLsnr != null}} 
in constructor CacheContinuousQuery Handler;
* Add assertion in #notifyLocLsnr method which check that exactly one listener 
exists and this method should be renamed;
* Use F.view in #transform method or avoid to create wrapper over collections; 


> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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

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

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-2092:
--

[~Maxim Neverov],
It sounds reasonable for me. Could you create pull request on this ticket?

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



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

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6053:
--

[~roman_s],
I saw that Ignite {{Platform .NET}} suite is failed constantly, but passed in 
master. Let's to merge last change from master to your branch and check the 
suite.

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Commented] (IGNITE-6219) IgniteCache#loadCache executes local load in caller thread

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6219:
--

Looks good for me. Merged to master

> IgniteCache#loadCache executes local load in caller thread
> --
>
> Key: IGNITE-6219
> URL: https://issues.apache.org/jira/browse/IGNITE-6219
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.3
>
>
> {{IgniteCache#loadCache}} method broadcasts an internal task under the hood. 
> If one of the jobs are local (i.e. if {{loadCache}} is invoked on server 
> node), this job is executed in a caller thread, potentially *before all or 
> some remote requests are sent*. Since data loading is generally long running 
> process, its duration doubles in this scenario.
> Possible solution is to check the list of nodes before task execution, and if 
> local node is there, execute on remote nodes first, and only then submit to 
> local node. This way we make sure that remote nodes never wait for the local 
> node.



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

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6053:
--

[~roman_s],
Most of cache operations are processed in sys-pool and long clearAll operation 
can to lead to threads starvation. I saw that last commit wasn't processed by 
[TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2443%2Fhead].
 I've triggered it and if it's OK, I'm agree with this changes.

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Comment Edited] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6053 at 9/1/17 11:43 AM:
---

[~roman_s],
I've looked at code and have only one comment, let's will execute clear closure 
in public pool instead of system pool. For it need to pass false to localSafe 
method. {{ctx.closures().callLocalSafe(..., false)}}
Also I don't see a runs on TC. Are you sure that you triggered this suites 
[link 
TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2443%2Fhead]?
BTW Thank you for your contribution!


was (Author: ntikhonov):
[~roman_s],
I've looked at code and have only one comment, let's will execute clearTask in 
public pool instead of system pool. For it need to pass false to localSafe 
method. {{ctx.closures().callLocalSafe(..., false)}}
Also I don't see a runs on TC. Are you sure that you triggered this suites 
[link 
TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2443%2Fhead]?
BTW Thank you for your contribution!

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6053:
--

[~roman_s],
I've looked at code and have only one comment, let's will execute clearTask in 
public pool instead of system pool. For it need to pass false to localSafe 
method. {{ctx.closures().callLocalSafe(..., false)}}
Also I don't see a runs on TC. Are you sure that you triggered this suites 
[link 
TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2443%2Fhead]?
BTW Thank you for your contribution!

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6053:
--

[~roman_s],
Yes, this changes looks good, but I've forgotten about async method IgniteCache 
#clearAsync. Could you fix the method as well?

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6053:
--

[~roman_s],
Seems that only server parameter should be {{true}} for local cache. AFAIK, 
user can't to create near cache for local cache (and it looks very strange for 
me :) ). Let's change it and rerun TC.

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Commented] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6168:
--

[~ilyak]
Thank you for your contribution! Looks good for me. I've merged to master.

> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Ilya Kasnacheev
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Commented] (IGNITE-6155) Add GC Date Stamps to yardstick gc log

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6155:
--

[~oleg-ostanin],
Thank you for your contribution! I've looked at changes and them look good for 
me.

> Add GC Date Stamps to yardstick gc log
> --
>
> Key: IGNITE-6155
> URL: https://issues.apache.org/jira/browse/IGNITE-6155
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.2
>
>
> We need to add -XX:+PrintGCDateStamps to Jvm options in yardstick config 
> files.



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

[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-425:
-

[~NIzhikov],
Thank you for your contribution! I've looked at code and have the following 
notes:
* Let's discuss changes related with public API on dev list;
* Behaviour when transformer throws exception should be clear and properly 
documented;

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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

[jira] [Assigned] (IGNITE-4551) Reconsider cache key/value peer class loading

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-4551:


Assignee: (was: Nikolay Tikhonov)

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



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

[jira] [Commented] (IGNITE-6088) Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on SSLSocket

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6088:
--

[~ezhuravl],
Thank you for your contribution! It looks good for me.

> Socket#shutdownOutput in ServerImpl leads to UnsupportedOperationException on 
> SSLSocket
> ---
>
> Key: IGNITE-6088
> URL: https://issues.apache.org/jira/browse/IGNITE-6088
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.2
>
>
> UnsupportedOperationException: The method shutdownOutput() is not supported 
> in SSLSocket 



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

[jira] [Comment Edited] (IGNITE-5355) Create task with release tools

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-5355 at 8/18/17 9:31 AM:
---

[~lexa],
Thank you for your contribution! I've reviewed changes and have some minor 
comments:
* Can you to make sure that org.json.json:20170516 dependency compatible with 
apache license?
* Some minor code style issues (space, name convention and etc);
* Use StringBuilder instead of simple string concatenation in loop;
* Is it possible to add test on this tool?


was (Author: ntikhonov):
[~lexa],
Thank you for your contribution! I've reviewed changes and have some minor 
comments:
* Can you to make sure that org.json.json:20170516 dependency compatible with 
apache license?
* Some minor code style issues (space, name convention and etc);
* Use StringBuilder instead of simple string concatenation in loop.

> Create task with release tools
> --
>
> Key: IGNITE-5355
> URL: https://issues.apache.org/jira/browse/IGNITE-5355
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Aleksey Chetaev
>Assignee: Aleksey Chetaev
>
> 1. Create task for auto-generate HTML formatted releases notes



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

[jira] [Commented] (IGNITE-5355) Create task with release tools

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5355:
--

[~lexa],
Thank you for your contribution! I've reviewed changes and have some minor 
comments:
* Can you to make sure that org.json.json:20170516 dependency compatible with 
apache license?
* Some minor code style issues (space, name convention and etc);
* Use StringBuilder instead of simple string concatenation in loop.

> Create task with release tools
> --
>
> Key: IGNITE-5355
> URL: https://issues.apache.org/jira/browse/IGNITE-5355
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Aleksey Chetaev
>Assignee: Aleksey Chetaev
>
> 1. Create task for auto-generate HTML formatted releases notes



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

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6053:
--

[~roman_s],
Thank you for your contribution! I think for local cache might be more 
effective just call to {{cache.clearLocally}} method and avoid to create jobs 
and tasks.

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.2
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



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

[jira] [Commented] (IGNITE-4991) Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is set

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4991:
--

[~ezhuravl],
Thank you for your contribution! I've merged changes to master.

> Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is 
> set
> -
>
> Key: IGNITE-4991
> URL: https://issues.apache.org/jira/browse/IGNITE-4991
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>  Labels: newbie
> Fix For: 2.2
>
>
> {{IgniteKernal#ackSystemProperties}} and {{IgniteKernal#ackVmArguments}} 
> print out system properties that can contain sensitive data. This print outs 
> should be disabled when {{IGNITE_TO_STRING_INCLUDE_SENSITIVE}} system 
> property is set to {{true}}.



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

[jira] [Commented] (IGNITE-4991) Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is set

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4991:
--

Looks good for me.

> Do not print out system properties when IGNITE_TO_STRING_INCLUDE_SENSITIVE is 
> set
> -
>
> Key: IGNITE-4991
> URL: https://issues.apache.org/jira/browse/IGNITE-4991
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>  Labels: newbie
> Fix For: 2.2
>
>
> {{IgniteKernal#ackSystemProperties}} and {{IgniteKernal#ackVmArguments}} 
> print out system properties that can contain sensitive data. This print outs 
> should be disabled when {{IGNITE_TO_STRING_INCLUDE_SENSITIVE}} system 
> property is set to {{true}}.



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

[jira] [Assigned] (IGNITE-5947) ClassCastException when two-dimensional array is fetched from cache

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-5947:


Assignee: Nikolay Tikhonov

> ClassCastException when two-dimensional array is fetched from cache
> ---
>
> Key: IGNITE-5947
> URL: https://issues.apache.org/jira/browse/IGNITE-5947
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
>Priority: Critical
> Fix For: 2.2
>
> Attachments: TestMain.java
>
>
> When an instance of {{Object[][]}} is put into cache, and then read from 
> there, the following exception is thrown:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
> cannot be cast to [[Ljava.lang.Object;
> {noformat}
> Reproducer attached.



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

[jira] [Resolved] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

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

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

Fixed by 42293fa sboikov  on 29.05.2017 at 16:41

> Events might be missed during concurrent CQ registration and cache operations
> -
>
> Key: IGNITE-5290
> URL: https://issues.apache.org/jira/browse/IGNITE-5290
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
> Attachments: test.patch
>
>
> Events might be missed during concurrent CQ registration and cache 
> operations. See attached test.



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

[jira] [Created] (IGNITE-5848) Ignite should support Hibernate 5.2.X

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5848:


 Summary: Ignite should support Hibernate 5.2.X
 Key: IGNITE-5848
 URL: https://issues.apache.org/jira/browse/IGNITE-5848
 Project: Ignite
  Issue Type: Sub-task
  Components: cache
Affects Versions: 2.0, 2.1
Reporter: Nikolay Tikhonov


Currently Ignite supports Hibernate 5.1.X
With Hibernate version of 5.2.X got the following exception:

{code:java}
Handler dispatch failed; nested exception is java.lang.AbstractMethodError: 
org.apache.ignite.cache.hibernate.HibernateEntityRegion$AccessStrategy.putFromLoad(Lorg/hibernate/engine/spi/SharedSessionContractImplementor;Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/Object;Z)Z
{code}



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

[jira] [Closed] (IGNITE-4298) User exceptions cause IgniteException if Ignite services are deployed separately

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-4298.


> User exceptions cause IgniteException if Ignite services are deployed 
> separately
> 
>
> Key: IGNITE-4298
> URL: https://issues.apache.org/jira/browse/IGNITE-4298
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ben
>
> 2 services, Service A and Service B, are deployed and restricted to 
> individual nodes. If A calls a method of B thru the service proxy and a user 
> exception is thrown inside that method, then an IgniteException is thrown due 
> to an InvocationTargetException. See code below for a reproducable example.
> {code:title=MyUserException.java|borderStyle=solid}
> package com.example.testing;
> public class MyUserException extends Throwable {}
> {code}
> {code:title=MyCounterService.java|borderStyle=solid}
> package com.example.testing;
> public interface MyCounterService {
> int increment() throws MyUserException;
> }
> {code}
> Note this error condition in the deployment of the two services: 
> {{ignite.cluster().forYoungest()}}
> {code:title=MyCounterServiceImpl.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteServices;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCounterServiceImpl implements MyCounterService, Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private int value = 0;
> public int increment() throws MyUserException {
> if ((value % 2) == 0) {
> throw new MyUserException();
> } else {
> value++;
> }
> return value;
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> IgniteServices svcs = ignite.services(ignite.cluster().forYoungest());
> svcs.deployNodeSingleton("MyCounterService", new 
> MyCounterServiceImpl());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> System.out.println("Service cancelled");
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> System.out.println("Service initialized");
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> System.out.println("Service running");
> }
> }
> {code}
> {code:title=MyCallerService.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCallerService implements Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private Boolean stopped;
> public void run() {
> stopped = false;
> MyCounterService service = 
> ignite.services().serviceProxy("MyCounterService", MyCounterService.class, 
> false);
> while (!stopped)
> {
> try {
> Thread.sleep(500);
> service.increment();
> } catch (MyUserException e) {
> System.out.println("Got exception");
> //e.printStackTrace();
> } catch (InterruptedException e) {
> //e.printStackTrace();
> }
> catch (IgniteException e) {
> System.out.println("Got critial exception");
> // would print the actual user exception
> //e.getCause().getCause().getCause().printStackTrace();
> break;
> }
> }
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> 
> ignite.services(ignite.cluster().forYoungest()).deployNodeSingleton("MyCallerService",
>  new MyCallerService());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> stopped = true;
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> run();
> }
> }
> {code}
> {code:title=Output of MyCounterServiceImpl|borderStyle=solid}
> [18:23:23] Ignite node started OK (id=c82df19c)
> [18:23:23] Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, heap=3.5GB]
> Service initialized
> Service running
> [18:23:27] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.0GB]
> Nov 17, 2016 6:23:28 PM 

[jira] [Resolved] (IGNITE-4298) User exceptions cause IgniteException if Ignite services are deployed separately

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-4298.
--
Resolution: Duplicate

> User exceptions cause IgniteException if Ignite services are deployed 
> separately
> 
>
> Key: IGNITE-4298
> URL: https://issues.apache.org/jira/browse/IGNITE-4298
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ben
>
> 2 services, Service A and Service B, are deployed and restricted to 
> individual nodes. If A calls a method of B thru the service proxy and a user 
> exception is thrown inside that method, then an IgniteException is thrown due 
> to an InvocationTargetException. See code below for a reproducable example.
> {code:title=MyUserException.java|borderStyle=solid}
> package com.example.testing;
> public class MyUserException extends Throwable {}
> {code}
> {code:title=MyCounterService.java|borderStyle=solid}
> package com.example.testing;
> public interface MyCounterService {
> int increment() throws MyUserException;
> }
> {code}
> Note this error condition in the deployment of the two services: 
> {{ignite.cluster().forYoungest()}}
> {code:title=MyCounterServiceImpl.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteServices;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCounterServiceImpl implements MyCounterService, Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private int value = 0;
> public int increment() throws MyUserException {
> if ((value % 2) == 0) {
> throw new MyUserException();
> } else {
> value++;
> }
> return value;
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> IgniteServices svcs = ignite.services(ignite.cluster().forYoungest());
> svcs.deployNodeSingleton("MyCounterService", new 
> MyCounterServiceImpl());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> System.out.println("Service cancelled");
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> System.out.println("Service initialized");
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> System.out.println("Service running");
> }
> }
> {code}
> {code:title=MyCallerService.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCallerService implements Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private Boolean stopped;
> public void run() {
> stopped = false;
> MyCounterService service = 
> ignite.services().serviceProxy("MyCounterService", MyCounterService.class, 
> false);
> while (!stopped)
> {
> try {
> Thread.sleep(500);
> service.increment();
> } catch (MyUserException e) {
> System.out.println("Got exception");
> //e.printStackTrace();
> } catch (InterruptedException e) {
> //e.printStackTrace();
> }
> catch (IgniteException e) {
> System.out.println("Got critial exception");
> // would print the actual user exception
> //e.getCause().getCause().getCause().printStackTrace();
> break;
> }
> }
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> 
> ignite.services(ignite.cluster().forYoungest()).deployNodeSingleton("MyCallerService",
>  new MyCallerService());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> stopped = true;
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> run();
> }
> }
> {code}
> {code:title=Output of MyCounterServiceImpl|borderStyle=solid}
> [18:23:23] Ignite node started OK (id=c82df19c)
> [18:23:23] Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, heap=3.5GB]
> Service initialized
> Service running
> [18:23:27] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.0GB]

[jira] [Resolved] (IGNITE-3893) void type is not part of 'primitiveMap' in IgniteUtils class , this is causing class not found exception for void.

[Nikolay Tikhonov (JIRA)]

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

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

Fixed by the following commit:

Fixed ClassNotFoundException for void.class
2a3a565 Valentin Kulichenko  on 12.03.2016 at 
1:35

> void type is not part of 'primitiveMap' in IgniteUtils class , this is 
> causing class not found exception for void.
> --
>
> Key: IGNITE-3893
> URL: https://issues.apache.org/jira/browse/IGNITE-3893
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.5.0.final
>Reporter: Benakaraj K S
>
> I am doing dynamic code generation inside IgniteCallable which i am 
> broadcasting to all the nodes(this is to achieve Dynamic pojo support for 
> IgniteCache) using bytebuddy , my dynamically generated pojo class has setter 
> methods with return type void,  I am getting ClassNotFoundException : void  
> while generating Dynamic pojo, when i debugged i got to know that the 
> problem(?) is that, void is not part of 'primitiveMap' in IgniteUtils class. 
> Is there a reason for not having it in this MAP?. 



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

[jira] [Closed] (IGNITE-3893) void type is not part of 'primitiveMap' in IgniteUtils class , this is causing class not found exception for void.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-3893.


> void type is not part of 'primitiveMap' in IgniteUtils class , this is 
> causing class not found exception for void.
> --
>
> Key: IGNITE-3893
> URL: https://issues.apache.org/jira/browse/IGNITE-3893
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.5.0.final
>Reporter: Benakaraj K S
>
> I am doing dynamic code generation inside IgniteCallable which i am 
> broadcasting to all the nodes(this is to achieve Dynamic pojo support for 
> IgniteCache) using bytebuddy , my dynamically generated pojo class has setter 
> methods with return type void,  I am getting ClassNotFoundException : void  
> while generating Dynamic pojo, when i debugged i got to know that the 
> problem(?) is that, void is not part of 'primitiveMap' in IgniteUtils class. 
> Is there a reason for not having it in this MAP?. 



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

[jira] [Commented] (IGNITE-5390) But in IgniteCacheTxStoreSessionWriteBehindCoalescingTest

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5390:
--

Thank you for your contribution! Merged to master.

> But in IgniteCacheTxStoreSessionWriteBehindCoalescingTest
> -
>
> Key: IGNITE-5390
> URL: https://issues.apache.org/jira/browse/IGNITE-5390
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Trivial
> Fix For: 2.1
>
>
> IgniteCacheTxStoreSessionWriteBehindCoalescingTest override 
> cacheConfiguration method from IgniteCacheStoreSessionWriteBehindAbstractTest 
> to switch TestStore into TestNonCoalescingStore.
> But IgniteCacheStoreSessionWriteBehindAbstractTest.getConfiguration 
> cacheStoreFactory explicitly set to TestStore for ccfg1.
> Need to remove it.



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

[jira] [Assigned] (IGNITE-5390) But in IgniteCacheTxStoreSessionWriteBehindCoalescingTest

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-5390:


Assignee: Alexander Belyak  (was: Nikolay Tikhonov)

> But in IgniteCacheTxStoreSessionWriteBehindCoalescingTest
> -
>
> Key: IGNITE-5390
> URL: https://issues.apache.org/jira/browse/IGNITE-5390
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Trivial
> Fix For: 2.1
>
>
> IgniteCacheTxStoreSessionWriteBehindCoalescingTest override 
> cacheConfiguration method from IgniteCacheStoreSessionWriteBehindAbstractTest 
> to switch TestStore into TestNonCoalescingStore.
> But IgniteCacheStoreSessionWriteBehindAbstractTest.getConfiguration 
> cacheStoreFactory explicitly set to TestStore for ccfg1.
> Need to remove it.



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

[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-2190:
--

[~avinogradov],
Are sure for this case needed to deserialize this value? If nobody subscribe 
this event might be make sense to doesn't unmarshal a value. What do you think 
about it?

> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> 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)
> Caused by: java.lang.ClassNotFoundException: 
> **.SubMessageB
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at 

[jira] [Updated] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-3653:
-
Fix Version/s: (was: 2.1)

> P2P doesn't work for remote filter and filter factory.
> --
>
> Key: IGNITE-3653
> URL: https://issues.apache.org/jira/browse/IGNITE-3653
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
> Attachments: CCP2PTest.patch
>
>
> Remote filter and filter factory classes were not deployed on nodes which 
> join to cluster after their initialization. Test attached.



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

[jira] [Assigned] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-5489:


Assignee: Nikolay Tikhonov

> Possible connection leaks when loadPreviousValue set to true
> 
>
> Key: IGNITE-5489
> URL: https://issues.apache.org/jira/browse/IGNITE-5489
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
> Attachments: IGNITE_5489.patch
>
>
> When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
> does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
> connections to DB.
> See attached test.



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

[jira] [Updated] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5489:
-
Attachment: IGNITE_5489.patch

> Possible connection leaks when loadPreviousValue set to true
> 
>
> Key: IGNITE-5489
> URL: https://issues.apache.org/jira/browse/IGNITE-5489
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: IGNITE_5489.patch
>
>
> When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
> does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
> connections to DB.
> See attached test.



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

[jira] [Updated] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5489:
-
Attachment: (was: IGNITE_5489.patch)

> Possible connection leaks when loadPreviousValue set to true
> 
>
> Key: IGNITE-5489
> URL: https://issues.apache.org/jira/browse/IGNITE-5489
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: IGNITE_5489.patch
>
>
> When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
> does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
> connections to DB.
> See attached test.



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

[jira] [Updated] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5489:
-
Attachment: IGNITE_5489.patch

> Possible connection leaks when loadPreviousValue set to true
> 
>
> Key: IGNITE-5489
> URL: https://issues.apache.org/jira/browse/IGNITE-5489
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: IGNITE_5489.patch
>
>
> When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
> does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
> connections to DB.
> See attached test.



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

[jira] [Created] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5489:


 Summary: Possible connection leaks when loadPreviousValue set to 
true
 Key: IGNITE-5489
 URL: https://issues.apache.org/jira/browse/IGNITE-5489
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Nikolay Tikhonov


When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
connections to DB.
See attached test.



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

[jira] [Closed] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-4324.


> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes
> -
>
> Key: IGNITE-4324
> URL: https://issues.apache.org/jira/browse/IGNITE-4324
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Nikolay Tikhonov
>Assignee: William Do
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: Tests.patch
>
>
> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes (for example with node filter).  See attached test.
> {code}
> java.lang.IllegalArgumentException: bound must be positive
>   at java.util.Random.nextInt(Random.java:388)
>   at org.apache.ignite.internal.util.lang.GridFunc.rand(GridFunc.java:677)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.nodes(GridCacheQueryAdapter.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:527)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4119)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4094)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
>   at 
> org.apache.ignite.internal.CacheFilterQueryTest.testScanQuery(CacheFilterQueryTest.java:90)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1768)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1706)
>   at java.lang.Thread.run(Thread.java:745)
> [
> {code}



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

[jira] [Commented] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4324:
--

[~williamdo],
Thank you for your contribution! I've reviewed your changes and have only minor 
notes. I've fixed them (code style and added test for partition cache). I've 
pushed changes to ignite-4324 branch. Could you look at it? If you don't have 
any objections, I'll merge the branch to master.

> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes
> -
>
> Key: IGNITE-4324
> URL: https://issues.apache.org/jira/browse/IGNITE-4324
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Nikolay Tikhonov
>Assignee: William Do
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: Tests.patch
>
>
> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes (for example with node filter).  See attached test.
> {code}
> java.lang.IllegalArgumentException: bound must be positive
>   at java.util.Random.nextInt(Random.java:388)
>   at org.apache.ignite.internal.util.lang.GridFunc.rand(GridFunc.java:677)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.nodes(GridCacheQueryAdapter.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:527)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4119)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4094)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
>   at 
> org.apache.ignite.internal.CacheFilterQueryTest.testScanQuery(CacheFilterQueryTest.java:90)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1768)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1706)
>   at java.lang.Thread.run(Thread.java:745)
> [
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-5290:


Assignee: Nikolay Tikhonov

> Events might be missed during concurrent CQ registration and cache operations
> -
>
> Key: IGNITE-5290
> URL: https://issues.apache.org/jira/browse/IGNITE-5290
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
> Attachments: test.patch
>
>
> Events might be missed during concurrent CQ registration and cache 
> operations. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5290:
--

[~sboikov]
Thank you for your idea!  I've already implemeted it. Could you please look at 
PR? 
https://github.com/apache/ignite/pull/2010

> Events might be missed during concurrent CQ registration and cache operations
> -
>
> Key: IGNITE-5290
> URL: https://issues.apache.org/jira/browse/IGNITE-5290
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: test.patch
>
>
> Events might be missed during concurrent CQ registration and cache 
> operations. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5290:
--

[~amashenkov],
It is not duplicate. Its other issue.

> Events might be missed during concurrent CQ registration and cache operations
> -
>
> Key: IGNITE-5290
> URL: https://issues.apache.org/jira/browse/IGNITE-5290
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: test.patch
>
>
> Events might be missed during concurrent CQ registration and cache 
> operations. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5290:
-
Attachment: test.patch

> Events might be missed during concurrent CQ registration and cache operations
> -
>
> Key: IGNITE-5290
> URL: https://issues.apache.org/jira/browse/IGNITE-5290
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: test.patch
>
>
> Events might be missed during concurrent CQ registration and cache 
> operations. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5290:


 Summary: Events might be missed during concurrent CQ registration 
and cache operations
 Key: IGNITE-5290
 URL: https://issues.apache.org/jira/browse/IGNITE-5290
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Nikolay Tikhonov


Events might be missed during concurrent CQ registration and cache operations. 
See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4551) Reconsider cache key/value peer class loading

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-4551:


Assignee: (was: Nikolay Tikhonov)

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
> Fix For: 2.1
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4551) Reconsider cache key/value peer class loading

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-4551 at 5/22/17 2:10 PM:
---

* Added into {{CacheDataRow}} new methods {{keyClassLoaderId}}, 
{{valueClassLoaderId}} and {{deploymentEnabled}};
* Updated {{writeFragmentData}} and {{writeRowData}};
* Updated {{readData}} and {{readFragmentData}};

Link to [github|https://github.com/gridgain/apache-ignite/tree/ignite-4551].


was (Author: ntikhonov):
* Added into {{CacheDataRow}} new methods {{keyClassLoaderId}}, 
{{valueClassLoaderId}} and {{deploymentEnabled}};
* Updated {{writeFragmentData}} and {{writeRowData}};
* Updated {{readData}} and {{readFragmentData}};

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
> Fix For: 2.1
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4551) Reconsider cache key/value peer class loading

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-4551 at 5/22/17 2:08 PM:
---

* Added into {{CacheDataRow}} new methods {{keyClassLoaderId}}, 
{{valueClassLoaderId}} and {{deploymentEnabled}};
* Updated {{writeFragmentData}} and {{writeRowData}};
* Updated {{readData}} and {{readFragmentData}};


was (Author: ntikhonov):
* Added into {{CacheDataRow}} new methods {{keyClassLoaderId}}, 
{{valueClassLoaderId}} and {{deploymentEnabled}}.
* Updated {{writeFragmentData}} and {{writeRowData}}

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
> Fix For: 2.1
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4551) Reconsider cache key/value peer class loading

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4551:
--

* Added into {{CacheDataRow}} new methods {{keyClassLoaderId}}, 
{{valueClassLoaderId}} and {{deploymentEnabled}}.
* Updated {{writeFragmentData}} and {{writeRowData}}

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
> Fix For: 2.1
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-4205.


> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5214:
-
Attachment: IGNITE_5214.patch

> ConcurrentModificationException with enable DEBUG log level
> ---
>
> Key: IGNITE-5214
> URL: https://issues.apache.org/jira/browse/IGNITE-5214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
> Attachments: IGNITE_5214.patch
>
>
> ConcurrentModificationException with 
> org.apache.ignite.continuous.query=DEBUG
> {noformat}
> Unexpected exception during cache update 
> java.util.ConcurrentModificationException: null
>   at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1247)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1242)
>   at java.util.AbstractMap.toString(AbstractMap.java:554)
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$PartitionRecovery.collectEntries(CacheContinuousQueryHandler.java:1132)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:739)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:792)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$800(CacheContinuousQueryHandler.java:91)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:419)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2669)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2390)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1632)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:263)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:208)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1152)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1150)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:847)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1150)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2574)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsentAsync(GridDhtAtomicCache.java:664)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsent(GridDhtAtomicCache.java:657)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putIfAbsent(IgniteCacheProxy.java:1451)
>   at 
> com.workday.fabric.ignite.management.IgniteManagementService.doExecute(IgniteManagementService.java:174)
>   at 
> com.workday.fabric.ignite.service.AbstractIgniteService.execute(AbstractIgniteService.java:94)
>   at 
> 

[jira] [Updated] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5214:
-
Description: 
ConcurrentModificationException with 
org.apache.ignite.continuous.query=DEBUG
{noformat}
Unexpected exception during cache update 
java.util.ConcurrentModificationException: null
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1247)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1242)
at java.util.AbstractMap.toString(AbstractMap.java:554)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$PartitionRecovery.collectEntries(CacheContinuousQueryHandler.java:1132)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:739)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:792)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$800(CacheContinuousQueryHandler.java:91)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:419)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2669)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2390)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1632)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:263)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:208)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1152)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1150)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:847)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1150)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:619)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2574)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsentAsync(GridDhtAtomicCache.java:664)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsent(GridDhtAtomicCache.java:657)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putIfAbsent(IgniteCacheProxy.java:1451)
at 
com.workday.fabric.ignite.management.IgniteManagementService.doExecute(IgniteManagementService.java:174)
at 
com.workday.fabric.ignite.service.AbstractIgniteService.execute(AbstractIgniteService.java:94)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$3.run(GridServiceProcessor.java:1157)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
{noformat}

  was:
ConcurrentModificationException with 
org.apache.ignite.continuous.query=DEBUG
{{noformat}}
Unexpected 

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

I've logout from there and have the same problem too. I'll to ask from theirs 
support.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

[~javaller]
Which kind of issue do you have? Could you share some screenshot?

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

[~javaller],
Thank you for your contribution. I've fixed some minors issue and pushed your 
changes into {{ignite-4052}} branch. Please look at the changes. 

>I dont work with Mesos and think that anyone who has experience should make 
>it. OK?
I think that it good time to try it. ;) It looks strange when developer don't 
run own code. [2] Also would be great to update docs [1]. Use for it {{suggest 
edits}} button.

1. https://apacheignite.readme.io/docs/mesos-deployment
2. http://mesos.apache.org/gettingstarted/

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

[~javaller]
I've looked at changes and have minor comments:
* code style (extra space, if esle blocks, javadoc and etc. 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute);
* let's split #testIgniteFramework() test: one which will testing new parametes 
and other which will testing role validation;
* let's to use PowerMock in test (distributed under apache 2.0 licence which 
acceptable for our product) and rid #setEnv method;

And again, did you test this parameters on real mesos cluster?

Thank you for your contribution.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4927) Write behind - add an option to skip write coalescing

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4927:
--

[~sbberkov]
I've merged your changes to master. Thank you for your contribution!

> Write behind - add an option to skip write coalescing
> -
>
> Key: IGNITE-4927
> URL: https://issues.apache.org/jira/browse/IGNITE-4927
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Tikhonov
> Fix For: 2.0
>
>
> Currently, the write-behind store is backed by a map, therefore when several 
> updates come to the same key, they are coalesced. 
> We need to introduce optional mode and back write-behind with a queue and 
> pass each  to a database.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (IGNITE-4927) Write behind - add an option to skip write coalescing

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-4927.


> Write behind - add an option to skip write coalescing
> -
>
> Key: IGNITE-4927
> URL: https://issues.apache.org/jira/browse/IGNITE-4927
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Tikhonov
> Fix For: 2.0
>
>
> Currently, the write-behind store is backed by a map, therefore when several 
> updates come to the same key, they are coalesced. 
> We need to introduce optional mode and back write-behind with a queue and 
> pass each  to a database.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

[~javaller]
It meens that lets remove #setEnv mathod and will create mock in test which 
will override {{getUser}} and {{getRole}} methods. Also how do you think might 
be need to add validation for role? Which valid set of values for this property?

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

[~javaller]
Let's just in test override {{getUser}} and {{getRole}} methods. It should be 
enough for this feature.
Also did you test this locally? It's really works? We need to understand which 
exception user will get if user name and/or role incorrect.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-4939) Receive event before cache initialized

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-4939:
-
Description: 
Receive event before cache initialized that leads to the following:
{noformat}
Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException: 
Cache is not configured: ignite-sys-cache
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
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)
{noformat}

  was:
Receive event before cache initialized that leads to the following:

Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException: 
Cache is not configured: ignite-sys-cache
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
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)


> Receive event before cache initialized
> --
>
> Key: IGNITE-4939
> URL: https://issues.apache.org/jira/browse/IGNITE-4939
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>
> Receive event before cache initialized that leads to the following:
> {noformat}
> Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException: 
> Cache is not configured: ignite-sys-cache
> 

[jira] [Updated] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-4324:
-
Fix Version/s: (was: 2.0)
   2.1

> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes
> -
>
> Key: IGNITE-4324
> URL: https://issues.apache.org/jira/browse/IGNITE-4324
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Nikolay Tikhonov
> Fix For: 2.1
>
> Attachments: Tests.patch
>
>
> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes (for example with node filter).  See attached test.
> {code}
> java.lang.IllegalArgumentException: bound must be positive
>   at java.util.Random.nextInt(Random.java:388)
>   at org.apache.ignite.internal.util.lang.GridFunc.rand(GridFunc.java:677)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.nodes(GridCacheQueryAdapter.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:527)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4119)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4094)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
>   at 
> org.apache.ignite.internal.CacheFilterQueryTest.testScanQuery(CacheFilterQueryTest.java:90)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1768)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1706)
>   at java.lang.Thread.run(Thread.java:745)
> [
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-3653:
-
Fix Version/s: (was: 2.0)
   2.1

> P2P doesn't work for remote filter and filter factory.
> --
>
> Key: IGNITE-3653
> URL: https://issues.apache.org/jira/browse/IGNITE-3653
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
> Fix For: 2.1
>
> Attachments: CCP2PTest.patch
>
>
> Remote filter and filter factory classes were not deployed on nodes which 
> join to cluster after their initialization. Test attached.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-2699) Starvation when CacheEntryListenerConfiguration.isSynchronous is true

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-2699:
-
Fix Version/s: (was: 2.0)
   2,1

> Starvation when CacheEntryListenerConfiguration.isSynchronous is true
> -
>
> Key: IGNITE-2699
> URL: https://issues.apache.org/jira/browse/IGNITE-2699
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Nikolay Tikhonov
> Fix For: 2,1
>
>
> When event notifications in {{CacheEntryListener}} configured as synchronous 
> possible situation that all thread in {{SYSTEM}} pool will be stuck on 
> waiting ack messages. It is necessary to make the processing of acknowledge 
> messages in another thread pool.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3454) Used Thread.getContextClassLoader() classloader for P2P

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-3454:
-
Fix Version/s: (was: 2.0)
   2,1

> Used Thread.getContextClassLoader() classloader for P2P
> ---
>
> Key: IGNITE-3454
> URL: https://issues.apache.org/jira/browse/IGNITE-3454
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
> Fix For: 2,1
>
> Attachments: DeployTest_new.patch, DeployTest.patch
>
>
> {{GridClassLoaderCache#detectClassLoader}} tries to load class by 
> {{Thread.getContextClassLoader()}} when it possible. In some cases it to lead 
> to errors in cache operations:
> {noformat}
> Suppressed: class org.apache.ignite.IgniteCheckedException: Encountered 
> incompatible class loaders for cache [class1=[C, 
> class2=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:611)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMessage.prepareObject(GridCacheMessage.java:214)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMessage.marshalInvokeArguments(GridCacheMessage.java:430)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateRequest.prepareMarshal(GridNearAtomicUpdateRequest.java:607)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:620)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:642)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:803)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:469)
> ... 44 more
> {noformat}
> Test which reproduced the issue in attachment and see on 
> {{GridCacheDeploymentManager#registerClass(java.lang.Class, 
> java.lang.ClassLoader)}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)