date:20171207

[jira] [Assigned] (IGNITE-7051) SQL Rename table support

2017-12-07 Thread Dmitriy Setrakyan (JIRA)


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

Dmitriy Setrakyan reassigned IGNITE-7051:
-

Assignee: Vladimir Ozerov

> SQL Rename table support
> 
>
> Key: IGNITE-7051
> URL: https://issues.apache.org/jira/browse/IGNITE-7051
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Blackfield
>Assignee: Vladimir Ozerov
>
> Use case was discussed at length here: 
> http://apache-ignite-users.70518.x6.nabble.com/Continuous-update-Data-Grid-Cache-td2075.html#a17641
> Currently, we have to load data to second table, the client then has to 
> change their query to query this 
> new table. Drop the old table. 
> The latest suggestion in the above thread to "load new data set in the same 
> cache and remove old entries once preloading is finished" is not feasible 
> since for large table and table scan query (thus requires whole dataset to 
> be loaded), it will take a while to load everything - thus increasing the 
> downtime. 
> Table rename support will reduce the downtime greatly. 
> Ref: Postgresql and H2 syntax
> ALTER TABLE TmpTable RENAME TO Table1; 
> Then, one would wrap it within transaction (It appears that this is slated 
> for 2.4/2.5?) to drop old table, rename temp table to original table. 



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

[jira] [Commented] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

2017-12-07 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov commented on IGNITE-6999:


Tested.

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Assigned] (IGNITE-7145) Visor CMD: Fix tests for: Ignite Visor Console

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-7145:
-

Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Visor CMD: Fix tests for: Ignite Visor Console
> --
>
> Key: IGNITE-7145
> URL: https://issues.apache.org/jira/browse/IGNITE-7145
> Project: Ignite
>  Issue Type: Test
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> https://ci.ignite.apache.org/viewLog.html?buildId=984720=buildResultsDiv=Ignite20Tests_IgniteVisorConsoleTestDetach



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

[jira] [Assigned] (IGNITE-7145) Visor CMD: Fix tests for: Ignite Visor Console

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-7145:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

Test fixed. See 3177 pull request.

> Visor CMD: Fix tests for: Ignite Visor Console
> --
>
> Key: IGNITE-7145
> URL: https://issues.apache.org/jira/browse/IGNITE-7145
> Project: Ignite
>  Issue Type: Test
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> https://ci.ignite.apache.org/viewLog.html?buildId=984720=buildResultsDiv=Ignite20Tests_IgniteVisorConsoleTestDetach



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

[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-6999:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Commented] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-6999:
---

Fixed.

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Assigned] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

2017-12-07 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-6976:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-7145) Visor CMD: Fix tests for: Ignite Visor Console

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7145:


GitHub user vsisko opened a pull request:

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

IGNITE-7145 Fixed print of warning message.



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

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

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

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


commit 6be9a94c82884e7fd8620795281fcb8cc4b05600
Author: vsisko 
Date:   2017-12-08T03:32:48Z

IGNITE-7145 Fixed print of warning message.




> Visor CMD: Fix tests for: Ignite Visor Console
> --
>
> Key: IGNITE-7145
> URL: https://issues.apache.org/jira/browse/IGNITE-7145
> Project: Ignite
>  Issue Type: Test
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>
> https://ci.ignite.apache.org/viewLog.html?buildId=984720=buildResultsDiv=Ignite20Tests_IgniteVisorConsoleTestDetach



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

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

2017-12-07 Thread Stanilovsky Evgeny (JIRA)


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

Stanilovsky Evgeny commented on IGNITE-7112:


this fix partially consist in https://github.com/apache/ignite/pull/3175, if 
3175 will be merged, no need in this fix.

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



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

[jira] [Created] (IGNITE-7145) Visor CMD: Fix tests for: Ignite Visor Console

2017-12-07 Thread Vasiliy Sisko (JIRA)

Vasiliy Sisko created IGNITE-7145:
-

 Summary: Visor CMD: Fix tests for: Ignite Visor Console
 Key: IGNITE-7145
 URL: https://issues.apache.org/jira/browse/IGNITE-7145
 Project: Ignite
  Issue Type: Test
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


https://ci.ignite.apache.org/viewLog.html?buildId=984720=buildResultsDiv=Ignite20Tests_IgniteVisorConsoleTestDetach



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

[jira] [Comment Edited] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted

2017-12-07 Thread Andrey Gura (JIRA)


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

Andrey Gura edited comment on IGNITE-6339 at 12/8/17 1:09 AM:
--

Using mmap with {{DEFAULT}} WAL mode and partial fsync improves perfromance 
~10-20% vs master or single writer.


was (Author: agura):
Using mmap with {{DEFAULT}} WAL mode and partial fsync improves perfromance 
~10-20%.

> WAL: Avoid closed by interruption exception when user thread is interrupted
> ---
>
> Key: IGNITE-6339
> URL: https://issues.apache.org/jira/browse/IGNITE-6339
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Blocker
>  Labels: important
> Fix For: 2.4
>
>
> We should have a separate writer thread for WAL that will write completed 
> serialized chunks of data. This will allow us avoid closed by interruption 
> exception when user thread is interrupted.



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

[jira] [Assigned] (IGNITE-7121) visorcmd: there is no output for last command in batch mode in case of using -nq option

2017-12-07 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-7121:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> visorcmd: there is no output for last command in batch mode in case of using 
> -nq option
> ---
>
> Key: IGNITE-7121
> URL: https://issues.apache.org/jira/browse/IGNITE-7121
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.3
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> To reproduce try to execute visorcmd in batch mode 
> {code}
> ignitevisorcmd.bat "-nq -b=commands.visor"
> {code}
> with command file
> {code}
> open -cpath=config/your-config.xml
> config
> {code}
> output of 'config' command will not displayed



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

[jira] [Commented] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-6976:
---

Implemented automatic type detection and value equal to key when it is empty.

> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted

2017-12-07 Thread Andrey Gura (JIRA)


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

Andrey Gura commented on IGNITE-6339:
-

Using mmap with {{DEFAULT}} WAL mode and partial fsync improves perfromance 
~10-20%.

> WAL: Avoid closed by interruption exception when user thread is interrupted
> ---
>
> Key: IGNITE-6339
> URL: https://issues.apache.org/jira/browse/IGNITE-6339
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Blocker
>  Labels: important
> Fix For: 2.4
>
>
> We should have a separate writer thread for WAL that will write completed 
> serialized chunks of data. This will allow us avoid closed by interruption 
> exception when user thread is interrupted.



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

[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

2017-12-07 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-6999:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Comment Edited] (IGNITE-369) Cache manager should switch cache statisticsEnabled property globaly

2017-12-07 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov edited comment on IGNITE-369 at 12/7/17 9:25 PM:
---

[~avinogradov]], 
Current implementation register 
{{javax.cache.management.CacheStatisticsMXBean}} (which are located at 
{{javax.cache}} -> {{CacheStatistics}} -> {{_ignite config_}} -> {{_cache 
name_}}) when {{enableStatistics}} method is invoked.
Ignite also register {{org.apache.ignite.mxbean.CacheMetricsMXBean}} (which 
extends {{javax.cache.management.CacheStatisticsMXBean}}) when cache starts.


was (Author: alex_pl):
[~avinograd], 
Current implementation register 
{{javax.cache.management.CacheStatisticsMXBean}} (which are located at 
{{javax.cache}} -> {{CacheStatistics}} -> {{_ignite config_}} -> {{_cache 
name_}}) when {{enableStatistics}} method is invoked.
Ignite also register {{org.apache.ignite.mxbean.CacheMetricsMXBean}} (which 
extends {{javax.cache.management.CacheStatisticsMXBean}}) when cache starts.

> Cache manager should switch cache statisticsEnabled property globaly
> 
>
> Key: IGNITE-369
> URL: https://issues.apache.org/jira/browse/IGNITE-369
> Project: Ignite
>  Issue Type: Task
>Affects Versions: sprint-2
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>
> Also you should take care about new nodes that joining grid.
> New node could have statisticsEnabled with opposite value that nodes in grid.



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

[jira] [Commented] (IGNITE-369) Cache manager should switch cache statisticsEnabled property globaly

2017-12-07 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov commented on IGNITE-369:
--

[~avinograd], 
Current implementation register 
{{javax.cache.management.CacheStatisticsMXBean}} (which are located at 
{{javax.cache}} -> {{CacheStatistics}} -> {{_ignite config_}} -> {{_cache 
name_}}) when {{enableStatistics}} method is invoked.
Ignite also register {{org.apache.ignite.mxbean.CacheMetricsMXBean}} (which 
extends {{javax.cache.management.CacheStatisticsMXBean}}) when cache starts.

> Cache manager should switch cache statisticsEnabled property globaly
> 
>
> Key: IGNITE-369
> URL: https://issues.apache.org/jira/browse/IGNITE-369
> Project: Ignite
>  Issue Type: Task
>Affects Versions: sprint-2
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>
> Also you should take care about new nodes that joining grid.
> New node could have statisticsEnabled with opposite value that nodes in grid.



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

[jira] [Commented] (IGNITE-7055) Text query for a particular field not working

2017-12-07 Thread Roman Shtykh (JIRA)


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

Roman Shtykh commented on IGNITE-7055:
--

[~vkulichenko] I believe it can be done, but do we really need to do it? ;) All 
SQL indexes are upper-cased. Shall we treat text indexes differently?

> Text query for a particular field not working
> -
>
> Key: IGNITE-7055
> URL: https://issues.apache.org/jira/browse/IGNITE-7055
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Roman Shtykh
>
> Lucene queries allow to specify a specific field name to search in [1], 
> however this doesn't seem to work in latest versions of Ignite.
> To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
> expression:
> {code}
> QueryCursor> masters =
> cache.query(new TextQuery(Person.class, "resume:Master"));
> {code}
> This query returns empty result.
> [1] 
> http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



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

[jira] [Comment Edited] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted

2017-12-07 Thread Andrey Gura (JIRA)


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

Andrey Gura edited comment on IGNITE-6339 at 12/8/17 12:21 AM:
---

As solution the following are implemented:

- Ring buffer (see {{SegmentedRingByteBuffer}}) that reserve segment (buffer 
slice) for thread that want write WAL records. Thread serializes WAL records to 
the segment and calculate CRC if enabled. As result all threads serialize 
record in parallel manner to the ring buffer.
- Dedicated single thread that handles fsync requests and flushes data from the 
ring buffer to the file channel. This thread can't be interrupted via public 
API in distinction of current implementation. Threads that initiate fsync will 
be parked until data will be flushed to disk. 

This solution solves problem with interrupts and improve WAL write performance 
for most cases in {{LOG_ONLY}} WAL mode. But this change leads to performance 
drop for cases when 
local thread writes data to the local node. It is valid for cases with 1-4 
threads. For larger amount of thread we have better performance.

In order to improve performance for case mentioned above we tried mapped file. 
This solution works very well and has better performance for any amount of 
threads. But {{MappedByteBuffer}} don't have method for partial fsync of data 
and for naive fsync ({{#force}} method) has performance drop for {{DEFAULT}} 
WAL mode.

So we have three implementations: master, single writer and mmap. 

See rough benchmarks results below (throughput of cache.put, ops/sec):

*BACKGROUND WAL mode*

| Threads | master | single writer | mmap |
| 1 | 70-80 K | 64-65 K | 70-80 K |
| 2 | 127-128 K | 100-110 K | 127-128 K |
| 4 | 190-200 K | 170-180 K | 190-200 K |
| 8 | 220-230K | 220-230 K | 220-230 K |

For {{BACKGROUND}} mode throughput values are comparable for all 
implementations.

*LOG_ONLY WAL mode*

| Threads | master | single writer | mmap |
| 1 | 60-65 K | 36-37 K | 70-80 K |
| 2 | 100-105 K | 60-70 K | 124-125 K |
| 4 | 130-140 K | 100-110 K | 190-200 K |
| 8 | 50-60 K | 150-160 K | 210-220 K |

For {{LOG_ONLY}} mode single writer performs better than master for larger 
amount of threads. But mmap is the best.

*DEFAULT WAL mode*

| Threads | master | single writer | mmap |
| 1 | 1 K | 1 K | 1 K |
| 2 | 1-2 K | 1-2 K | 1 K |
| 4 | 3-4 K | 3-4 K | 1 K |
| 8 | 5-6 K | 5-6 K | 1 K |

For {{DEFAULT}} mode we have performance drop with mmap. But it seems that 
partial fsync should solve it. Any way changes related with this issue allow 
switch between mmap and signle writer solution using system property.

*Note*: single writer and mmap still use {{fileIO.close()}} call that is 
interruptible. So {{ClosedByInterruption}} exception still has a chance to be 
thrown. This problem is still in TODO's that should be fixed.


was (Author: agura):
As solution the following are implemented:

- Ring buffer (see {{SegmentedRingByteBuffer}}) that reserve segment (buffer 
slice) for thread that want write WAL records. Thread serializes WAL records to 
the segment and calculate CRC if enabled. As result all threads serialize 
record in parallel manner to the ring buffer.
- Dedicated single thread that handles fsync requests and flushes data from the 
ring buffer to the file channel. This thread can't be interrupted via public 
API in distinction of current implementation. Threads that initiate fsync will 
be parked until data will be flushed to disk. 

This solution solves problem with interrupts and improve WAL write performance 
for most cases in {{LOG_ONLY}} WAL mode. But this change leads to performance 
drop for cases when 
local thread writes data to the local node. It is valid for cases with 1-4 
threads. For larger amount of thread we have better performance.

In order to improve performance for case mentioned above we tried mapped file. 
This solution works very well and has better performance for any amount of 
threads. But {{MappedByteBuffer}} don't have method for partial fsync of data 
and for naive fsync ({{#force}} method) has performance drop for {{DEFAULT}} 
WAL mode.

So we have three implementations: master, single writer and mmap. 

See rough benchmarks results below (throughput ops/sec):

*BACKGROUND WAL mode*

| Threads | master | single writer | mmap |
| 1 | 70-80 K | 64-65 K | 70-80 K |
| 2 | 127-128 K | 100-110 K | 127-128 K |
| 4 | 190-200 K | 170-180 K | 190-200 K |
| 8 | 220-230K | 220-230 K | 220-230 K |

For {{BACKGROUND}} mode throughput values are comparable for all 
implementations.

*LOG_ONLY WAL mode*

| Threads | master | single writer | mmap |
| 1 | 60-65 K | 36-37 K | 70-80 K |
| 2 | 100-105 K | 60-70 K | 124-125 K |
| 4 | 130-140 K | 100-110 K | 190-200 K |
| 8 | 50-60 K | 150-160 K | 210-220 K |

For {{LOG_ONLY}} mode single writer performs better than master for larger 
amount of threads. But mmap

[jira] [Commented] (IGNITE-7055) Text query for a particular field not working

2017-12-07 Thread Valentin Kulichenko (JIRA)


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

Valentin Kulichenko commented on IGNITE-7055:
-

[~roman_s], is there a way to make them case sensitive in Ignite as well, so 
that we're consistent with Lucene?

> Text query for a particular field not working
> -
>
> Key: IGNITE-7055
> URL: https://issues.apache.org/jira/browse/IGNITE-7055
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Roman Shtykh
>
> Lucene queries allow to specify a specific field name to search in [1], 
> however this doesn't seem to work in latest versions of Ignite.
> To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
> expression:
> {code}
> QueryCursor> masters =
> cache.query(new TextQuery(Person.class, "resume:Master"));
> {code}
> This query returns empty result.
> [1] 
> http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



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

[jira] [Updated] (IGNITE-7143) CPP: Can not insert zero decimal value with the ODBC driver.

2017-12-07 Thread Dmitriy Setrakyan (JIRA)


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

Dmitriy Setrakyan updated IGNITE-7143:
--
Priority: Blocker  (was: Major)

> CPP: Can not insert zero decimal value with the ODBC driver.
> 
>
> Key: IGNITE-7143
> URL: https://issues.apache.org/jira/browse/IGNITE-7143
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Blocker
> Fix For: 2.4
>
>
> Create the following table:
> {code}
> CREATE TABLE IF NOT EXISTS TestTable (RecId varchar PRIMARY KEY, RecValue 
> DECIMAL(4,2))
> WITH "template=replicated, cache_name=TestTable_Cache";
> {code}
> Then do an ODBC insert using the OdbcParameter with the OdbcCommand object:
> {code}
> INSERT INTO TestTable (RecId, RecValue) VALUES ('1', ?)
> {code}
> The Odbc error is "The connection has been disabled." however the JVM is
> throwing this error:
> {noformat}
> [SEVERE][client-connector-#47][ClientListenerNioListener] Failed to parse
> client request.
> java.lang.ArrayIndexOutOfBoundsException: 0
>  at org.apache.ignite.internal.binary.BinaryUtils.doReadDecimal
> {noformat}
> Everything works out ok until the actual value set on the parameter is 0.
> Null works fine, values other than 0 work fine. Precision and
> Scale are set appropriately. 



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

[jira] [Updated] (IGNITE-7143) CPP: Can not insert zero decimal value with the ODBC driver.

2017-12-07 Thread Dmitriy Setrakyan (JIRA)


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

Dmitriy Setrakyan updated IGNITE-7143:
--
Fix Version/s: 2.4

> CPP: Can not insert zero decimal value with the ODBC driver.
> 
>
> Key: IGNITE-7143
> URL: https://issues.apache.org/jira/browse/IGNITE-7143
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Create the following table:
> {code}
> CREATE TABLE IF NOT EXISTS TestTable (RecId varchar PRIMARY KEY, RecValue 
> DECIMAL(4,2))
> WITH "template=replicated, cache_name=TestTable_Cache";
> {code}
> Then do an ODBC insert using the OdbcParameter with the OdbcCommand object:
> {code}
> INSERT INTO TestTable (RecId, RecValue) VALUES ('1', ?)
> {code}
> The Odbc error is "The connection has been disabled." however the JVM is
> throwing this error:
> {noformat}
> [SEVERE][client-connector-#47][ClientListenerNioListener] Failed to parse
> client request.
> java.lang.ArrayIndexOutOfBoundsException: 0
>  at org.apache.ignite.internal.binary.BinaryUtils.doReadDecimal
> {noformat}
> Everything works out ok until the actual value set on the parameter is 0.
> Null works fine, values other than 0 work fine. Precision and
> Scale are set appropriately. 



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

[jira] [Assigned] (IGNITE-7143) CPP: Can not insert zero decimal value with the ODBC driver.

2017-12-07 Thread Dmitriy Setrakyan (JIRA)


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

Dmitriy Setrakyan reassigned IGNITE-7143:
-

Assignee: Igor Sapego

> CPP: Can not insert zero decimal value with the ODBC driver.
> 
>
> Key: IGNITE-7143
> URL: https://issues.apache.org/jira/browse/IGNITE-7143
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Create the following table:
> {code}
> CREATE TABLE IF NOT EXISTS TestTable (RecId varchar PRIMARY KEY, RecValue 
> DECIMAL(4,2))
> WITH "template=replicated, cache_name=TestTable_Cache";
> {code}
> Then do an ODBC insert using the OdbcParameter with the OdbcCommand object:
> {code}
> INSERT INTO TestTable (RecId, RecValue) VALUES ('1', ?)
> {code}
> The Odbc error is "The connection has been disabled." however the JVM is
> throwing this error:
> {noformat}
> [SEVERE][client-connector-#47][ClientListenerNioListener] Failed to parse
> client request.
> java.lang.ArrayIndexOutOfBoundsException: 0
>  at org.apache.ignite.internal.binary.BinaryUtils.doReadDecimal
> {noformat}
> Everything works out ok until the actual value set on the parameter is 0.
> Null works fine, values other than 0 work fine. Precision and
> Scale are set appropriately. 



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

[jira] [Comment Edited] (IGNITE-369) Cache manager should switch cache statisticsEnabled property globaly

2017-12-07 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov edited comment on IGNITE-369 at 12/7/17 9:25 PM:
---

[~avinogradov], 
Current implementation register 
{{javax.cache.management.CacheStatisticsMXBean}} (which are located at 
{{javax.cache}} -> {{CacheStatistics}} -> {{_ignite config_}} -> {{_cache 
name_}}) when {{enableStatistics}} method is invoked.
Ignite also register {{org.apache.ignite.mxbean.CacheMetricsMXBean}} (which 
extends {{javax.cache.management.CacheStatisticsMXBean}}) when cache starts.


was (Author: alex_pl):
[~avinogradov]], 
Current implementation register 
{{javax.cache.management.CacheStatisticsMXBean}} (which are located at 
{{javax.cache}} -> {{CacheStatistics}} -> {{_ignite config_}} -> {{_cache 
name_}}) when {{enableStatistics}} method is invoked.
Ignite also register {{org.apache.ignite.mxbean.CacheMetricsMXBean}} (which 
extends {{javax.cache.management.CacheStatisticsMXBean}}) when cache starts.

> Cache manager should switch cache statisticsEnabled property globaly
> 
>
> Key: IGNITE-369
> URL: https://issues.apache.org/jira/browse/IGNITE-369
> Project: Ignite
>  Issue Type: Task
>Affects Versions: sprint-2
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>
> Also you should take care about new nodes that joining grid.
> New node could have statisticsEnabled with opposite value that nodes in grid.



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

[jira] [Commented] (IGNITE-6867) Implement new JMX metrics for topology monitoring

2017-12-07 Thread Max Shonichev (JIRA)


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

Max Shonichev commented on IGNITE-6867:
---

How come this merged to 2.4.1-p2?

> Implement new JMX metrics for topology monitoring
> -
>
> Key: IGNITE-6867
> URL: https://issues.apache.org/jira/browse/IGNITE-6867
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> * Current topology version
> * Total server nodes count
> * Total client nodes count
> * Method to count nodes filtered by some node attribute
> * Method to count nodes grouped by some node attribute
>  
> There is already a ticket to implement first 2 metrics from this list 
> (IGNITE-6844)



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

[jira] [Commented] (IGNITE-6373) Create example for local and distributed k-means algorithm

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6373:


Github user asfgit closed the pull request at:

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


> Create example for local and distributed k-means algorithm
> --
>
> Key: IGNITE-6373
> URL: https://issues.apache.org/jira/browse/IGNITE-6373
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Oleg Ignatenko
>  Labels: examples
> Fix For: 2.4
>
>
> Currently we no examples for both versions of k-means. So we need at least 
> two example for local k-means and for distributed k-means.



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

[jira] [Commented] (IGNITE-369) Cache manager should switch cache statisticsEnabled property globaly

2017-12-07 Thread Anton Vinogradov (JIRA)


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

Anton Vinogradov commented on IGNITE-369:
-

[~alex_pl] ,

I see no reason to have local method.
Seems, we should replace current implementation with global.

Please provide additional info about mxbean will be registered in that case.

> Cache manager should switch cache statisticsEnabled property globaly
> 
>
> Key: IGNITE-369
> URL: https://issues.apache.org/jira/browse/IGNITE-369
> Project: Ignite
>  Issue Type: Task
>Affects Versions: sprint-2
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>
> Also you should take care about new nodes that joining grid.
> New node could have statisticsEnabled with opposite value that nodes in grid.



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

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

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7113:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-7113 Processing of redundant type names



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

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

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

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


commit 071d55881db33cadcda40b568978bca3a151d8b3
Author: Alexander Paschenko 
Date:   2017-12-07T17:11:11Z

IGNITE-7113 Processing of redundant type names




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

[jira] [Commented] (IGNITE-7110) Javadoc package descriptions missed for ML

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7110:


Github user asfgit closed the pull request at:

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


> Javadoc package descriptions missed for ML
> --
>
> Key: IGNITE-7110
> URL: https://issues.apache.org/jira/browse/IGNITE-7110
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.3
>Reporter: Sergey Kozlov
>Assignee: Yury Babak
>Priority: Minor
> Fix For: 2.4
>
>
> The following packages have no description:
> org.apache.ignite.development.utils
> org.apache.ignite.ml.trees.trainers.columnbased.caches
> org.apache.ignite.ml.util



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

[jira] [Commented] (IGNITE-7110) Javadoc package descriptions missed for ML

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7110:


GitHub user ybabak opened a pull request:

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

IGNITE-7110: Javadoc package descriptions missed for ML

fixed.

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

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

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

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


commit 3e48a703208b99451f0191746cc20f9ec7809d13
Author: YuriBabak 
Date:   2017-12-07T16:27:39Z

IGNITE-7110: Javadoc package descriptions missed for ML

fixed.




> Javadoc package descriptions missed for ML
> --
>
> Key: IGNITE-7110
> URL: https://issues.apache.org/jira/browse/IGNITE-7110
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.3
>Reporter: Sergey Kozlov
>Assignee: Yury Babak
>Priority: Minor
> Fix For: 2.4
>
>
> The following packages have no description:
> org.apache.ignite.development.utils
> org.apache.ignite.ml.trees.trainers.columnbased.caches
> org.apache.ignite.ml.util



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

[jira] [Commented] (IGNITE-7008) TcpDiscoverySharedFsIpFinder fails with NPE if address can't be resolved.

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7008:


Github user asfgit closed the pull request at:

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


> TcpDiscoverySharedFsIpFinder fails with NPE if address can't be resolved.
> -
>
> Key: IGNITE-7008
> URL: https://issues.apache.org/jira/browse/IGNITE-7008
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>
> Seems, we should add a check to registerAddresses() method if address has 
> been resolved and use hostname otherwise.
> 2017-11-23 14:25:19,487 ERROR [tcp-disco-msg-worker-#2%null%] 
> [Slf4jLogger.java:119] Runtime error caught during grid runnable execution: 
> IgniteSpiThread [name=tcp-disco-msg-worker-#2%null%]
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.sharedfs.TcpDiscoverySharedFsIpFinder.name(TcpDiscoverySharedFsIpFinder.java:277)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.sharedfs.TcpDiscoverySharedFsIpFinder.distinctNames(TcpDiscoverySharedFsIpFinder.java:260)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.sharedfs.TcpDiscoverySharedFsIpFinder.registerAddresses(TcpDiscoverySharedFsIpFinder.java:220)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4442)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4052)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2623)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2437)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6568)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2523)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}



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

[jira] [Assigned] (IGNITE-7110) Javadoc package descriptions missed for ML

2017-12-07 Thread Yury Babak (JIRA)


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

Yury Babak reassigned IGNITE-7110:
--

Assignee: Yury Babak

> Javadoc package descriptions missed for ML
> --
>
> Key: IGNITE-7110
> URL: https://issues.apache.org/jira/browse/IGNITE-7110
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.3
>Reporter: Sergey Kozlov
>Assignee: Yury Babak
>Priority: Minor
> Fix For: 2.4
>
>
> The following packages have no description:
> org.apache.ignite.development.utils
> org.apache.ignite.ml.trees.trainers.columnbased.caches
> org.apache.ignite.ml.util



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

[jira] [Commented] (IGNITE-369) Cache manager should switch cache statisticsEnabled property globaly

2017-12-07 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov commented on IGNITE-369:
--

Where in the public API is the best place for a methods to enable/disable 
statistics?

At the moment, there is a method 
{{org.apache.ignite.cache.CacheManager#enableStatistics}}, that 
enables/disables statistics locally, but it also register or unregister new 
MXBean (for JSR-107 compatibility, as I understand it). I can change this 
method to enable/disable statistics globally, but for each cache additional 
MXBeans will be registered when this method will be used to enable statistics.
Also I can implement a new method in {{CacheManager}} (something like 
{{enableStatisticsGlobally}}), but, perhaps, API will become inconsistent 
(public methods which are not declared in {{javax.cache.CacheManager}}).
Another proposal was to implement new methods in {{IgniteCluster}}, but for now 
it contains mostly methods for topology management.

Which way to choose? Are there any other proposals?

> Cache manager should switch cache statisticsEnabled property globaly
> 
>
> Key: IGNITE-369
> URL: https://issues.apache.org/jira/browse/IGNITE-369
> Project: Ignite
>  Issue Type: Task
>Affects Versions: sprint-2
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>
> Also you should take care about new nodes that joining grid.
> New node could have statisticsEnabled with opposite value that nodes in grid.



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

[jira] [Comment Edited] (IGNITE-6373) Create example for local and distributed k-means algorithm

2017-12-07 Thread Oleg Ignatenko (JIRA)


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

Oleg Ignatenko edited comment on IGNITE-6373 at 12/7/17 4:11 PM:
-

Drafted examples in branch _ignite-6373_. Plan to wait for a bit for maybe some 
changes made to examples in the course of IGNITE-6872 will merge to master and 
if this happens soon enough will accommodate.

*Update* accommodated final implementation is in branch  
[ignite-6373-1|https://github.com/gridgain/apache-ignite/tree/ignite-6373-1]


was (Author: oignatenko):
drafted examples in branch 
[ignite-6373|https://github.com/gridgain/apache-ignite/tree/ignite-6373]. Plan 
to wait for a bit for maybe some changes made to examples in the course of 
IGNITE-6872 will merge to master and if this happens soon enough will 
accommodate

> Create example for local and distributed k-means algorithm
> --
>
> Key: IGNITE-6373
> URL: https://issues.apache.org/jira/browse/IGNITE-6373
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Oleg Ignatenko
>  Labels: examples
>
> Currently we no examples for both versions of k-means. So we need at least 
> two example for local k-means and for distributed k-means.



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

[jira] [Commented] (IGNITE-6373) Create example for local and distributed k-means algorithm

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6373:


GitHub user oignatenko opened a pull request:

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

IGNITE-6373 Create example for local and distributed k-means algorithm

- examples implemented
-- verified with diffs overview, clean build and execution of examples

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

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

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

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


commit b0cc9d74dfd664f3be11cadb0a43369819b3e8b5
Author: Oleg Ignatenko 
Date:   2017-12-07T15:56:14Z

IGNITE-6373 Create example for local and distributed k-means algorithm
- examples implemented
-- verified with diffs overview, clean build and execution of examples




> Create example for local and distributed k-means algorithm
> --
>
> Key: IGNITE-6373
> URL: https://issues.apache.org/jira/browse/IGNITE-6373
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Oleg Ignatenko
>  Labels: examples
>
> Currently we no examples for both versions of k-means. So we need at least 
> two example for local k-means and for distributed k-means.



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

2017-12-07 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-7109:


Hybrid approach implemented: 
# Send requests in blocking mode ({{Socket.Send}})
# Use a dedicated thread to read responses in blocking mode 
({{Socket.Receive}}) and complete async operations with {{TaskCompletionSource}}
# Synchronous calls ({{cache.Put}}): If there are no pending socket operations 
- read response in blocking mode right from current thread. Otherwise fall back 
to async mechanism with background thread.


> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Commented] (IGNITE-7144) Java 9: fix build issue with tools.jar not found

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7144:


GitHub user vveider opened a pull request:

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

IGNITE-7144 Java 9: fix build issue with tools.jar not found

 * added profiles to parent and ignite-tools modules to detect java-9 
environment and run parametrised build
 * added macOS compatibility for previouse java versions

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

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

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

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


commit fedf126db357ba04cda08cdec2c709101140ff4c
Author: Ivanov Petr 
Date:   2017-12-07T15:07:59Z

IGNITE-7144 Java 9: fix build issue with tools.jar not found
 * added profiles to parent and ignite-tools modules to detect java-9 
environment and run parametrised build
 * added macOS compatibility for previouse java versions




> Java 9: fix build issue with tools.jar not found
> 
>
> Key: IGNITE-7144
> URL: https://issues.apache.org/jira/browse/IGNITE-7144
> Project: Ignite
>  Issue Type: Bug
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>
> {code}
> [ERROR] Failed to execute goal on project ignite-tools: Could not resolve 
> dependencies for project org.apache.ignite:ignite-tools:jar:2.4.0-SNAPSHOT: 
> Could not find artifact com.sun:tools:jar:9.0.1 at specified path 
> /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/../lib/tools.jar
> {code}



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

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

2017-12-07 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov reassigned IGNITE-5874:


Assignee: Andrew Mashenkov

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



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

[jira] [Updated] (IGNITE-7144) Java 9: fix build issue with tools.jar not found

2017-12-07 Thread Peter Ivanov (JIRA)


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

Peter Ivanov updated IGNITE-7144:
-
Issue Type: Bug  (was: Improvement)

> Java 9: fix build issue with tools.jar not found
> 
>
> Key: IGNITE-7144
> URL: https://issues.apache.org/jira/browse/IGNITE-7144
> Project: Ignite
>  Issue Type: Bug
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>
> {code}
> [ERROR] Failed to execute goal on project ignite-tools: Could not resolve 
> dependencies for project org.apache.ignite:ignite-tools:jar:2.4.0-SNAPSHOT: 
> Could not find artifact com.sun:tools:jar:9.0.1 at specified path 
> /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/../lib/tools.jar
> {code}



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

[jira] [Comment Edited] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn edited comment on IGNITE-7114 at 12/7/17 3:04 PM:
-

[~isapego] logic looks good to me, but there is a lot of code duplication.
I think Windows and Linux differ only in path separators and jvm library names, 
so all the logic can be shared.


was (Author: ptupitsyn):
[~isapego] logic looks good to me, but there is a lot of code duplication.
I thin Windows and Linux logic differs only in path separators and jvm library 
names, so all the logic can be shared.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-7114:


[~isapego] logic looks good to me, but there is a lot of code duplication.
I thin Windows and Linux logic differs only in path separators and jvm library 
names, so all the logic can be shared.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Created] (IGNITE-7143) CPP: Can not insert zero decimal value with the ODBC driver.

2017-12-07 Thread Igor Sapego (JIRA)

Igor Sapego created IGNITE-7143:
---

 Summary: CPP: Can not insert zero decimal value with the ODBC 
driver.
 Key: IGNITE-7143
 URL: https://issues.apache.org/jira/browse/IGNITE-7143
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.1
Reporter: Igor Sapego


Create the following table:
{code}
CREATE TABLE IF NOT EXISTS TestTable (RecId varchar PRIMARY KEY, RecValue 
DECIMAL(4,2))
WITH "template=replicated, cache_name=TestTable_Cache";
{code}

Then do an ODBC insert using the OdbcParameter with the OdbcCommand object:

{code}
INSERT INTO TestTable (RecId, RecValue) VALUES ('1', ?)
{code}

The Odbc error is "The connection has been disabled." however the JVM is
throwing this error:

{noformat}
[SEVERE][client-connector-#47][ClientListenerNioListener] Failed to parse
client request.
java.lang.ArrayIndexOutOfBoundsException: 0
 at org.apache.ignite.internal.binary.BinaryUtils.doReadDecimal
{noformat}

Everything works out ok until the actual value set on the parameter is 0.
Null works fine, values other than 0 work fine. Precision and
Scale are set appropriately. 



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

[jira] [Resolved] (IGNITE-7142) Introduce ability to run Ignite Tests on TeamCity with Java 9

2017-12-07 Thread Peter Ivanov (JIRA)


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

Peter Ivanov resolved IGNITE-7142.
--
Resolution: Done

Ability added to build plan [Ignite Tests / -> Run 
All|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests_RunAll] 
via parametrised run:
*Run Custom Build (...)* --> *Parameters* --> *Choose JAVA*

One can select from _java-1.7_, _java-1.8_ and _java-9_ environments to 
initiate build of all dependency builds with chosen java version.

(!) NOTE: java-9 run is currently fails because of code unreadiness for 
compilation with java-9, which is going to be fixed in IGNITE-6728 tickets.

> Introduce ability to run Ignite Tests on TeamCity with Java 9
> -
>
> Key: IGNITE-7142
> URL: https://issues.apache.org/jira/browse/IGNITE-7142
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>
> Introduce ability to run Ignite Tests on TeamCity with Java 9 (and Java 1.8 
> as well).



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Igor Sapego (JIRA)


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

Igor Sapego commented on IGNITE-7114:
-

[~ptupitsyn], can you take a look on a new version?

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Created] (IGNITE-7142) Introduce ability to run Ignite Tests on TeamCity with Java 9

2017-12-07 Thread Peter Ivanov (JIRA)

Peter Ivanov created IGNITE-7142:


 Summary: Introduce ability to run Ignite Tests on TeamCity with 
Java 9
 Key: IGNITE-7142
 URL: https://issues.apache.org/jira/browse/IGNITE-7142
 Project: Ignite
  Issue Type: New Feature
Reporter: Peter Ivanov
Assignee: Peter Ivanov


Introduce ability to run Ignite Tests on TeamCity with Java 9 (and Java 1.8 as 
well).



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

[jira] [Comment Edited] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Igor Sapego (JIRA)


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

Igor Sapego edited comment on IGNITE-7114 at 12/7/17 2:13 PM:
--

[~apopov], I've seen the attached file. So should it be detected or should not?
By the way, these checks only used when user did not provide us {{IGNITE_HOME}} 
and we are trying to find it by ourselves. If user provides us {{IGNITE_HOME}} 
that points to any existent directory, no additional checks performed now, so 
user can rename libs however they want, if only they point out {{IGNITE_HOME}} 
for us.


was (Author: isapego):
[~apopov], I've seen the attached file. So should it be detected or should not?
By the way, these checks only used when user did not provide us {{IGNITE_HOME}} 
and we are trying to find it by ourselves. If user provides us {{IGNITE_HOME}} 
that points to any existent directory, no additional checks performed now, so 
user can rename libs however they want now, if only he point out 
{{IGNITE_HOME}} for us.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Igor Sapego (JIRA)


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

Igor Sapego commented on IGNITE-7114:
-

[~apopov], I've seen the attached file. So should it be detected or should not?
By the way, these checks only used when user did not provide us {{IGNITE_HOME}} 
and we are trying to find it by ourselves. If user provides us {{IGNITE_HOME}} 
that points to any existent directory, no additional checks performed now, so 
user can rename libs however they want now, if only he point out 
{{IGNITE_HOME}} for us.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Assigned] (IGNITE-7132) Investigate and document Ignite Persistence usage in Docker

2017-12-07 Thread Denis Magda (JIRA)


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

Denis Magda reassigned IGNITE-7132:
---

Assignee: Nikolay Tikhonov

> Investigate and document Ignite Persistence usage in Docker
> ---
>
> Key: IGNITE-7132
> URL: https://issues.apache.org/jira/browse/IGNITE-7132
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
> Fix For: 2.4
>
>
> Inspired by the following talk:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-in-docker-Native-Persistence-td18426.html
> The aim is to investigate how is better to deploy Ignite persistence in 
> Docker. Probably with the usage of Docker volumes:
> https://docs.docker.com/engine/admin/volumes/volumes/#use-a-read-only-volume 
> Once the configuration option is clear the following documentation needs to 
> be updated:
> https://apacheignite.readme.io/docs/docker-deployment 



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Alexey Popov (JIRA)


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

Alexey Popov commented on IGNITE-7114:
--

[~isapego], please see the attached .png. It has {{/libs/ignite-core.jar}} 
file. 
{{/libs/ignite-core*.jar}} is ok

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Created] (IGNITE-7141) JDBC Driver 2.3.0 Incorrectly reads PK column meta data

2017-12-07 Thread Josh (JIRA)

Josh created IGNITE-7141:


 Summary: JDBC Driver 2.3.0 Incorrectly reads PK column meta data
 Key: IGNITE-7141
 URL: https://issues.apache.org/jira/browse/IGNITE-7141
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.3
Reporter: Josh


It appears the meta data coming back while trying to read PK information about 
a table through the jdbc driver has two properties flipped (PK_NAME and 
COLUMN_NAME). 

I have a table with a PK column named ID and while querying the meta data 
through the driver I receive the following entries:

PK_NAME=ID
COLUMN_NAME=_KEY

I verified the same shows through a jdbc tool like Squirrel sql.





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

[jira] [Comment Edited] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Igor Sapego (JIRA)


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

Igor Sapego edited comment on IGNITE-7114 at 12/7/17 1:50 PM:
--

[~apopov], what do you mean by "check the absence of "-x.y.z" part with some 
error indication"?
Currently, I simply check for existence of the {{/libs/ignite-core*.jar}} file. 
Is it OK for your case?


was (Author: isapego):
[~apopov], what do you mean by "check the absence of "-x.y.z" part with some 
error indication"?
Currently, I simply check for existence of the {{/libs/ignite-core*.jar}} file. 
Is it Ok for your case?

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Igor Sapego (JIRA)


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

Igor Sapego commented on IGNITE-7114:
-

[~apopov], what do you mean by "check the absence of "-x.y.z" part with some 
error indication"?
Currently, I simply check for existence of the {{/libs/ignite-core*.jar}} file. 
Is it Ok for your case?

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Assigned] (IGNITE-369) Cache manager should switch cache statisticsEnabled property globaly

2017-12-07 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov reassigned IGNITE-369:


Assignee: Aleksey Plekhanov

> Cache manager should switch cache statisticsEnabled property globaly
> 
>
> Key: IGNITE-369
> URL: https://issues.apache.org/jira/browse/IGNITE-369
> Project: Ignite
>  Issue Type: Task
>Affects Versions: sprint-2
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>
> Also you should take care about new nodes that joining grid.
> New node could have statisticsEnabled with opposite value that nodes in grid.



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

[jira] [Created] (IGNITE-7140) Error in cardinality checks in AbstractMatrix in methods plus and minus

2017-12-07 Thread Artem Malykh (JIRA)

Artem Malykh created IGNITE-7140:


 Summary: Error in cardinality checks in AbstractMatrix in methods 
plus and minus
 Key: IGNITE-7140
 URL: https://issues.apache.org/jira/browse/IGNITE-7140
 Project: Ignite
  Issue Type: Bug
Reporter: Artem Malykh
Assignee: Artem Malykh


Cardinality checks in mentioned methods compare matrix dimensions with its own 
dimensions instead of operands dimensions.



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

[jira] [Comment Edited] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

2017-12-07 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov edited comment on IGNITE-7044 at 12/7/17 12:55 PM:
---

[~dmagda], [~rkondakov], these operations have nothing in common. Query 
parallelism splits indexes into multiple pieces. We will deprecate it in future 
in favor of intellectual parallel execution based on statistics. {{CREATE 
INDEX}} parallelism defines how many threads will fill index with data during 
creation. 


was (Author: vozerov):
[~dmagda], [~rkondakov], these operations have nothing in common.

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



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

[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

2017-12-07 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-7044:
-

[~dmagda], [~rkondakov], these operations have nothing in common.

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



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

[jira] [Comment Edited] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted

2017-12-07 Thread Andrey Gura (JIRA)


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

Andrey Gura edited comment on IGNITE-6339 at 12/7/17 12:52 PM:
---

As solution the following are implemented:

- Ring buffer (see {{SegmentedRingByteBuffer}}) that reserve segment (buffer 
slice) for thread that want write WAL records. Thread serializes WAL records to 
the segment and calculate CRC if enabled. As result all threads serialize 
record in parallel manner to the ring buffer.
- Dedicated single thread that handles fsync requests and flushes data from the 
ring buffer to the file channel. This thread can't be interrupted via public 
API in distinction of current implementation. Threads that initiate fsync will 
be parked until data will be flushed to disk. 

This solution solves problem with interrupts and improve WAL write performance 
for most cases in {{LOG_ONLY}} WAL mode. But this change leads to performance 
drop for cases when 
local thread writes data to the local node. It is valid for cases with 1-4 
threads. For larger amount of thread we have better performance.

In order to improve performance for case mentioned above we tried mapped file. 
This solution works very well and has better performance for any amount of 
threads. But {{MappedByteBuffer}} don't have method for partial fsync of data 
and for naive fsync ({{#force}} method) has performance drop for {{DEFAULT}} 
WAL mode.

So we have three implementations: master, single writer and mmap. 

See rough benchmarks results below (throughput ops/sec):

*BACKGROUND WAL mode*

| Threads | master | single writer | mmap |
| 1 | 70-80 K | 64-65 K | 70-80 K |
| 2 | 127-128 K | 100-110 K | 127-128 K |
| 4 | 190-200 K | 170-180 K | 190-200 K |
| 8 | 220-230K | 220-230 K | 220-230 K |

For {{BACKGROUND}} mode throughput values are comparable for all 
implementations.

*LOG_ONLY WAL mode*

| Threads | master | single writer | mmap |
| 1 | 60-65 K | 36-37 K | 70-80 K |
| 2 | 100-105 K | 60-70 K | 124-125 K |
| 4 | 130-140 K | 100-110 K | 190-200 K |
| 8 | 50-60 K | 150-160 K | 210-220 K |

For {{LOG_ONLY}} mode single writer performs better than master for larger 
amount of threads. But mmap is the best.

*DEFAULT WAL mode*

| Threads | master | single writer | mmap |
| 1 | 1 K | 1 K | 1 K |
| 2 | 1-2 K | 1-2 K | 1 K |
| 4 | 3-4 K | 3-4 K | 1 K |
| 8 | 5-6 K | 5-6 K | 1 K |

For {{DEFAULT}} mode we have performance drop with mmap. But it seems that 
partial fsync should solve it. Any way changes related with this issue allow 
switch between mmap and signle writer solution using system property.

*Note*: single writer and mmap still use {{fileIO.close()}} call that is 
interruptible. So {{ClosedByInterruption}} exception still has a chance to be 
thrown. This problem is still in TODO's that should be fixed.


was (Author: agura):
As solution the following are implemented:

- Ring buffer (see {{SegmentedRingByteBuffer}}) that reserve segment (buffer 
slice) for thread that want write WAL records. Thread serializes WAL records to 
the segment and calculate CRC if enabled. As result all threads serialize 
record in parallel manner to the ring buffer.
- Dedicated single thread that handles fsync requests and flushes data from the 
ring buffer to the file channel. This thread can't be interrupted via public 
API in distinction of current implementation. Threads that initiate fsync will 
be parked until data will be flushed to disk. 

This solution solves problem with interrupts and improve WAL write performance 
for most cases in {{LOG_ONLY}} WAL mode. But this change leads to performance 
drop for cases when 
local thread writes data to the local node. It is valid for cases with 1-4 
threads. For larger amount of thread we have better performance.

In order to improve performance for case mentioned above we tried mapped file. 
This solution works very well and has better performance for any amount of 
threads. But {{MappedByteBuffer}} don't have method for partial fsync of data 
and for naive fsync ({{#force}} method) has performance drop for {{DEFAULT}} 
WAL mode.

So we have three implementations: master, single writer and mmap. 

See rough benchmarks results below (throughput ops/sec):

*BACKGROUND WAL mode*

| Threads | master | single writer | mmap |
| 1 | 70-80 K | 64-65 K | 70-80 K |
| 2 | 127-128 K | 100-110 K | 127-128 K |
| 4 | 190-200 K | 170-180 K | 190-200 K |
| 8 | 220-230K | 220-230 K | 220-230 K |

For {{BACKGROUND}} mode throughput values are comparable for all 
implementations.

*LOG_ONLY WAL mode*

| Threads | master | single writer | mmap |
| 1 | 60-65 K | 36-37 K | 70-80 K |
| 2 | 100-105 K | 60-70 K | 124-125 K |
| 4 | 130-140 K | 100-110 K | 190-200 K |
| 8 | 50-60 K | 150-160 K | 210-220 K |

For {{LOG_ONLY}} mode single writer performs better than master for larger 
amount of threads. But mmap is the best.

[jira] [Commented] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted

2017-12-07 Thread Andrey Gura (JIRA)


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

Andrey Gura commented on IGNITE-6339:
-

As solution the following are implemented:

- Ring buffer (see {{SegmentedRingByteBuffer}}) that reserve segment (buffer 
slice) for thread that want write WAL records. Thread serializes WAL records to 
the segment and calculate CRC if enabled. As result all threads serialize 
record in parallel manner to the ring buffer.
- Dedicated single thread that handles fsync requests and flushes data from the 
ring buffer to the file channel. This thread can't be interrupted via public 
API in distinction of current implementation. Threads that initiate fsync will 
be parked until data will be flushed to disk. 

This solution solves problem with interrupts and improve WAL write performance 
for most cases in {{LOG_ONLY}} WAL mode. But this change leads to performance 
drop for cases when 
local thread writes data to the local node. It is valid for cases with 1-4 
threads. For larger amount of thread we have better performance.

In order to improve performance for case mentioned above we tried mapped file. 
This solution works very well and has better performance for any amount of 
threads. But {{MappedByteBuffer}} don't have method for partial fsync of data 
and for naive fsync ({{#force}} method) has performance drop for {{DEFAULT}} 
WAL mode.

So we have three implementations: master, single writer and mmap. 

See rough benchmarks results below (throughput ops/sec):

*BACKGROUND WAL mode*

| Threads | master | single writer | mmap |
| 1 | 70-80 K | 64-65 K | 70-80 K |
| 2 | 127-128 K | 100-110 K | 127-128 K |
| 4 | 190-200 K | 170-180 K | 190-200 K |
| 8 | 220-230K | 220-230 K | 220-230 K |

For {{BACKGROUND}} mode throughput values are comparable for all 
implementations.

*LOG_ONLY WAL mode*

| Threads | master | single writer | mmap |
| 1 | 60-65 K | 36-37 K | 70-80 K |
| 2 | 100-105 K | 60-70 K | 124-125 K |
| 4 | 130-140 K | 100-110 K | 190-200 K |
| 8 | 50-60 K | 150-160 K | 210-220 K |

For {{LOG_ONLY}} mode single writer performs better than master for larger 
amount of threads. But mmap is the best.

*DEFAULT WAL mode*

| Threads | master | single writer | mmap |
| 1 | 1 K | 1 K | 1 K |
| 2 | 1-2 K | 1-2 K | 1 K |
| 4 | 3-4 K | 3-4 K | 1 K |
| 8 | 5-6 K | 5-6 K | 1 K |

For {{DEFAULT}} mode we have performance drop with mmap. But it seems that 
partial fsync should solve it. Any way changes related with this issue allow 
switch between mmap and signle writer solution using system property.

*Note*: single writer and mmap still use {{fileIO.close()}} call that is 
interruptible. So "closed by interruption" exception still has a chance to be 
thrown. This problem is still in TODO's that should be fixed.

> WAL: Avoid closed by interruption exception when user thread is interrupted
> ---
>
> Key: IGNITE-6339
> URL: https://issues.apache.org/jira/browse/IGNITE-6339
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Blocker
>  Labels: important
> Fix For: 2.4
>
>
> We should have a separate writer thread for WAL that will write completed 
> serialized chunks of data. This will allow us avoid closed by interruption 
> exception when user thread is interrupted.



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

[jira] [Commented] (IGNITE-7088) Wrong implementation of DIRECT comparator for ordering cache start operations

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7088:


Github user asfgit closed the pull request at:

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


> Wrong implementation of DIRECT comparator for ordering cache start operations
> -
>
> Key: IGNITE-7088
> URL: https://issues.apache.org/jira/browse/IGNITE-7088
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.4
>
>
> {code:java}
> java.lang.IllegalArgumentException: Comparison method violates its general 
> contract!
>   at java.util.TimSort.mergeHi(TimSort.java:899) ~[?:1.8.0_102]
>   at java.util.TimSort.mergeAt(TimSort.java:516) ~[?:1.8.0_102]
>   at java.util.TimSort.mergeForceCollapse(TimSort.java:457) ~[?:1.8.0_102]
>   at java.util.TimSort.sort(TimSort.java:254) ~[?:1.8.0_102]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[?:1.8.0_102]
>   at java.util.ArrayList.sort(ArrayList.java:1454) ~[?:1.8.0_102]
>   at java.util.Collections.sort(Collections.java:175) ~[?:1.8.0_102]
>   at 
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.orderedCaches(ClusterCachesInfo.java:1616)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.cachesReceivedFromJoin(ClusterCachesInfo.java:839)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1709)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:606)
>  [ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
>  [ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-2.1.7.jar:2.1.7]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_102]
> {code}
> When 2 not user caches will be compared using this comparator, this above 
> exception will be thrown.
> As a workaround can be used system variable 
> -Djava.util.Arrays.useLegacyMergeSort=true 



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

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

2017-12-07 Thread Alexander Paschenko (JIRA)


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

Alexander Paschenko reassigned IGNITE-7113:
---

Assignee: Alexander Paschenko

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

[jira] [Commented] (IGNITE-4192) SQL TX: JDBC driver support

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-4192:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-4192



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

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

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

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


commit f6e982540e65ab17d439dba990794f35616a30dd
Author: sboikov 
Date:   2017-08-30T09:45:40Z

ignite-3478

commit 275a85db5cd6923b36126166ae99b15e876192be
Author: sboikov 
Date:   2017-08-31T07:44:07Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2
Author: sboikov 
Date:   2017-08-31T09:00:36Z

disco cache cleanup

commit 855c2d45794c300d41e386b4e6fa40736cc3e40d
Author: sboikov 
Date:   2017-08-31T09:09:58Z

Merge branch 'ignite-3478-1' into ignite-3478

commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31
Author: sboikov 
Date:   2017-08-31T09:52:23Z

ignite-3478

commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90
Author: sboikov 
Date:   2017-09-04T08:13:50Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit d3c049952384750c5543a9f88b383c033ef74096
Author: sboikov 
Date:   2017-09-04T08:52:11Z

ignite-3478

commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab
Author: sboikov 
Date:   2017-09-04T10:16:03Z

ignite-3478

commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c
Author: sboikov 
Date:   2017-09-05T10:16:44Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4
Author: sboikov 
Date:   2017-09-05T11:30:55Z

ignite-3478

commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e
Author: sboikov 
Date:   2017-09-05T11:31:14Z

ignite-3478

commit cbada3934a386668da0b11d4de7d0f58a4d04dfe
Author: sboikov 
Date:   2017-09-05T11:49:49Z

ignite-3484

commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b
Author: sboikov 
Date:   2017-09-05T11:59:49Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit bc9134c94b7a738dc1664e96ca6eabb059f1c268
Author: sboikov 
Date:   2017-09-05T12:03:39Z

Merge branch 'ignite-3478' into ignite-3484

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/tree/AbstractDataInnerIO.java

commit b4bfcde78825c6517232e49d389bdb5de19f05a9
Author: sboikov 
Date:   2017-09-05T12:27:51Z

ignite-3484

commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599
Author: sboikov 
Date:   2017-09-05T13:13:00Z

ignite-3478

commit d1b828095713fcadfa260cf94fef01b42a1b12fd
Author: sboikov 
Date:   2017-09-05T13:13:33Z

Merge branch 'ignite-3478' into ignite-3484

commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5
Author: sboikov 
Date:   2017-09-05T13:47:11Z

ignite-3484

commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5
Author: sboikov 
Date:   2017-09-06T07:10:26Z

ignite-3484

commit dd0afb28466094b801506da8afa3601bfaebd853
Author: sboikov 
Date:   2017-09-06T07:30:04Z

ignite-3484

commit 27b87b413348b03986a463551db24b7726321732
Author: sboikov 
Date:   2017-09-06T08:19:18Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit dcaf8801accd6ee089849a82b2ccd558aec81895
Author: sboikov 
Date:   2017-09-06T08:19:30Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit c966451d0bf7059575de92bcfae43d72096ebce4
Author: sboikov 
Date:   2017-09-06T08:27:04Z

Merge branch 'ignite-3478' into ignite-3484

commit 91b9911731a387a3199ddbbc22704bc14af09995
Author: sboikov

[jira] [Created] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.

2017-12-07 Thread Roman Kondakov (JIRA)

Roman Kondakov created IGNITE-7139:
--

 Summary: SQL: Implement a lazy execution for the local queries.
 Key: IGNITE-7139
 URL: https://issues.apache.org/jira/browse/IGNITE-7139
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.3
Reporter: Roman Kondakov
 Fix For: 2.4


At the moment a lazy execution is implemented for the distributed queries only 
(see {{GridMapQueryExecutor}}). We need to add this feature for the local 
queries too.



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Alexey Popov (JIRA)


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

Alexey Popov commented on IGNITE-7114:
--

just FYI, sample files for regexp:
ignite-core-2.1.7-p1.jar
ignite-core-2.1.7.b3.jar

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Created] (IGNITE-7138) BinaryMetadata should be marshalled with standard JdkMarshaller instead of BinaryMarshaller

2017-12-07 Thread Sergey Chugunov (JIRA)

Sergey Chugunov created IGNITE-7138:
---

 Summary: BinaryMetadata should be marshalled with standard 
JdkMarshaller instead of BinaryMarshaller
 Key: IGNITE-7138
 URL: https://issues.apache.org/jira/browse/IGNITE-7138
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Chugunov
 Fix For: 3.0


When running in persistent-enabled mode each Ignite node writes all updates of 
BinaryMetadata to local file system right from discovery thread.

On writing metadata has to be marshalled into byte array, BinaryMarshaller is 
used at the moment (see BinaryMetadataFileStore class for implementation).
It turned out it can cause a deadlock (more details are in linked ticket) when 
BinaryMarshaller decides to register metadata for one of the fields of initial 
BinaryMetadata object.

JdkMarshaller should be used instead as it doesn't rely on internal mechanics 
of Ignite node.
As it breaks compatibility this change cannot be implemented in 2.x version.



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

[jira] [Commented] (IGNITE-6187) Cache JdbcDatabaseMetadata in JdbcConnection

2017-12-07 Thread Ilya Kasnacheev (JIRA)


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

Ilya Kasnacheev commented on IGNITE-6187:
-

I don't think it makes any sense because it will call updateMetaData() every 
time on any non-trivial call, thus doing full amount of work.
Otherwise, JdbcDatabaseMetadata is lightweight.

Unless we have specific complaints about metadata performance it should be kept 
that way, I think.

> Cache JdbcDatabaseMetadata in JdbcConnection
> 
>
> Key: IGNITE-6187
> URL: https://issues.apache.org/jira/browse/IGNITE-6187
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>
> To avoid re-creating it every time



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

[jira] [Resolved] (IGNITE-6187) Cache JdbcDatabaseMetadata in JdbcConnection

2017-12-07 Thread Ilya Kasnacheev (JIRA)


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

Ilya Kasnacheev resolved IGNITE-6187.
-
Resolution: Won't Fix

> Cache JdbcDatabaseMetadata in JdbcConnection
> 
>
> Key: IGNITE-6187
> URL: https://issues.apache.org/jira/browse/IGNITE-6187
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>
> To avoid re-creating it every time



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Alexey Popov (JIRA)


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

Alexey Popov commented on IGNITE-7114:
--

[~isapego], Please look through the attached sample.png. Can you please check 
the absence of "-x.y.z" part with some error indication as well. That's a 
real-world example )

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Updated] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Alexey Popov (JIRA)


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

Alexey Popov updated IGNITE-7114:
-
Attachment: sample.png

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Updated] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Alexey Popov (JIRA)


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

Alexey Popov updated IGNITE-7114:
-
Attachment: (was: kodiak.png)

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Updated] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Alexey Popov (JIRA)


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

Alexey Popov updated IGNITE-7114:
-
Attachment: kodiak.png

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: kodiak.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Commented] (IGNITE-6872) Linear regression should implement Model API

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6872:


GitHub user oignatenko opened a pull request:

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

IGNITE-6872 Linear regression should implement Model API

Model and Trainer API implemented for OLS regression

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

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

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

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


commit cf6ba40c97840a28ee14f49f09f79fe3d9d5a66f
Author: Oleg Ignatenko 
Date:   2017-11-20T11:53:46Z

IGNITE-6872 Linear regression should implement Model API
- regression examples moved to more appropriate package
-- verified with diffs overview, clean build and execution of unit tests

commit a8dadee71e0ca2a00387cfa2dba9c656de75137f
Author: Oleg Ignatenko 
Date:   2017-11-20T11:57:18Z

IGNITE-6872 Linear regression should implement Model API
- added missing package-info
-- verified with diffs overview

commit cc8edfbd0ca7e20655f45dc82d576f2d21627497
Author: Oleg Ignatenko 
Date:   2017-11-20T14:12:03Z

IGNITE-6872 Linear regression should implement Model API
- implementation, tests and examples
- accommodated changes done to OLS per IGNITE-5846
- fixed some issues with coding style and javadoc
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit a0f294740b78dbe354a67a1658c9877544e587ea
Author: Oleg Ignatenko 
Date:   2017-11-21T08:57:27Z

IGNITE-6872 Linear regression should implement Model API
- decision trees example moved to more appropriate package
-- verified with diffs overview

commit e944568849d09f2bc7fca932bc043304208ff55d
Author: Oleg Ignatenko 
Date:   2017-11-21T13:25:31Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit dfa4ea896d404b7bd231b57e880b5745b9db634f
Author: Oleg Ignatenko 
Date:   2017-11-21T13:37:47Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit fe79868659d9a04d73234d800b7e5b1ba9029eeb
Author: Oleg Ignatenko 
Date:   2017-11-21T13:38:19Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit c69583b91eef73616827cbfe03ad9eb1ff7ccde0
Author: Oleg Ignatenko 
Date:   2017-11-21T13:42:56Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit 1ca1fb030d5be32843fce9746aa7d026a81d4502
Author: Oleg Ignatenko 
Date:   2017-11-21T13:45:15Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit 35918b024bca13dea3a061f623f743ab33f14cd7
Author: Oleg Ignatenko 
Date:   2017-11-21T13:49:53Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit 88fe344b83b9c9272eddc1c6e536febb0f8eff43
Author: Oleg Ignatenko 
Date:   2017-11-23T14:50:47Z

IGNITE-6872 Linear regression should implement Model API
- OLS regression Trainer wip - preliminary cleanup of QR decomposition
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit 24a27d9976fe5c1cf3ab876e410b4af63aec8792
Author: Oleg Ignatenko 
Date:   2017-11-23T15:26:20Z

IGNITE-6872 Linear regression should implement Model API
- OLS regression Trainer wip - adapter from QR decomposition to trainer
-- verified with diffs overview, clean build and execution of unit tests

commit 608d558fa33e61d86b35621ea706819621a017ba
Author: Oleg Ignatenko 
Date:   2017-11-27T16:16:19Z

IGNITE-6872 Linear regression should implement Model API
- OLS regression Trainer implemented
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit 857c0f83a281f9a37664988a50f2924f26140f47
Author: Oleg Ignatenko 
Date:   2017-12-07T11:04:41Z

Merge branch 'ignite-6872-2' into ignite-6872-4

# Conflicts:
#

[jira] [Commented] (IGNITE-6872) Linear regression should implement Model API

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6872:


Github user oignatenko closed the pull request at:

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


> Linear regression should implement Model API
> 
>
> Key: IGNITE-6872
> URL: https://issues.apache.org/jira/browse/IGNITE-6872
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> When linear regression was originally implemented per IGNITE-5012 we had no 
> Model API.
> Now that this API is available (merged into master with IGNITE-5218) lin 
> regression needs to adapt to implement it.



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

[jira] [Comment Edited] (IGNITE-6872) Linear regression should implement Model API

2017-12-07 Thread Oleg Ignatenko (JIRA)


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

Oleg Ignatenko edited comment on IGNITE-6872 at 12/7/17 11:24 AM:
--

[~chief] - I drafted implementation with Trainer API in branch 
[ignite-6872-4|https://github.com/gridgain/apache-ignite/tree/ignite-6872-4], 
would appreciate if you take a look.


was (Author: oignatenko):
[~chief] - I drafted implementation with Trainer API in branch 
[ignite-6872-3|https://github.com/gridgain/apache-ignite/tree/ignite-6872-3], 
would appreciate if you take a look.

> Linear regression should implement Model API
> 
>
> Key: IGNITE-6872
> URL: https://issues.apache.org/jira/browse/IGNITE-6872
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> When linear regression was originally implemented per IGNITE-5012 we had no 
> Model API.
> Now that this API is available (merged into master with IGNITE-5218) lin 
> regression needs to adapt to implement it.



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

[jira] [Assigned] (IGNITE-4835) Add ability to start rebalancing from management console

2017-12-07 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-4835:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

2017-12-07 Thread Dmitriy Sorokin (JIRA)


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

Dmitriy Sorokin commented on IGNITE-6171:
-

[~avinogradov], review new patch, please!

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
> Fix For: 2.4
>
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Commented] (IGNITE-4835) Add ability to start rebalancing from management console

2017-12-07 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov commented on IGNITE-4835:


Tested.

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Comment Edited] (IGNITE-6872) Linear regression should implement Model API

2017-12-07 Thread Oleg Ignatenko (JIRA)


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

Oleg Ignatenko edited comment on IGNITE-6872 at 12/7/17 10:21 AM:
--

[~chief] - I drafted implementation with Trainer API in branch 
[ignite-6872-3|https://github.com/gridgain/apache-ignite/tree/ignite-6872-3], 
would appreciate if you take a look.


was (Author: oignatenko):
[~chief] - I drafted implementation with Trainer API in branch 
[ignite-6872-2|https://github.com/gridgain/apache-ignite/tree/ignite-6872-2], 
would appreciate if you take a look.

> Linear regression should implement Model API
> 
>
> Key: IGNITE-6872
> URL: https://issues.apache.org/jira/browse/IGNITE-6872
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> When linear regression was originally implemented per IGNITE-5012 we had no 
> Model API.
> Now that this API is available (merged into master with IGNITE-5218) lin 
> regression needs to adapt to implement it.



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

[jira] [Commented] (IGNITE-6903) Implement new JMX metrics for Indexing

2017-12-07 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov commented on IGNITE-6903:
---

[~avinogradov], [~NIzhikov]
Looks good to me.

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



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

[jira] [Commented] (IGNITE-6872) Linear regression should implement Model API

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6872:


GitHub user oignatenko opened a pull request:

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

IGNITE-6872 Linear regression should implement Model API



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

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

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

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


commit cf6ba40c97840a28ee14f49f09f79fe3d9d5a66f
Author: Oleg Ignatenko 
Date:   2017-11-20T11:53:46Z

IGNITE-6872 Linear regression should implement Model API
- regression examples moved to more appropriate package
-- verified with diffs overview, clean build and execution of unit tests

commit a8dadee71e0ca2a00387cfa2dba9c656de75137f
Author: Oleg Ignatenko 
Date:   2017-11-20T11:57:18Z

IGNITE-6872 Linear regression should implement Model API
- added missing package-info
-- verified with diffs overview

commit cc8edfbd0ca7e20655f45dc82d576f2d21627497
Author: Oleg Ignatenko 
Date:   2017-11-20T14:12:03Z

IGNITE-6872 Linear regression should implement Model API
- implementation, tests and examples
- accommodated changes done to OLS per IGNITE-5846
- fixed some issues with coding style and javadoc
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit a0f294740b78dbe354a67a1658c9877544e587ea
Author: Oleg Ignatenko 
Date:   2017-11-21T08:57:27Z

IGNITE-6872 Linear regression should implement Model API
- decision trees example moved to more appropriate package
-- verified with diffs overview

commit e944568849d09f2bc7fca932bc043304208ff55d
Author: Oleg Ignatenko 
Date:   2017-11-21T13:25:31Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit dfa4ea896d404b7bd231b57e880b5745b9db634f
Author: Oleg Ignatenko 
Date:   2017-11-21T13:37:47Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit fe79868659d9a04d73234d800b7e5b1ba9029eeb
Author: Oleg Ignatenko 
Date:   2017-11-21T13:38:19Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit c69583b91eef73616827cbfe03ad9eb1ff7ccde0
Author: Oleg Ignatenko 
Date:   2017-11-21T13:42:56Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit 1ca1fb030d5be32843fce9746aa7d026a81d4502
Author: Oleg Ignatenko 
Date:   2017-11-21T13:45:15Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview

commit 35918b024bca13dea3a061f623f743ab33f14cd7
Author: Oleg Ignatenko 
Date:   2017-11-21T13:49:53Z

IGNITE-6872 Linear regression should implement Model API
- corrections per review
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit 88fe344b83b9c9272eddc1c6e536febb0f8eff43
Author: Oleg Ignatenko 
Date:   2017-11-23T14:50:47Z

IGNITE-6872 Linear regression should implement Model API
- OLS regression Trainer wip - preliminary cleanup of QR decomposition
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit 24a27d9976fe5c1cf3ab876e410b4af63aec8792
Author: Oleg Ignatenko 
Date:   2017-11-23T15:26:20Z

IGNITE-6872 Linear regression should implement Model API
- OLS regression Trainer wip - adapter from QR decomposition to trainer
-- verified with diffs overview, clean build and execution of unit tests

commit 608d558fa33e61d86b35621ea706819621a017ba
Author: Oleg Ignatenko 
Date:   2017-11-27T16:16:19Z

IGNITE-6872 Linear regression should implement Model API
- OLS regression Trainer implemented
-- verified with diffs overview, clean build, execution of unit tests and 
examples

commit 6aca220e1a40609b5d2a283a338a9f9bdecdfe33
Author: Oleg Ignatenko 
Date:   2017-12-07T10:01:26Z

Merge branch 'ignite-6872-2' into ignite-6872-3

# Conflicts:
#   modules/ml/src/test/java/org/apache/ignite/ml/LocalModelsTest.java
#

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

2017-12-07 Thread Igor Sapego (JIRA)


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

Igor Sapego commented on IGNITE-7114:
-

[~ptupitsyn], agree. I'll try to implement proposed logic.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Assigned] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails

2017-12-07 Thread Alexandr Kuramshin (JIRA)


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

Alexandr Kuramshin reassigned IGNITE-7135:
--

Assignee: Alexandr Kuramshin

> IgniteCluster.startNodes() returns successful ClusterStartNodeResult even 
> though the remote process fails
> -
>
> Key: IGNITE-7135
> URL: https://issues.apache.org/jira/browse/IGNITE-7135
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>  Labels: test
> Fix For: 2.4
>
>
> After unsuccessful start of three remote nodes with 
> {{IgniteCluster#startNodes(Collection>, 
> Map, boolean, int, int)}} we get 
> {{Collection}} with three elements, each has 
> {{isSuccess()}} is true.
> But the remote node startup log was
> {noformat}
> nohup: ignoring input
> /data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
> The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is 
> incorrect.
> Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
> You can also download latest JDK at http://java.com/download
> {noformat}



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

[jira] [Commented] (IGNITE-7134) Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-7134:


GitHub user akuramshingg opened a pull request:

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

IGNITE-7134 Never-ending timeout in 
IgniteSpiOperationTimeoutHelper.nextTimeoutChunk().



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

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

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

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


commit 982f91a695442a4f2a63f7dc96761f7cc87a25cf
Author: Alexandr Kuramshin 
Date:   2017-12-07T10:10:02Z

IGNITE-7134 Never-ending timeout in 
IgniteSpiOperationTimeoutHelper.nextTimeoutChunk().




> Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()
> --
>
> Key: IGNITE-7134
> URL: https://issues.apache.org/jira/browse/IGNITE-7134
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>Priority: Critical
> Fix For: 2.4
>
>
> {noformat}
> org.apache.ignite.spi.IgniteSpiOperationTimeoutHelper#nextTimeoutChunk
> long curTs = U.currentTimeMillis();
> timeout = timeout - (curTs - lastOperStartTs);
> {noformat}
> Timeout will not be decreased at all if delay between successive calls to 
> nextTimeoutChunk() is smaller than U.currentTimeMillis() discretization. Such 
> behaviour could be easily achieved when getting an error right after the 
> nextTimeoutChunk() invocation and do the retry.
> Only rare calls (the first right before U.currentTimeMillis() and the second 
> right after that) may decrease timeout, so actual 
> IgniteSpiOperationTimeoutHelper timeout could be much bigger than the 
> failureDetectionTimeout.
> My opinion to not split failureDetectionTimeout between network operations, 
> but initialize first operation timestamp at first call to nextTimeoutChunk(), 
> and then calculate the timeout as a difference between the current timestamp 
> and the first operation timestamp.



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

[jira] [Commented] (IGNITE-7088) Wrong implementation of DIRECT comparator for ordering cache start operations

2017-12-07 Thread Alexey Goncharuk (JIRA)


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

Alexey Goncharuk commented on IGNITE-7088:
--

Looks good to me.

> Wrong implementation of DIRECT comparator for ordering cache start operations
> -
>
> Key: IGNITE-7088
> URL: https://issues.apache.org/jira/browse/IGNITE-7088
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.4
>
>
> {code:java}
> java.lang.IllegalArgumentException: Comparison method violates its general 
> contract!
>   at java.util.TimSort.mergeHi(TimSort.java:899) ~[?:1.8.0_102]
>   at java.util.TimSort.mergeAt(TimSort.java:516) ~[?:1.8.0_102]
>   at java.util.TimSort.mergeForceCollapse(TimSort.java:457) ~[?:1.8.0_102]
>   at java.util.TimSort.sort(TimSort.java:254) ~[?:1.8.0_102]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[?:1.8.0_102]
>   at java.util.ArrayList.sort(ArrayList.java:1454) ~[?:1.8.0_102]
>   at java.util.Collections.sort(Collections.java:175) ~[?:1.8.0_102]
>   at 
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.orderedCaches(ClusterCachesInfo.java:1616)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.cachesReceivedFromJoin(ClusterCachesInfo.java:839)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1709)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:606)
>  [ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
>  [ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-2.1.7.jar:2.1.7]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_102]
> {code}
> When 2 not user caches will be compared using this comparator, this above 
> exception will be thrown.
> As a workaround can be used system variable 
> -Djava.util.Arrays.useLegacyMergeSort=true 



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

[jira] [Created] (IGNITE-7137) Provide a way to switch off BaselineTopology validation of nodes joining the cluster

2017-12-07 Thread Sergey Chugunov (JIRA)

Sergey Chugunov created IGNITE-7137:
---

 Summary: Provide a way to switch off BaselineTopology validation 
of nodes joining the cluster
 Key: IGNITE-7137
 URL: https://issues.apache.org/jira/browse/IGNITE-7137
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Reporter: Sergey Chugunov


In specific circumstances like split-brain user may need an ability to switch 
BaselineTopology validation off for a period of time when the cluster is 
assembling back.

To do so we need to provide an API to switch BaselineTopology validation on and 
off dynamically.



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

[jira] [Commented] (IGNITE-7136) Add JMX metric for indexing to .Net

2017-12-07 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-7136:


See also IGNITE-7128.

> Add JMX metric for indexing to .Net 
> 
>
> Key: IGNITE-7136
> URL: https://issues.apache.org/jira/browse/IGNITE-7136
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Pavel Tupitsyn
>  Labels: iep-6
> Fix For: 2.4
>
>
> New JMX metric implemented in IGNITE-6903.
> We need to add support for this metric to .Net 



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

[jira] [Assigned] (IGNITE-7134) Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()

2017-12-07 Thread Alexandr Kuramshin (JIRA)


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

Alexandr Kuramshin reassigned IGNITE-7134:
--

Assignee: Alexandr Kuramshin

> Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()
> --
>
> Key: IGNITE-7134
> URL: https://issues.apache.org/jira/browse/IGNITE-7134
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>Priority: Critical
> Fix For: 2.4
>
>
> {noformat}
> org.apache.ignite.spi.IgniteSpiOperationTimeoutHelper#nextTimeoutChunk
> long curTs = U.currentTimeMillis();
> timeout = timeout - (curTs - lastOperStartTs);
> {noformat}
> Timeout will not be decreased at all if delay between successive calls to 
> nextTimeoutChunk() is smaller than U.currentTimeMillis() discretization. Such 
> behaviour could be easily achieved when getting an error right after the 
> nextTimeoutChunk() invocation and do the retry.
> Only rare calls (the first right before U.currentTimeMillis() and the second 
> right after that) may decrease timeout, so actual 
> IgniteSpiOperationTimeoutHelper timeout could be much bigger than the 
> failureDetectionTimeout.
> My opinion to not split failureDetectionTimeout between network operations, 
> but initialize first operation timestamp at first call to nextTimeoutChunk(), 
> and then calculate the timeout as a difference between the current timestamp 
> and the first operation timestamp.



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

[jira] [Created] (IGNITE-7136) Add JMX metric for indexing to .Net

2017-12-07 Thread Nikolay Izhikov (JIRA)

Nikolay Izhikov created IGNITE-7136:
---

 Summary: Add JMX metric for indexing to .Net 
 Key: IGNITE-7136
 URL: https://issues.apache.org/jira/browse/IGNITE-7136
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Nikolay Izhikov
Assignee: Pavel Tupitsyn


New JMX metric implemented in IGNITE-6903.
We need to add support for this metric to .Net 



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

[jira] [Created] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails

2017-12-07 Thread Alexandr Kuramshin (JIRA)

Alexandr Kuramshin created IGNITE-7135:
--

 Summary: IgniteCluster.startNodes() returns successful 
ClusterStartNodeResult even though the remote process fails
 Key: IGNITE-7135
 URL: https://issues.apache.org/jira/browse/IGNITE-7135
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexandr Kuramshin
 Fix For: 2.4


After unsuccessful start of three remote nodes with 
{{IgniteCluster#startNodes(Collection>, Map, 
boolean, int, int)}} we get {{Collection}} with three 
elements, each has {{isSuccess()}} is true.

But the remote node startup log was
{noformat}
nohup: ignoring input
/data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is 
incorrect.
Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
You can also download latest JDK at http://java.com/download
{noformat}



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

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

2017-12-07 Thread Andrey Kuznetsov (JIRA)


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

Andrey Kuznetsov commented on IGNITE-6711:
--

[~avinogradov], could you please review the fix?

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



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

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

2017-12-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6711:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-6711: TotalAllocatedPages metric fix.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-6711

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

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


commit e6c75e81b87ec7e4e2489dd6a96e2f5a0b3d0c89
Author: Andrey Kuznetsov 
Date:   2017-12-07T08:23:47Z

IGNITE-6711: TotalAllocatedPages metric fix.




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



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

[jira] [Assigned] (IGNITE-4835) Add ability to start rebalancing from management console

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-4835:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Commented] (IGNITE-4835) Add ability to start rebalancing from management console

2017-12-07 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-4835:
---

Fixed check of not exist cache. Fixed check on scan of system cache.

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Vasiliy Sisko
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Closed] (IGNITE-7133) Web console: Improve ignite icon service interface to extendable

2017-12-07 Thread Alexey Kuznetsov (JIRA)


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

Alexey Kuznetsov closed IGNITE-7133.


> Web console: Improve ignite icon service interface to extendable
> 
>
> Key: IGNITE-7133
> URL: https://issues.apache.org/jira/browse/IGNITE-7133
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>




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

93 matches

Mail list logo