[jira] [Updated] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-8449:
---
Description: 
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can significantly decrease contention as this method can be hot (thousands 
invocations per minute) see also IGNITE-8226

 

  was:
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method can be hot (thousands invocations per 
minute) see also IGNITE-8226

 


> Avoid empty acquiring/releasing checkpointReadLock for stale updates
> 
>
> Key: IGNITE-8449
> URL: https://issues.apache.org/jira/browse/IGNITE-8449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> we have in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
>  
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
>  boolean)
> currently we have something like this
> {code:java}
>ctx.database().checkpointReadLock();
> try {
> ...
> if (isStaleUpdate(cur, parts)) {
> 
> return false;
> }
> .
> }
> finally {
> ctx.database().checkpointReadUnlock();
> }
>  {code}
> we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
> can significantly decrease contention as this method can be hot (thousands 
> invocations per minute) see also IGNITE-8226
>  



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

[jira] [Updated] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-8449:
---
Description: 
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method can be hot (thousands invocations per 
minute) see also IGNITE-8226

 

  was:
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method can be hot (thousandsa invocations per 
minute) see also IGNITE-8226

 


> Avoid empty acquiring/releasing checkpointReadLock for stale updates
> 
>
> Key: IGNITE-8449
> URL: https://issues.apache.org/jira/browse/IGNITE-8449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> we have in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
>  
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
>  boolean)
> currently we have something like this
> {code:java}
>ctx.database().checkpointReadLock();
> try {
> ...
> if (isStaleUpdate(cur, parts)) {
> 
> return false;
> }
> .
> }
> finally {
> ctx.database().checkpointReadUnlock();
> }
>  {code}
> we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
> can decrease contention as this method can be hot (thousands invocations per 
> minute) see also IGNITE-8226
>  



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

[jira] [Updated] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-8449:
---
Description: 
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method can be hot (thousandsa invocations per 
minute) see also IGNITE-8226

 

  was:
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method is hot (thousandsa invocations per 
minute) see also IGNITE-8226

 


> Avoid empty acquiring/releasing checkpointReadLock for stale updates
> 
>
> Key: IGNITE-8449
> URL: https://issues.apache.org/jira/browse/IGNITE-8449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> we have in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
>  
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
>  boolean)
> currently we have something like this
> {code:java}
>ctx.database().checkpointReadLock();
> try {
> ...
> if (isStaleUpdate(cur, parts)) {
> 
> return false;
> }
> .
> }
> finally {
> ctx.database().checkpointReadUnlock();
> }
>  {code}
> we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
> can decrease contention as this method can be hot (thousandsa invocations per 
> minute) see also IGNITE-8226
>  



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

[jira] [Updated] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-8449:
---
Description: 
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method is hot (thousandsa invocations per 
minute) see also IGNITE-8226

 

  was:
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method is hot (thousandsa invocations per 
minute) see 

 


> Avoid empty acquiring/releasing checkpointReadLock for stale updates
> 
>
> Key: IGNITE-8449
> URL: https://issues.apache.org/jira/browse/IGNITE-8449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> we have in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
>  
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
>  boolean)
> currently we have something like this
> {code:java}
>ctx.database().checkpointReadLock();
> try {
> ...
> if (isStaleUpdate(cur, parts)) {
> 
> return false;
> }
> .
> }
> finally {
> ctx.database().checkpointReadUnlock();
> }
>  {code}
> we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
> can decrease contention as this method is hot (thousandsa invocations per 
> minute) see also IGNITE-8226
>  



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

[jira] [Updated] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-8449:
---
Description: 
we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
can decrease contention as this method is hot (thousandsa invocations per 
minute) see 

 

> Avoid empty acquiring/releasing checkpointReadLock for stale updates
> 
>
> Key: IGNITE-8449
> URL: https://issues.apache.org/jira/browse/IGNITE-8449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> we have in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
>  
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
>  boolean)
> currently we have something like this
> {code:java}
>ctx.database().checkpointReadLock();
> try {
> ...
> if (isStaleUpdate(cur, parts)) {
> 
> return false;
> }
> .
> }
> finally {
> ctx.database().checkpointReadUnlock();
> }
>  {code}
> we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
> can decrease contention as this method is hot (thousandsa invocations per 
> minute) see 
>  



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

[jira] [Created] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-8449:
--

 Summary: Avoid empty acquiring/releasing checkpointReadLock for 
stale updates
 Key: IGNITE-8449
 URL: https://issues.apache.org/jira/browse/IGNITE-8449
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Kosarev






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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-8439:
--

[~kuaw26] Can see now. Please see my changes.

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Comment Edited] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-8439 at 5/8/18 1:54 AM:
--

[~roman_s], Yes, on github


was (Author: kuaw26):
Yes, on github

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-8439:
--

Yes, on github

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Comment Edited] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-8439 at 5/8/18 1:49 AM:
--

[~kuaw26] Sure, but I can't see the comments ;) Are they on github?


was (Author: roman_s):
[~kuaw26] Sure, but I can't see the comments ;)

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-8439:
--

[~kuaw26] Sure, but I can't see the comments ;)

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-8439:
--

[~roman_s], yes it is better. But lets do minor renaming (added two more minor 
comments).

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-8439:
--

[~kuaw26] Good point. Changed it as you proposed.

Actually, even better no _if_ is needed now. Please have a look.

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-8436:
-

[~prabhat], I don't think there are tests that cover this. Could you please 
create one? I would just check that there are no Ignite threads and/or thread 
pools are running after node stop. 

> Executor service for services does not shutdown properly
> 
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802] 
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls 
> Grid life cycle and allows listening for grid events. 
> As cotributor, you should ensure that execution pool shutdowns properly and 
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}



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

[jira] [Commented] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8429:


GitHub user glukos opened a pull request:

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

IGNITE-8429 Unexpected error during incorrect WAL segment decompressi…

…on, causes node termination

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

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

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

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

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

This closes #3955


commit 9b8a8472e3e782d4888de7b9ccb9329de734c21b
Author: Ivan Rakov 
Date:   2018-05-07T23:18:51Z

IGNITE-8429 Unexpected error during incorrect WAL segment decompression, 
causes node termination




> Unexpected error during incorrect WAL segment decompression, causes node 
> termination.
> -
>
> Key: IGNITE-8429
> URL: https://issues.apache.org/jira/browse/IGNITE-8429
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> File decompressor failure due to incorrect (zero-length) archived segment. 
> 2018-04-30 00:00:02.811 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  Critical system error detected. Will be handled accordingly to configured 
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, 
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104)
> 2018-04-30 00:00:02.812 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  JVM will be halted immediately due to the failure: 
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> touch 0754.wal
> zip 0754.wal.zip 0754.wal
> ls -l
> -rw-rw-r-- 1 dmitriy dmitriy   0 май  1 16:40 0754.wal
> -rw-rw-r-- 1 dmitriy dmitriy 190 май  1 16:46 0754.wal.zip
> Archive:  /tmp/temp/0754.wal.zip
>  Length   MethodSize  CmprDateTime   CRC-32   Name
>   --  ---  -- -   
>0  Stored0   0% 2018-05-01 16:40   0754.wal
>   ---  ------
>00   0%1 file
> We should softly handle this situation: print message in log and continue the 
> decompression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Commented] (IGNITE-8226) Thousands of warning messages per second in log files.

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-8226:
-

[~macrergate] Reasonable proposal. Not sure that it will give major performance 
impact, but can save a few time in some cases. Please file a separate ticket 
with your description and feel free to take this problem by yourself.

> Thousands of warning messages per second in log files.
> --
>
> Key: IGNITE-8226
> URL: https://issues.apache.org/jira/browse/IGNITE-8226
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Oleg Ostanin
>Assignee: Pavel Kovalenko
>Priority: Minor
> Fix For: 2.5
>
>
> Sometimes I see this message in log file:
> [2018-04-11 15:45:30,999][WARN ][sys-#454] Partition has been scheduled for 
> rebalancing due to outdated update counter 
> [nodeId=bed11708-090f-4e44-a1a7-e3d2b717fcb2, grp=cache_group_5, partId=239, 
> haveHistory=false]
> The problem is that there is about 4 messages per 2 seconds.
> Also this message:
> [2018-04-11 15:03:39,997][WARN ][sys-#75] Stale update for single partition 
> map update (will ignore) [grp=cache_group_46, exchId=null, 
> curMap=GridDhtPartitionMap [moving=1024, top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=1], updateSeq=6, size=1024], 
> newMap=GridDhtPartitionMap [moving=1024, top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=1], updateSeq=6, size=1024]]
> appears about 1 times per 2 seconds.
>  
> Can we move this messages to debug level or do something else?



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

[jira] [Commented] (IGNITE-8226) Thousands of warning messages per second in log files.

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev commented on IGNITE-8226:


[~Jokser],

thanks for removing excessive logging,  but what do you think about 
 checkpointReadLock() / checkpointReadUnlock() we have in

org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
 boolean)

currently we have something like this
{code:java}
   ctx.database().checkpointReadLock();

try {
...
if (isStaleUpdate(cur, parts)) {

return false;
}
.
}
finally {
ctx.database().checkpointReadUnlock();
}
 {code}
I suppose we'd better do not  accquire those lock for isStaleUpdate == true 
branch.

 

> Thousands of warning messages per second in log files.
> --
>
> Key: IGNITE-8226
> URL: https://issues.apache.org/jira/browse/IGNITE-8226
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Oleg Ostanin
>Assignee: Pavel Kovalenko
>Priority: Minor
> Fix For: 2.5
>
>
> Sometimes I see this message in log file:
> [2018-04-11 15:45:30,999][WARN ][sys-#454] Partition has been scheduled for 
> rebalancing due to outdated update counter 
> [nodeId=bed11708-090f-4e44-a1a7-e3d2b717fcb2, grp=cache_group_5, partId=239, 
> haveHistory=false]
> The problem is that there is about 4 messages per 2 seconds.
> Also this message:
> [2018-04-11 15:03:39,997][WARN ][sys-#75] Stale update for single partition 
> map update (will ignore) [grp=cache_group_46, exchId=null, 
> curMap=GridDhtPartitionMap [moving=1024, top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=1], updateSeq=6, size=1024], 
> newMap=GridDhtPartitionMap [moving=1024, top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=1], updateSeq=6, size=1024]]
> appears about 1 times per 2 seconds.
>  
> Can we move this messages to debug level or do something else?



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

[jira] [Assigned] (IGNITE-8041) Add a GA Grid example that solves 'Knapsack Problem'

[Turik Campbell (JIRA)]

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

Turik Campbell reassigned IGNITE-8041:
--

Assignee: Yury Babak  (was: Turik Campbell)

> Add a GA Grid example that solves 'Knapsack Problem' 
> -
>
> Key: IGNITE-8041
> URL: https://issues.apache.org/jira/browse/IGNITE-8041
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Turik Campbell
>Assignee: Yury Babak
>Priority: Minor
> Fix For: 2.6
>
>
> The _Knapsack Problem_ is well known combinatorial optimization problem where 
> the goal is to maximize the benefit of objects in a knapsack without 
> exceeding its capacity.
> Additional information:
> [https://en.wikipedia.org/wiki/Knapsack_problem]
>  



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

[jira] [Assigned] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8350:
---

Assignee: Denis Magda  (was: Prachi Garg)

> GA Grid: Prepare documentation for 2.5
> --
>
> Key: IGNITE-8350
> URL: https://issues.apache.org/jira/browse/IGNITE-8350
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Turik Campbell
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> Review documentation and prepare for 2.5.



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

[jira] [Assigned] (IGNITE-8269) Add documentation for decision tree (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8269:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Add documentation for decision tree (release 2.5)
> -
>
> Key: IGNITE-8269
> URL: https://issues.apache.org/jira/browse/IGNITE-8269
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Anton Dmitriev
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> In Apache Ignite 2.5 we have added a decision tree based on partition based 
> dataset and now we need to documentation for this feature.
> Affected pages:
> [Decision Tree|https://apacheignite.readme.io/v2.4/docs/decision-tree-25]
> In release 2.5 
> [https://apacheignite.readme.io/docs/decision-trees|https://apacheignite.readme.io/docs/decision-trees]
>  page should be changed to 
> [https://apacheignite.readme.io/docs/decision-tree-25|https://apacheignite.readme.io/docs/decision-tree-25].



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

[jira] [Assigned] (IGNITE-8268) Add documentation for linear regression (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8268:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Add documentation for linear regression (release 2.5)
> -
>
> Key: IGNITE-8268
> URL: https://issues.apache.org/jira/browse/IGNITE-8268
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Anton Dmitriev
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> In Apache Ignite 2.5 we have added two implementation of linear regression 
> based on partition based dataset: LSQR and gradient descent and now we need 
> to add documentation for these features.
> Affected pages:
> [Linear 
> Regression|https://apacheignite.readme.io/v2.4/docs/linear-regression-25]
> In release 2.5 
> [https://apacheignite.readme.io/v2.4/docs/ols-multiple-linear-regression|https://apacheignite.readme.io/v2.4/docs/ols-multiple-linear-regression]
>  should be changed to 
> [https://apacheignite.readme.io/docs/linear-regression-25|https://apacheignite.readme.io/docs/linear-regression-25].



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

[jira] [Assigned] (IGNITE-8271) Add documentation for partition based dataset (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8271:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Add documentation for partition based dataset (release 2.5)
> ---
>
> Key: IGNITE-8271
> URL: https://issues.apache.org/jira/browse/IGNITE-8271
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Anton Dmitriev
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> In Apache Ignite 2.5 we have added new infrastructure layer - partition based 
> dataset, so now we need to add correspondent documentation.
> Affected pages:
> [Machine 
> Learning|https://apacheignite.readme.io/v2.4/docs/machine-learning-25]
> [Partition Based 
> Dataset|https://apacheignite.readme.io/v2.4/docs/partition-based-dataset-25]
> In release 2.5 
> [https://apacheignite.readme.io/docs/machine-learning|https://apacheignite.readme.io/docs/machine-learning]
>  page should be changed to 
> [https://apacheignite.readme.io/docs/machine-learning-25|https://apacheignite.readme.io/docs/machine-learning-25].
> In release 2.5 
> [https://apacheignite.readme.io/docs/partition-based-dataset-25|https://apacheignite.readme.io/docs/partition-based-dataset-25]
>  page should be added.



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

[jira] [Assigned] (IGNITE-8272) Add documentation for normalization preprocessor (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8272:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Add documentation for normalization preprocessor (release 2.5)
> --
>
> Key: IGNITE-8272
> URL: https://issues.apache.org/jira/browse/IGNITE-8272
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Anton Dmitriev
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> In Apache Ignite 2.5 we have added a normalization preprocessor working on 
> top of partition based dataset and now we need to add documentation for this 
> feature.
> Affected pages:
> [Preprocessing|https://apacheignite.readme.io/v2.4/docs/preprocessing-25]
> In release 2.5 
> [https://apacheignite.readme.io/v2.4/docs/preprocessing-25|https://apacheignite.readme.io/v2.4/docs/preprocessing-25]
>  page should be added.



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

[jira] [Commented] (IGNITE-8272) Add documentation for normalization preprocessor (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-8272:
-

Thanks Akmal. If you have reviewed, then it should be good. I will have 
[~dmagda] review it from the Product standpoint.

> Add documentation for normalization preprocessor (release 2.5)
> --
>
> Key: IGNITE-8272
> URL: https://issues.apache.org/jira/browse/IGNITE-8272
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Anton Dmitriev
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> In Apache Ignite 2.5 we have added a normalization preprocessor working on 
> top of partition based dataset and now we need to add documentation for this 
> feature.
> Affected pages:
> [Preprocessing|https://apacheignite.readme.io/v2.4/docs/preprocessing-25]
> In release 2.5 
> [https://apacheignite.readme.io/v2.4/docs/preprocessing-25|https://apacheignite.readme.io/v2.4/docs/preprocessing-25]
>  page should be added.



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

[jira] [Updated] (IGNITE-8434) .NET: Service proxies do not work on .NET Core

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8434:

Fix Version/s: 2.5

> .NET: Service proxies do not work on .NET Core
> --
>
> Key: IGNITE-8434
> URL: https://issues.apache.org/jira/browse/IGNITE-8434
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> Service proxies do not work on .NET Core because of conditional compilation 
> in {{ServiceProxyTypeGenerator}}.
> We only compile for a single target, so {{NETCOREAPP2_0}} branch is never 
> used.
> Except in tests, so they pass.



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

[jira] [Commented] (IGNITE-8447) .Net support of DataStreamer.perThreadBufferSize

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8447:
-

[~dpavlov]

TC results - 
https://ci.ignite.apache.org/viewLog.html?buildId=1273341=buildResultsDiv=IgniteTests24Java8_RunAllNet

[~ptupitsyn] Can you review my changes?

Should I do Run All?

> .Net support of DataStreamer.perThreadBufferSize 
> -
>
> Key: IGNITE-8447
> URL: https://issues.apache.org/jira/browse/IGNITE-8447
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Need to add support of DataStreamer#perThreadBuffer property.
> It was added in IGNITE-6699.
> Related failed test - DataStreamerTest.TestBufferSize
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-8434) .NET: Service proxies do not work on .NET Core

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-8434:


Another issue found: if service interface inherits another interface, proxy 
generation fails (we do not handle interface hierarchy when generating proxies).

This is also a regression from IGNITE-7281.

> .NET: Service proxies do not work on .NET Core
> --
>
> Key: IGNITE-8434
> URL: https://issues.apache.org/jira/browse/IGNITE-8434
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Service proxies do not work on .NET Core because of conditional compilation 
> in {{ServiceProxyTypeGenerator}}.
> We only compile for a single target, so {{NETCOREAPP2_0}} branch is never 
> used.
> Except in tests, so they pass.



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

[jira] [Updated] (IGNITE-8329) Clarify TransactionRollbackException-related paragraph in documentation

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-8329:

Fix Version/s: 2.5

> Clarify TransactionRollbackException-related paragraph in documentation
> ---
>
> Key: IGNITE-8329
> URL: https://issues.apache.org/jira/browse/IGNITE-8329
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Denis Magda
>Priority: Trivial
> Fix For: 2.5
>
>
> As documentation states currently [1], TransactionRollbackException is thrown 
> "if the transaction was rolled back automatically". This should be extended 
> to manual rollback as well, if it took place before commit for some reason.
> [1] 
> https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions



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

[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Alexey Kosenchuk (JIRA)]

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

Alexey Kosenchuk commented on IGNITE-8039:
--

c) We get it in reality. Ignite server returns 38 when we read ENUM from cache 
after it was written by Java client.

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



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

[jira] [Commented] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8448:
-

In which way AffinityKey should be supported is a topic for a debate. I gather 
templates can be put to use, but then again, I'm not a C++ dev.

> C++: AffinityKey support
> 
>
> Key: IGNITE-8448
> URL: https://issues.apache.org/jira/browse/IGNITE-8448
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Major
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Commented] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8448:
-

Currently, a workaround should be available by setting 
cacheConfiguration.setKeyConfiguration() to a custom CacheKeyConfiguration (in 
Java config or XML).

But it would be more direct to just be able to specify affinity key in C++.

Otherwise, a following error is reported:
{code}
An error occurred: Java exception occurred 
[cls=org.apache.ignite.binary.BinaryObjectException, msg=Binary type has 
different affinity key fields [typeName=KeyType, affKeyFieldName1=affId, 
affKeyFieldName2=null]]
{code}

> C++: AffinityKey support
> 
>
> Key: IGNITE-8448
> URL: https://issues.apache.org/jira/browse/IGNITE-8448
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Major
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Updated] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8448:

Issue Type: New Feature  (was: Task)

> C++: AffinityKey support
> 
>
> Key: IGNITE-8448
> URL: https://issues.apache.org/jira/browse/IGNITE-8448
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Updated] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8448:

Affects Version/s: (was: 1.1.4)
   2.6

> C++: AffinityKey support
> 
>
> Key: IGNITE-8448
> URL: https://issues.apache.org/jira/browse/IGNITE-8448
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Major
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Updated] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8448:

Priority: Major  (was: Critical)

> C++: AffinityKey support
> 
>
> Key: IGNITE-8448
> URL: https://issues.apache.org/jira/browse/IGNITE-8448
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Major
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Created] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8448:
---

 Summary: C++: AffinityKey support
 Key: IGNITE-8448
 URL: https://issues.apache.org/jira/browse/IGNITE-8448
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 1.1.4
Reporter: Ilya Kasnacheev
Assignee: Vladimir Ozerov
 Fix For: 1.6


Add AffinityKey class and AffinityKeyMapped attribute to allow custom affinity 
mapping.
This is crucial for SQL joins to work properly.
See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in Java.



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

[jira] [Updated] (IGNITE-8448) C++: AffinityKey support

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8448:

Fix Version/s: (was: 1.6)

> C++: AffinityKey support
> 
>
> Key: IGNITE-8448
> URL: https://issues.apache.org/jira/browse/IGNITE-8448
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-8039:
-

[~alexey.kosenchuk],

a) You are right. Fixed and added clarification.

b) Yes. it exists. Well, there is an root object ID, which is the parent of any 
other object (in Java it is {{java.lang.Object}}). ID of such type is \{{-1}}. 
Mentioned this in Doc.

c) It's a type made for internal purposes so lets ignore it for now, I'm not 
sure user will ever be able to get it.

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



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

[jira] [Commented] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-8437:
--

[~agoncharuk] As we can see from sources, the cause of NPE is equality to null 
of MarshallerMappingTransport instance (this.transport to be precise).

Why at the moment  onMarshallerProcessorStarted wasn't called – it's a 
question. But I suppose this is not related to the issue

> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
>  Issue Type: Improvement
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>  
> {code:java}
> 2018-05-03 16:56:36.225 
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
>  Failed to process client request [ses=GridSelectorNioSessionImpl 
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395 
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-rest-0, 
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false, 
> hashCode=1766410348, interrupted=false, 
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]], 
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null, 
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211, 
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984, 
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553, 
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075, 
> lastRcvTime=1525355796175, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d], 
> routerClient=false], directMode=false]], accepted=true]], 
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask, 
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class 
> org.apache.ignite.IgniteCheckedException: Failed to serialize object: 
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2, 
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean 
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6, 
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult 
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192)
> at 
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:165)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:162)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> 

[jira] [Updated] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7113:

Fix Version/s: (was: 2.5)
   2.6

> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
>   ID VARCHAR PRIMARY KEY,
>   DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional, 
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId) 
> VALUES ('ref2', 'src2'), params=null]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
>   at 
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
>   ... 24 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId) 
> VALUES ('ref2', 'src2'), params=null]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
>   ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing 
> from query
>   at 
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
>   at 
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
>   at 
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
>   ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.



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

[jira] [Updated] (IGNITE-7906) Create languages comparison page

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7906:

Fix Version/s: (was: 2.5)
   2.6

> Create languages comparison page 
> -
>
> Key: IGNITE-7906
> URL: https://issues.apache.org/jira/browse/IGNITE-7906
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> In addition to Java, .NET and C++ thick clients, the community is going to 
> support a variety of thin client for many other languages such as Python, 
> Node.JS, etc. It will be beneficial to create a page that depicts 
> capabilities of every language like this one:
> https://hazelcast.org/clients-languages/



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7743:

Fix Version/s: (was: 2.5)
   2.6

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



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

[jira] [Updated] (IGNITE-7855) ODBC: Support streaming mode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7855:

Fix Version/s: (was: 2.5)
   2.6

> ODBC: Support streaming mode
> 
>
> Key: IGNITE-7855
> URL: https://issues.apache.org/jira/browse/IGNITE-7855
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.6
>
>
> We need to support streaming mode in the same way it is done for JDBC.



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

[jira] [Commented] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8437:
--

[~ascherbakov], [~ivandasch],
Guys, the fix includes missing classes to the classnames.properties. Did you 
investigate what was the reason for the NPE?

> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
>  Issue Type: Improvement
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>  
> {code:java}
> 2018-05-03 16:56:36.225 
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
>  Failed to process client request [ses=GridSelectorNioSessionImpl 
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395 
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-rest-0, 
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false, 
> hashCode=1766410348, interrupted=false, 
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]], 
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null, 
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211, 
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984, 
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553, 
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075, 
> lastRcvTime=1525355796175, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d], 
> routerClient=false], directMode=false]], accepted=true]], 
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask, 
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class 
> org.apache.ignite.IgniteCheckedException: Failed to serialize object: 
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2, 
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean 
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6, 
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult 
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192)
> at 
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:165)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:162)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at 
> 

[jira] [Assigned] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4150:
---

Assignee: Vladimir Ozerov

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Updated] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4150:

Labels: performance  (was: sql-performance)

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Updated] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4150:

Fix Version/s: (was: 2.6)
   2.5

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: sql-performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Comment Edited] (IGNITE-8440) Transaction may hangs on node in PREPARED state

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-8440 at 5/7/18 3:23 PM:
-

[~v.pyatkov] Do you have any logs that contains information about described 
situation? Also it would be great to have reproducer.

Information just isn't enough.


was (Author: agura):
[~v.pyatkov] Do you have any logs that contains information about described 
situation? Also it would be great to have reproducer.

> Transaction may hangs on node in PREPARED state
> ---
>
> Key: IGNITE-8440
> URL: https://issues.apache.org/jira/browse/IGNITE-8440
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> In some specific cases we can to see when transaction hangs on one node in 
> {{PREPARED}} state, but does not hang in others.
> That unhappy node waiting to get {{TxFinishRequest}}, but never got it and 
> continue to print _long running transaction message_.
> Should to check other nodes, when transaction hang on PREPARED state without 
> progress.



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

[jira] [Commented] (IGNITE-8440) Transaction may hangs on node in PREPARED state

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-8440:
-

[~v.pyatkov] Do you have any logs that contains information about described 
situation? Also it would be great to have reproducer.

> Transaction may hangs on node in PREPARED state
> ---
>
> Key: IGNITE-8440
> URL: https://issues.apache.org/jira/browse/IGNITE-8440
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> In some specific cases we can to see when transaction hangs on one node in 
> {{PREPARED}} state, but does not hang in others.
> That unhappy node waiting to get {{TxFinishRequest}}, but never got it and 
> continue to print _long running transaction message_.
> Should to check other nodes, when transaction hang on PREPARED state without 
> progress.



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

[jira] [Resolved] (IGNITE-8173) ignite.getOrCreateCache(cacheConfig).iterator() method works incorrect for replicated cache in case if some data node isn't in baseline

[Andrey Aleksandrov (JIRA)]

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

Andrey Aleksandrov resolved IGNITE-8173.

Resolution: Fixed

This issue fixed in https://issues.apache.org/jira/browse/IGNITE-7628.

> ignite.getOrCreateCache(cacheConfig).iterator() method works incorrect for 
> replicated cache in case if some data node isn't in baseline
> ---
>
> Key: IGNITE-8173
> URL: https://issues.apache.org/jira/browse/IGNITE-8173
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
>  Labels: persistence
> Fix For: 2.6
>
> Attachments: StartClientNode.java, StartOneServerAndActivate.java, 
> StartSecondServerNode.java
>
>
> How to reproduce:
> 1)Create new server node and activate the cluster (run the 
> StartOneServerAndActivate.java example)
>  2)Create another server node. (run the StartSecondServerNode.java example 
> after step 1)
>  3)Create client node that will create new replicated cache, put some values 
> and try to get the cache iterator. (run the StartClientNode.java example)
> In this case you should see the log like that:
> Elements in cache: 0
>  **
>  **
>  **
>  **
> Elements in cache: 1000
>  **
>  **
>  **
>  **
> Elements in cache: 1000
>  **
>  **
>  **
>  **
> Elements in cache: 0
>  **
>  **
>  **
>  **
> Elements in cache: 0
>  **
>  **
> It means that sometime we see the cache values and sometime we do not. It 
> happens because second node isn't in the baseline topology. In this case all 
> data was stored to first server node and it's ok.
> The problem here is that when we ask for the iterator then we choose the node 
> that contains the required cache and send to it scan query. At the moment we 
> can choose the node in baseline topology (with data) and empty node. Looks 
> like this behavior should be changed.
> Incorrect logic located at GridCacheQueryAdapter.java at "private 
> Collection nodes() throws IgniteCheckedException" method:
> {noformat}
> case REPLICATED:
> if (prj != null || part != null)
> return nodes(cctx, prj, part);
> if (cctx.affinityNode())
> return Collections.singletonList(cctx.localNode());
> Collection affNodes = nodes(cctx, null, null); //HERE WE 
> HAVE BOTH NODES AT affNodes
> return affNodes.isEmpty() ? affNodes : 
> Collections.singletonList(F.rand(affNodes)) {noformat}
>  



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

[jira] [Commented] (IGNITE-4022) IgniteServices soesn't throw an exception if there are no server nodes

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov commented on IGNITE-4022:
--

With this approach we will get such warnings for every reassignment and every 
service, that wasn't assigned to any nodes. It will flood the log.

I think, we should print such warning in two cases:
 * This is the first time the assignments are calculated, i.e. {{oldAssigns == 
null}}
 * Old assignments are not empty, i.e. there was at least one assigned node 
after last reassignment.

In this case warnings will be printed only during first assignment and when 
nodes with last working service instances are brought down.

> IgniteServices soesn't throw an exception if there are no server nodes
> --
>
> Key: IGNITE-4022
> URL: https://issues.apache.org/jira/browse/IGNITE-4022
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Alexander Belyak
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> If you call deployNodeSingleton method, but there are no server nodes in 
> IgniteServices base ClusterGroup - you will never know about it and can't 
> find deployed service instance. Probably we should print out these errors in 
> logs as well.



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

[jira] [Assigned] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-8429:
--

Assignee: Ivan Rakov

> Unexpected error during incorrect WAL segment decompression, causes node 
> termination.
> -
>
> Key: IGNITE-8429
> URL: https://issues.apache.org/jira/browse/IGNITE-8429
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> File decompressor failure due to incorrect (zero-length) archived segment. 
> 2018-04-30 00:00:02.811 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  Critical system error detected. Will be handled accordingly to configured 
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, 
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104)
> 2018-04-30 00:00:02.812 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  JVM will be halted immediately due to the failure: 
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> touch 0754.wal
> zip 0754.wal.zip 0754.wal
> ls -l
> -rw-rw-r-- 1 dmitriy dmitriy   0 май  1 16:40 0754.wal
> -rw-rw-r-- 1 dmitriy dmitriy 190 май  1 16:46 0754.wal.zip
> Archive:  /tmp/temp/0754.wal.zip
>  Length   MethodSize  CmprDateTime   CRC-32   Name
>   --  ---  -- -   
>0  Stored0   0% 2018-05-01 16:40   0754.wal
>   ---  ------
>00   0%1 file
> We should softly handle this situation: print message in log and continue the 
> decompression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Updated] (IGNITE-8435) Inconsistent data after StopNodeFailureHandler handles process termination

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8435:

Fix Version/s: 2.5

> Inconsistent data after StopNodeFailureHandler handles process termination
> --
>
> Key: IGNITE-8435
> URL: https://issues.apache.org/jira/browse/IGNITE-8435
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Steps to reproduce:
> 1. Cluster started with StopNodeFailureHandler in config.
> 2. Upload data to the caches and run accounts task (transfer the amount from 
> one account to another for some cache).
> 3. Terminate one thread (ttl-cleanup-worker for example for one node).
> 4. Wait until accounts task finished the work.
> 5. Check the sum for caches.
> Expected result:
> The sum is the same as before thread rermination.
> Actual result:
> The sum is not the same for some caches.
> Also, I see these exception in the logs for node with terminated thread:
> {code:java}
> [13:08:37,709][SEVERE][sys-stripe-1-#2][GridNearTxLocal] Commit failed.
> class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Commit produced a runtime exception (all transaction entries will be 
> invalidated): 
> GridDhtTxRemote[xid=8e4906dd261--0815-47fa--0004, 
> xidVersion=GridCacheVersion [topVer=135612410, order=1524132517096, nod
> eOrder=4], concurrency=OPTIMISTIC, isolation=REPEATABLE_READ, 
> state=COMMITTING, invalidate=false, rollbackOnly=false, 
> nodeId=6f5954fa-e283-4506-9344-7a8914774681, timeout=4990, duration=41]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:742)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:815)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1316)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1228)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>  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 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
>  at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on 
> search row: 
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1aa35c0b
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1668)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1782)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:359)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3604)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3580)
>  at 
> 

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Roman Meerson (JIRA)]

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

Roman Meerson commented on IGNITE-6879:
---

[~dpavlov] I faced with same problem and it fixed by changing spring version to 
old one.

We couldn`t just add two version because if we do so we have to duplicate 
*ignite-spring* module and live with 2 modules for spring and with 2 moodules 
for spring data.

With old spring version tests of both modules works good

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
> Fix For: 2.6
>
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Commented] (IGNITE-8421) ZkDistributedCollectDataFuture fails to delete future data in case of concurrent deletion

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-8421:
-

Merged to ignite-2.5 branch.

> ZkDistributedCollectDataFuture fails to delete future data in case of 
> concurrent deletion
> -
>
> Key: IGNITE-8421
> URL: https://issues.apache.org/jira/browse/IGNITE-8421
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.5
>
>
> In *ZkDistributedCollectDataFuture#deleteFutureData* method 
> KeeperException.NoNodeException may be thrown but the exception isn't 
> critical in this context and doesn't require special handling (just logging 
> is enough).
> However *deleteFutureData* relies on *ZookeeperClient#getChildren* which 
> reacts on any exception (including NoNodeException) by killing current Ignite 
> node.
> Another implementation of *ZookeeperClient#getChildren* is needed which 
> tolerates NoNodeException.



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

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

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-7347:


[~dpavlov], approved.

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



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

[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-8347:
-

Merged to ignite-2.5 branch.

> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}} 
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the 
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite 
> cluster from the {{beforeTestsStarted()}} (this method is called from the 
> {{main}} thread and alive for all tests in a test suite).



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

[jira] [Comment Edited] (IGNITE-640) Implement IgniteMultimap data structures

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-640 at 5/7/18 2:52 PM:
---

Hi [~aakhmedov], I've checked tests, there are several suspicious failures
 - .NET: IgniteParityTest.TestIgnite[ (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8364830731500038749=pull%2F3926%2Fhead=testDetails]
 - 2 times
 - IgniteClientTestSuite: ClientReconnectionSelfTest.testNoFailedReconnection[ 
(fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3141249888117413735=pull%2F3926%2Fhead=testDetails]
 
 - IgniteCacheQuerySelfTestSuite3: 
CacheContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerAndRegularListenerAsync[
 (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4610502389755369639=pull%2F3926%2Fhead=testDetails]
 
 - IgniteBinarySimpleNameMapperBasicTestSuite: 
StopNodeOrHaltFailureHandlerTest.testJvmHalted[ (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2179356000860350976=pull%2F3926%2Fhead=testDetails]
 
 - IgniteCacheTestSuite4: 
CacheGetEntryOptimisticReadCommittedSeltTest.testPartitionedTransactional[ 
(fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3635582098648232308=pull%2F3926%2Fhead=testDetails]
 

 

These failures are not defenetely caused by this change, but it may be.  I 
would appreciate if failures would be double-checked.


was (Author: dpavlov):
Hi [~aakhmedov], I've checked tests, there are several suspicious failures

- .NET: IgniteParityTest.TestIgnite[ (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8364830731500038749=pull%2F3926%2Fhead=testDetails]
 - 2 times
 - IgniteClientTestSuite: ClientReconnectionSelfTest.testNoFailedReconnection[ 
(fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3141249888117413735=pull%2F3926%2Fhead=testDetails]
 
-IgniteCacheQuerySelfTestSuite3: 
CacheContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerAndRegularListenerAsync[
 (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4610502389755369639=pull%2F3926%2Fhead=testDetails]
 
- IgniteBinarySimpleNameMapperBasicTestSuite: 
StopNodeOrHaltFailureHandlerTest.testJvmHalted[ (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2179356000860350976=pull%2F3926%2Fhead=testDetails]
 
- IgniteCacheTestSuite4: 
CacheGetEntryOptimisticReadCommittedSeltTest.testPartitionedTransactional[ 
(fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3635582098648232308=pull%2F3926%2Fhead=testDetails]
 

 

These failures are not defenetely caused by this change, but it may be, so I 
would appreciate if failures would be double-checked.

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.6
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection 

[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-640:
---

Hi [~aakhmedov], I've checked tests, there are several suspicious failures

- .NET: IgniteParityTest.TestIgnite[ (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8364830731500038749=pull%2F3926%2Fhead=testDetails]
 - 2 times
 - IgniteClientTestSuite: ClientReconnectionSelfTest.testNoFailedReconnection[ 
(fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3141249888117413735=pull%2F3926%2Fhead=testDetails]
 
-IgniteCacheQuerySelfTestSuite3: 
CacheContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerAndRegularListenerAsync[
 (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4610502389755369639=pull%2F3926%2Fhead=testDetails]
 
- IgniteBinarySimpleNameMapperBasicTestSuite: 
StopNodeOrHaltFailureHandlerTest.testJvmHalted[ (fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2179356000860350976=pull%2F3926%2Fhead=testDetails]
 
- IgniteCacheTestSuite4: 
CacheGetEntryOptimisticReadCommittedSeltTest.testPartitionedTransactional[ 
(fail rate 
0,0%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3635582098648232308=pull%2F3926%2Fhead=testDetails]
 

 

These failures are not defenetely caused by this change, but it may be, so I 
would appreciate if failures would be double-checked.

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.6
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new 

[jira] [Assigned] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov reassigned IGNITE-8430:
-

Assignee: Anton Kalashnikov

> implement getCurrentCoordinator method in IgniteMXBean
> --
>
> Key: IGNITE-8430
> URL: https://issues.apache.org/jira/browse/IGNITE-8430
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, user can obtain coordinator node id via JMX attribute Coordinator 
> of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean.
> However, to get this attribute, external utility JMX must first understand 
> which discovery SPI implementation is used at current grid, which is 
> inconvenient. Would be much better if that attribute was located in same 
> instance no matter which Disco SPI was configured.
> Please, add String CurrentCoordinator attribute to Ignite MX bean with 
> following meaning:
>   - for the cases, when node does not know current coordinator (e.g. 
> getCoordinator returns null), attribute should be empty string ''
>   - for the case, when node knows current coordinator, return following 
> coordinator properties formatted as string, separated by ',':
>-- Coordinator IP address
>-- Coordinator node ID
>-- Coordinator node order
>-- Coordinator Fully Qualified Domain Name



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

[jira] [Commented] (IGNITE-7771) Names of Ignite JMX beans should not be quoted unless required

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7771:


[~aealeksandrov] please set In Progress or Open status if you are working on 
proposals.

> Names of Ignite JMX beans should not be quoted unless required
> --
>
> Key: IGNITE-7771
> URL: https://issues.apache.org/jira/browse/IGNITE-7771
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Names of Ignite JMX beans and bean groups are currently quoted if they 
> contain non-alphanumeric characters. This leads to names with spaces, e.g. 
> Thread Pools, appearing as "Thread Pools". Moreover, Thread Pools and "Thread 
> Pools" are recognized by JMX as distinct names, so code accessing that MBean 
> needs to take that into account.
> It would be better not to quote the bean and group names unless they contain 
> specific control characters. That way users won't need to quote names in 
> their JMX clients.



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7347:


[~ivan.glukos], please approve dontaion if looks good now.

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



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

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

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov commented on IGNITE-7347:
--

Fixed.

[~dpavlov], could you merge it?

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



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

[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-8238:
--

[~sharpler], 

Ignite itself throws RuntimeException from 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)

This behavior isn't mentioned in javadoc. I think we shouldn't use 
RuntimeException class directly, but throws smth meaningful either 
IgniteException or IllegalStateException. 

> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



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

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6879:


Same ocurred on TeamCity 
[https://ci.ignite.apache.org/viewLog.html?buildId=1272331&] 

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
> Fix For: 2.6
>
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Updated] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8347:

Fix Version/s: (was: 2.6)
   2.5

> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}} 
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the 
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite 
> cluster from the {{beforeTestsStarted()}} (this method is called from the 
> {{main}} thread and alive for all tests in a test suite).



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

[jira] [Updated] (IGNITE-8421) ZkDistributedCollectDataFuture fails to delete future data in case of concurrent deletion

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8421:

Fix Version/s: (was: 2.6)
   2.5

> ZkDistributedCollectDataFuture fails to delete future data in case of 
> concurrent deletion
> -
>
> Key: IGNITE-8421
> URL: https://issues.apache.org/jira/browse/IGNITE-8421
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.5
>
>
> In *ZkDistributedCollectDataFuture#deleteFutureData* method 
> KeeperException.NoNodeException may be thrown but the exception isn't 
> critical in this context and doesn't require special handling (just logging 
> is enough).
> However *deleteFutureData* relies on *ZookeeperClient#getChildren* which 
> reacts on any exception (including NoNodeException) by killing current Ignite 
> node.
> Another implementation of *ZookeeperClient#getChildren* is needed which 
> tolerates NoNodeException.



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

[jira] [Updated] (IGNITE-8447) .Net support of DataStreamer.perThreadBufferSize

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8447:
---
Labels: MakeTeamcityGreenAgain  (was: )

> .Net support of DataStreamer.perThreadBufferSize 
> -
>
> Key: IGNITE-8447
> URL: https://issues.apache.org/jira/browse/IGNITE-8447
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Need to add support of DataStreamer#perThreadBuffer property.
> It was added in IGNITE-6699.
> Related failed test - DataStreamerTest.TestBufferSize
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-7912:
--

Merged latest changes and added newest TC build. Tests seems to be ok.

> control.sh script should show used WAL-segments
> ---
>
> Key: IGNITE-7912
> URL: https://issues.apache.org/jira/browse/IGNITE-7912
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Filatov
>Assignee: Ivan Daschinskiy
>Priority: Minor
>
> We have to erase wal archive because wal archive can grow large and we must 
> have safe way to remove unused segments to free disk space.



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

[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-8238:
-

[~amashenkov] There are too many operations which can throw *RuntimeException* 
somehow. And I see no way to determinate can some method from public API throw 
*RuntimeException* or not. Do you know some IDEA plug-in or ather tool for such 
checking?

As I see we can't just replace all *RuntimeException* with 
*IllegalStateException*.

> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



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

[jira] [Commented] (IGNITE-8447) .Net support of DataStreamer.perThreadBufferSize

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8447:


GitHub user nizhikov opened a pull request:

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

IGNITE-8447: .Net support of DataStreamer#perThreadBufferSize



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

$ git pull https://github.com/nizhikov/ignite IGNITE-8447

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

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

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

This closes #3952


commit 4eea781a0006e70dcaf456c56f7329cb11ec8db1
Author: Nikolay Izhikov 
Date:   2018-05-07T13:46:39Z

IGNITE-8447: .Net support of DataStreamer#perThreadBufferSize




> .Net support of DataStreamer.perThreadBufferSize 
> -
>
> Key: IGNITE-8447
> URL: https://issues.apache.org/jira/browse/IGNITE-8447
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.6
>
>
> Need to add support of DataStreamer#perThreadBuffer property.
> It was added in IGNITE-6699.
> Related failed test - DataStreamerTest.TestBufferSize
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-6699) Optimize client-side data streamer performance

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-6699:
-

[~dpavlov] I've created IGNITE-8447 to fix issue.
I'll provide patch shortly.

> Optimize client-side data streamer performance
> --
>
> Key: IGNITE-6699
> URL: https://issues.apache.org/jira/browse/IGNITE-6699
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Currently if a user has several server nodes and a single client node with 
> single thread pushing data to streamer, he will not be able to load data at 
> maximum speed. On the other hand, if he start several data loading threads, 
> throughput will increase. 
> One of root causes of this is bad data streamer design. Method 
> {{IgniteDataStreamer.addData(K, V)}} returns new feature for every operation, 
> this is too fine grained approach. Also it generates a lot of garbage and 
> causes contention on streamer internals. 
> Proposed implementation flow:
> 1) Compare performance of {{addData(K, V)}} vs {{addData(Collection)}} 
> methods from one thread in distributed environment. The latter should show 
> considerably higher throughput.
> 2) Users should receive per-batch features, rather than per-key. 
> 3) Try caching thread data in some collection until it is large enough to 
> avoid contention and unnecessary allocations.



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

[jira] [Created] (IGNITE-8447) .Net support of DataStreamer.perThreadBufferSize

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-8447:
---

 Summary: .Net support of DataStreamer.perThreadBufferSize 
 Key: IGNITE-8447
 URL: https://issues.apache.org/jira/browse/IGNITE-8447
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.6


Need to add support of DataStreamer#perThreadBuffer property.
It was added in IGNITE-6699.

Related failed test - DataStreamerTest.TestBufferSize

https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-8375) NPE due to race on cache stop and timeout handler execution.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-8375:
-

[~ascherbakov] As I see in this method the *cacheCfg* is ** used twice:
{code:java}
if (!skipStore && (read || cctx.loadPreviousValue()) && cctx.readThrough() && 
(needReturnVal || read)) {
{code}
 # cctx.loadPreviousValue() calls *cacheCfg*.isLoadPreviousValue()
 # cctx.readThrough() calls *cacheCfg*.isReadThrough() && !skipStore();

Will it be a valid solution the add *cctx.config() != null && ...* into 
condition?

> NPE due to race on cache stop and timeout handler execution.
> 
>
> Key: IGNITE-8375
> URL: https://issues.apache.org/jira/browse/IGNITE-8375
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexei Scherbakov
>Priority: Major
> Fix For: 2.6
>
>
> {noformat}
> 2018-04-22 22:03:08.547 [INFO 
> ][Thread-25420][o.a.i.i.p.cache.GridCacheProcessor] Stopped cache 
> [cacheName=com.sbt.cdm.api.model.published.dictionary.PublishedSystem, 
> group=CACHEGROUP_DICTIONARY]
> 2018-04-22 22:03:08.548 
> [ERROR][grid-timeout-worker-#119%DPL_GRID%DplGridNodeName%][o.a.i.i.p.t.GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.loadPreviousValue(GridCacheContext.java:1450)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.loadMissingFromStore(GridDhtLockFuture.java:1030)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:731)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$900(GridDhtLockFuture.java:82)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1133)
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> NPE caused by execution of method [1] during timeout handler execution [2]:
> cacheCfg.isLoadPreviousValue() throws NPE because cacheCfg can be nulled by 
> [3] on stop.
> [1] 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture#loadMissingFromStore
> [2] 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.LockTimeoutObject#onTimeout
> [3] org.apache.ignite.internal.processors.cache.GridCacheContext#cleanup



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

[jira] [Updated] (IGNITE-6879) Support Spring 2.0

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6879:
---
Fix Version/s: 2.6

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
> Fix For: 2.6
>
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Commented] (IGNITE-8422) Zookeeper discovery split brain detection shouldn't consider client nodes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8422:


GitHub user Jokser opened a pull request:

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

IGNITE-8422 Zookeeper discovery split-brain resolving improvement



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

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

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

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

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

This closes #3951






> Zookeeper discovery split brain detection shouldn't consider client nodes
> -
>
> Key: IGNITE-8422
> URL: https://issues.apache.org/jira/browse/IGNITE-8422
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Zookeeper discovery checks each splitted cluster on full 
> connectivity taking into account client nodes. This is not correct, because 
> server and client nodes may use different networks to connect to each other. 
> It means that there can be client which sees both parts of splitted cluster 
> and breaks split brain recovery - full connected part of server nodes will be 
> never find.
> We should exclude client nodes from split brain analysis and improve split 
> brain tests to make them truly fair.



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

[jira] [Updated] (IGNITE-8322) Yardstick benchmark preloading option

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8322:

Fix Version/s: 2.6

> Yardstick benchmark preloading option
> -
>
> Key: IGNITE-8322
> URL: https://issues.apache.org/jira/browse/IGNITE-8322
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Major
> Fix For: 2.6
>
>
> Yardstick has no benchmarks with eviction on the disk (PDS). For that puspose 
> we need following:
> 1. Make new configuration and put every cache into a separate date region:
> atomic,tx,atomic-index,query,compute
> 2. Add a new preload option for a benchmark: preload up to a size passed from 
> that option. There two options:
>  * total size of preload data (bytes)
>  * the size of data in memory against total size (percent)



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

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6879:


Hi [~homich], I've checked changes and it looks good to me, but I've faced with 
tests failures for old spring data version

 
{noformat}
java.lang.NoClassDefFoundError: 
org/springframework/beans/factory/config/BeanDefinitionCustomizer
at 
org.springframework.context.annotation.AnnotatedBeanDefinitionReader.registerBean(AnnotatedBeanDefinitionReader.java:145)
at 
org.springframework.context.annotation.AnnotatedBeanDefinitionReader.register(AnnotatedBeanDefinitionReader.java:135)
at 
org.springframework.context.annotation.AnnotationConfigApplicationContext.register(AnnotationConfigApplicationContext.java:158)
at 
org.apache.ignite.springdata.IgniteSpringDataCrudSelfTest.beforeTestsStarted(IgniteSpringDataCrudSelfTest.java:49)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:611)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:490)
at junit.framework.TestCase.runBare(TestCase.java:139)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.ClassNotFoundException: 
org.springframework.beans.factory.config.BeanDefinitionCustomizer
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 21 more{noformat}
Can it be solved? My guess it can be done with some modules dependencies 
separation, e.g.

spring43.version for old module.

spring.version

could you please address?

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Commented] (IGNITE-7708) Ignite Compute has flaky failures

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7708:


According to mass run-all results this fix helped. 
[http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-5th-mass-run-all-td30174.html]

 

I think most of failures fixed came from this fix. I suggest to resolve this 
issue as far as  IGNITE-8079 

> Ignite Compute has flaky failures 
> --
>
> Key: IGNITE-7708
> URL: https://issues.apache.org/jira/browse/IGNITE-7708
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1093187=IgniteTests24Java8_IgniteComputeGrid
>  
> https://ci.ignite.apache.org/viewLog.html?buildId=1092214=IgniteTests24Java8_IgniteComputeGrid
> IgniteBinaryObjectsComputeGridTestSuite
> IgniteComputeBasicConfigVariationsFullApiTestSuite
> it is required to fix flaky failure or remove tests from  suite because of 
> default notifications were enabled recently.
> Flaky failures generates a lot of unecessary spam.
> {noformat}
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollection
>  (fail rate 9%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollectionAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollection
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApply
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCall
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testExecuteTask
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollectionWithReducerAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testAffinityCall
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastCallableAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastCallable
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollectionAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollectionWithReducer
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testExecuteTaskClassAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastClosure
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> 

[jira] [Updated] (IGNITE-7708) Ignite Compute has flaky failures

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7708:
---
Fix Version/s: 2.6

> Ignite Compute has flaky failures 
> --
>
> Key: IGNITE-7708
> URL: https://issues.apache.org/jira/browse/IGNITE-7708
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1093187=IgniteTests24Java8_IgniteComputeGrid
>  
> https://ci.ignite.apache.org/viewLog.html?buildId=1092214=IgniteTests24Java8_IgniteComputeGrid
> IgniteBinaryObjectsComputeGridTestSuite
> IgniteComputeBasicConfigVariationsFullApiTestSuite
> it is required to fix flaky failure or remove tests from  suite because of 
> default notifications were enabled recently.
> Flaky failures generates a lot of unecessary spam.
> {noformat}
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollection
>  (fail rate 9%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollectionAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollection
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApply
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCall
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testExecuteTask
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollectionWithReducerAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testAffinityCall
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastCallableAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastCallable
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollectionAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollectionWithReducer
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testExecuteTaskClassAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastClosure
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testDeployExecuteByName
>  (fail rate 8%) 
>  
> 

[jira] [Commented] (IGNITE-8400) Flaky failure of IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup (Grid is in invalid state)

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-8400:
-

LGTM! Merged to master branch. Thanks!

> Flaky failure of 
> IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup 
> (Grid is in invalid state)
> -
>
> Key: IGNITE-8400
> URL: https://issues.apache.org/jira/browse/IGNITE-8400
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Test fails sometimes on TeamCity with exception:
> {noformat}
> java.lang.IllegalStateException: Grid is in invalid state to perform this 
> operation. It either not started yet or has already being or have stopped 
> [igniteInstanceName=cache.IgniteTopologyValidatorGridSplitCacheTest6, 
> state=STOPPED]
> {noformat}
> Before this exception node is dropped out of topology by coordinator:
> {noformat}
> [tcp-disco-msg-worker-#7831%cache.IgniteTopologyValidatorGridSplitCacheTest6%][IgniteCacheTopologySplitAbstractTest$SplitTcpDiscoverySpi]
>  Node is out of topology (probably, due to short-time network problems).
> {noformat}



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

[jira] [Assigned] (IGNITE-8444) Authentication: add documentation about user management SQL command and authentication feature

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-8444:


Assignee: Denis Magda  (was: Taras Ledkov)

> Authentication: add documentation about user management SQL command and 
> authentication feature
> --
>
> Key: IGNITE-8444
> URL: https://issues.apache.org/jira/browse/IGNITE-8444
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
> Environment: Adds overview for authentication feature and 
> documentation for SQL commands:
> - CREATE USER
> - ALTER USER
> - DROP USER
>Reporter: Taras Ledkov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Comment Edited] (IGNITE-8444) Authentication: add documentation about user management SQL command and authentication feature

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-8444 at 5/7/18 12:37 PM:
---

[~dmagda], please review the docs changes.

I've crated three new page for SQL commands:
- [CREATE 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/create-user]
- [ALTER 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/alter-user]
- [DROP 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/drop-user]

I'll change the [parent DDL 
page|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/ddl] after 
review and publish Ignite 2.5 version.


was (Author: tledkov-gridgain):
I've crated three new page for SQL commands:
- [CREATE 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/create-user]
- [ALTER 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/alter-user]
- [DROP 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/drop-user]

I'll change the [parent DDL 
page|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/ddl] after 
review and publish Ignite 2.5 version.

> Authentication: add documentation about user management SQL command and 
> authentication feature
> --
>
> Key: IGNITE-8444
> URL: https://issues.apache.org/jira/browse/IGNITE-8444
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
> Environment: Adds overview for authentication feature and 
> documentation for SQL commands:
> - CREATE USER
> - ALTER USER
> - DROP USER
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-8444) Authentication: add documentation about user management SQL command and authentication feature

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-8444:
--

I've crated three new page for SQL commands:
- [CREATE 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/create-user]
- [ALTER 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/alter-user]
- [DROP 
USER|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/drop-user]

I'll change the [parent DDL 
page|https://dash.readme.io/project/apacheignite-sql/v2.4/docs/ddl] after 
review and publish Ignite 2.5 version.

> Authentication: add documentation about user management SQL command and 
> authentication feature
> --
>
> Key: IGNITE-8444
> URL: https://issues.apache.org/jira/browse/IGNITE-8444
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
> Environment: Adds overview for authentication feature and 
> documentation for SQL commands:
> - CREATE USER
> - ALTER USER
> - DROP USER
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Assigned] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-8037:


Assignee: Taras Ledkov

> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Taras Ledkov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:120)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:297)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:238)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.reconnectClientNode(DynamicColumnsAbstractConcurrentSelfTest.java:804)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.checkClientReconnect(DynamicColumnsAbstractConcurrentSelfTest.java:781)
> at 
> 

[jira] [Comment Edited] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy edited comment on IGNITE-8437 at 5/7/18 12:19 PM:
---

[~ascherbakov] I suppose, that it's necessary also add this to pom.xml in 
zookeeper module:
{code:xml}


   
org.codehaus.mojo
exec-maven-plugin
1.3.2


org.apache.ignite
ignite-tools
${project.version}




process-classes

java



true

org.apache.ignite.tools.classgen.ClassesGenerator


${project.basedir}/target/classes




org.apache.ignite.spi.discovery.zk.internal





{code}


was (Author: ivandasch):
[~ascherbakov] I suppose, that it's necessary also add this to pom.xml in 
zookeeper module:


{code:xml}


   
org.codehaus.mojo
exec-maven-plugin
1.3.2


org.apache.ignite
ignite-tools
${project.version}




process-classes

java



true

org.apache.ignite.tools.classgen.ClassesGenerator


${project.basedir}/target/classes




org.apache.ignite.hadoop:org.apache.ignite.internal.processors.hadoop





{code}


> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
>  Issue Type: Improvement
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>  
> {code:java}
> 2018-05-03 16:56:36.225 
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
>  Failed to process client request [ses=GridSelectorNioSessionImpl 
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395 
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-rest-0, 
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false, 
> hashCode=1766410348, interrupted=false, 
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]], 
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null, 
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211, 
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984, 
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553, 
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075, 
> lastRcvTime=1525355796175, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d], 
> routerClient=false], directMode=false]], accepted=true]], 
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask, 
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class 
> org.apache.ignite.IgniteCheckedException: Failed to serialize object: 
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2, 
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean 
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6, 
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult 
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at 
> 

[jira] [Commented] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-8437:
--

[~ascherbakov] I suppose, that it's necessary also add this to pom.xml in 
zookeeper module:


{code:xml}


   
org.codehaus.mojo
exec-maven-plugin
1.3.2


org.apache.ignite
ignite-tools
${project.version}




process-classes

java



true

org.apache.ignite.tools.classgen.ClassesGenerator


${project.basedir}/target/classes




org.apache.ignite.hadoop:org.apache.ignite.internal.processors.hadoop





{code}


> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
>  Issue Type: Improvement
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>  
> {code:java}
> 2018-05-03 16:56:36.225 
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
>  Failed to process client request [ses=GridSelectorNioSessionImpl 
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395 
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-rest-0, 
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false, 
> hashCode=1766410348, interrupted=false, 
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]], 
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null, 
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211, 
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984, 
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553, 
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075, 
> lastRcvTime=1525355796175, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d], 
> routerClient=false], directMode=false]], accepted=true]], 
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask, 
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class 
> org.apache.ignite.IgniteCheckedException: Failed to serialize object: 
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2, 
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean 
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6, 
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult 
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192)
> at 
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> 

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Paul Anderson (JIRA)]

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

Paul Anderson commented on IGNITE-8439:
---

happy to test... does not seem committed yet... hope this could get into 2.5..

I don't wish to seem judgemental, but the whole class seems it could do with a 
little rework 

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Updated] (IGNITE-4788) JVM crash while accessing offheap rows of SQL query result.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4788:

Component/s: (was: swap)

> JVM crash while accessing offheap rows of SQL query result.
> ---
>
> Key: IGNITE-4788
> URL: https://issues.apache.org/jira/browse/IGNITE-4788
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Major
> Attachments: hs_err_pid18543.log.txt, log.txt
>
>
> JVM crashed with SIGSEGV error while iterating over SQL query offheap rows.



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

[jira] [Updated] (IGNITE-4751) JVM crash while accessing Offheap entry.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4751:

Component/s: (was: swap)

> JVM crash while accessing Offheap entry.
> 
>
> Key: IGNITE-4751
> URL: https://issues.apache.org/jira/browse/IGNITE-4751
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7, 1.8
>Reporter: Andrew Mashenkov
>Priority: Critical
> Attachments: mm-rbp-server-err-pid8466.log
>
>
> JVM crashed with SIGSEGV error while iterating over offheap entries on stable 
> topology.
> PFA logs attached.
> Partitioned OffHeap-Tiered  cache with swap enabled has been configured.



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

[jira] [Updated] (IGNITE-3810) FileSwapSpaceSpi can hang when large value is written

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3810:

Component/s: (was: swap)
 general

> FileSwapSpaceSpi can hang when large value is written
> -
>
> Key: IGNITE-3810
> URL: https://issues.apache.org/jira/browse/IGNITE-3810
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 1.8
>
> Attachments: SwapSpaceTest.java
>
>
> Test reproducing the issue is attached.
> Weirdly, the value of size {{1024 * 1024 - 48}} is successfully written, but 
> when it is only one byte bigger, the swap space hangs.



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

[jira] [Updated] (IGNITE-4795) Inherit TransactionException and update Javadoc

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4795:

Component/s: (was: website)

> Inherit TransactionException and update Javadoc
> ---
>
> Key: IGNITE-4795
> URL: https://issues.apache.org/jira/browse/IGNITE-4795
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: documentation, important
> Fix For: 2.0
>
>
> Understanding transactional behaviour is not clear in Javadoc at this point 
> of time. Even after reading website some doubt remain.
> Proposal.
> 1. Create {{TransactionException}} as the marker of transactional methods and 
> inherit from it all the existed transactional exceptions like 
> {{TransactionTimeoutException}}, {{TransactionRollbackException}}, 
> {{TransactionHeuristicException}}, {{TransactionOptimisticException}}, etc.
> 2. Update all the transactional methods ({{get}}, {{put}}, {{invoke}}, etc) 
> as throwing the base {{TransactionException}}. Comment all the 
> {{IgniteCache}} methods whether they are transactional or not, add {{@see 
> TransactionException}} annotation.
> 3. Make extensive documentation in the header of {{TransactionException}} to 
> get understanding of transactional and non-transactional methods behaviour.
> 4. Update website and Javadoc to clarify the fact that {{put}} value is 
> cached within the transaction and affects successive {{get}}.



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

[jira] [Updated] (IGNITE-5106) Website still contains links to to "incubator-ignite"

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5106:

Component/s: (was: website)
 site

> Website still contains links to to "incubator-ignite" 
> --
>
> Key: IGNITE-5106
> URL: https://issues.apache.org/jira/browse/IGNITE-5106
> Project: Ignite
>  Issue Type: Bug
>  Components: site
>Affects Versions: 1.1.4
>Reporter: Konstantin Boudnik
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.0
>
>
> At least some of the examples referred by the website pages are pointed to 
> "incubator-ignite" mirror on the github. Which were empty for a long time.
> Let's get this fixed.



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

[jira] [Updated] (IGNITE-6038) Update Data Grid page on the website to reflect Persistence

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6038:

Component/s: (was: website)
 site

> Update Data Grid page on the website to reflect Persistence
> ---
>
> Key: IGNITE-6038
> URL: https://issues.apache.org/jira/browse/IGNITE-6038
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>Priority: Major
>  Labels: site
>
> # Change the diagram to reflect native persistence
> # add native persistence sub-section
> # add native persistence feature



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

[jira] [Updated] (IGNITE-2510) Auto swap spi creation on link cache with swap to cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2510:

Component/s: (was: website)
 site

> Auto swap spi creation on link cache with swap to cluster
> -
>
> Key: IGNITE-2510
> URL: https://issues.apache.org/jira/browse/IGNITE-2510
> Project: Ignite
>  Issue Type: Sub-task
>  Components: site
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Priority: Major
> Fix For: 1.6
>
>
> Add swap spi on save of cluster when swap spi is not configured and linked 
> cache with enabled swap.



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

[jira] [Updated] (IGNITE-2743) Broken download page on ignite.apache.org

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2743:

Component/s: (was: website)
 site

> Broken download page on ignite.apache.org
> -
>
> Key: IGNITE-2743
> URL: https://issues.apache.org/jira/browse/IGNITE-2743
> Project: Ignite
>  Issue Type: Bug
>  Components: site
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.7
>
>
> There are two download pages:
> * https://ignite.apache.org/download.cgi (correct)
> * https://ignite.apache.org/download (incorrect)
> All links are broken on the second one. You can't get on this broken page 
> from our website, but it is the first page in Google for "apache ignite 
> download": https://www.google.ru/search?q=apache+ignite+download
> Ideally, https://ignite.apache.org/download should be the correct link (.cgi 
> in the url is from 90's)



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

[jira] [Updated] (IGNITE-6040) Update Distributed SQL Database page on the website

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6040:

Component/s: (was: website)
 site

> Update Distributed SQL Database page on the website
> ---
>
> Key: IGNITE-6040
> URL: https://issues.apache.org/jira/browse/IGNITE-6040
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>Priority: Major
>  Labels: site
>
> # change DDL examples to pure SQL (without Java)
> # change DML examples to pure SQL (without Java)
> # change Query examples to pure SQL (without Java)
> # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java
> # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C#
> # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, 
> PHP, etc.



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

[jira] [Updated] (IGNITE-6039) Update Persistence page on the website

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6039:

Component/s: (was: website)
 site

> Update Persistence page on the website
> --
>
> Key: IGNITE-6039
> URL: https://issues.apache.org/jira/browse/IGNITE-6039
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Dmitriy Setrakyan
>Assignee: Prachi Garg
>Priority: Major
>  Labels: site
>
> # add Write-Ahead-Log (WAL) sub-section
> # add Main Storage sub-section
> # add Checkpointing sub-section
> # add Redundancy sub-section (describe backups)
> # add Durability sub-section (describe restarts)
> # add Configuration example
> # provide a better diagram if possible



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

[jira] [Updated] (IGNITE-7210) Web console: Fix show time of "Connected clusters: N" label

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7210:

Component/s: (was: website)
 site

> Web console: Fix show time of "Connected clusters: N" label
> ---
>
> Key: IGNITE-7210
> URL: https://issues.apache.org/jira/browse/IGNITE-7210
> Project: Ignite
>  Issue Type: Bug
>  Components: site
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.4
>
>
> Now that label showed quickly when login screen still shown or page is fully 
> empty.
> Should appear together with page content.



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

[jira] [Updated] (IGNITE-6041) Update Gettting Started documentation page

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6041:

Component/s: (was: website)
 site

> Update Gettting Started documentation page
> --
>
> Key: IGNITE-6041
> URL: https://issues.apache.org/jira/browse/IGNITE-6041
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Dmitriy Setrakyan
>Assignee: Prachi Garg
>Priority: Major
>  Labels: docs
>
> Update Getting Started guide in the documentation [1]:
> # show enable/disable persistence flag
> # add SQL connectivity example (create, insert, select)
> # put data grid example right after SQL
> # add collocated computation example to the data grid example
> # add service grid example
> [1] https://apacheignite.readme.io/docs/getting-started



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

[jira] [Updated] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6036:

Component/s: (was: website)
 site

> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>Priority: Major
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036
> Update Ignite overview on the db-engines once the ticket is ready: 
> https://db-engines.com/en/system/Ignite



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