[jira] [Commented] (IGNITE-7930) Partition map hang in incorrect state when backup filter is assigned

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-7930:
--

[~v.pyatkov] Can u reproduce it with considering of Ilya notice? Or we should 
close this issue with "Can't reproduce" resolution?

> Partition map hang in incorrect state when backup filter is assigned
> 
>
> Key: IGNITE-7930
> URL: https://issues.apache.org/jira/browse/IGNITE-7930
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Attachments: IgnitePdsRebalanceCompletionTest.java
>
>
> The test ([^IgnitePdsRebalanceCompletionTest.java]) shown, which some 
> partition turn up OWNING (but this should not be so) state and whole cluster 
> hangs.



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

[jira] [Comment Edited] (IGNITE-7298) Web console: error on web agent start in case if demo is opened in browser

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-7298 at 4/27/18 2:15 AM:
-

Here is what I see when I start console from the branch ignite-7298
{code}
[2018-04-27 09:10:29,927][INFO ][main][AgentLauncher] Starting Apache Ignite 
Web Console Agent...

Agent configuration:
User's security tokens: 3W5D
URI to Ignite node REST server: http://localhost:8080
URI to Ignite Console server  : http://192.168.1.221
Path to agent property file   : default.properties
Path to JDBC drivers folder   : C:\work\ignite-web-agent-9.9.9\jdbc-drivers
Demo mode : enabled

[2018-04-27 09:10:30,951][INFO ][main][AgentLauncher] Connecting to: 
http://192.168.1.221
[2018-04-27 09:10:31,035][INFO ][EventThread][AgentLauncher] Connection 
established.
[2018-04-27 09:10:31,120][INFO ][EventThread][AgentLauncher] Authentication 
success.
[2018-04-27 09:10:31,167][INFO ][pool-4-thread-1][AgentClusterDemo] DEMO: 
Starting embedded nodes for demo...
[2018-04-27 09:10:32,854][ERROR][demo-nodes-start-0][] Failed to resolve 
default logging config file: config/java.util.logging.properties
Console logging handler is not configured.
{code}


was (Author: pkonstantinov):
Here is what I see when I start console from the branch
{code}
[2018-04-27 09:10:29,927][INFO ][main][AgentLauncher] Starting Apache Ignite 
Web Console Agent...

Agent configuration:
User's security tokens: 3W5D
URI to Ignite node REST server: http://localhost:8080
URI to Ignite Console server  : http://192.168.1.221
Path to agent property file   : default.properties
Path to JDBC drivers folder   : C:\work\ignite-web-agent-9.9.9\jdbc-drivers
Demo mode : enabled

[2018-04-27 09:10:30,951][INFO ][main][AgentLauncher] Connecting to: 
http://192.168.1.221
[2018-04-27 09:10:31,035][INFO ][EventThread][AgentLauncher] Connection 
established.
[2018-04-27 09:10:31,120][INFO ][EventThread][AgentLauncher] Authentication 
success.
[2018-04-27 09:10:31,167][INFO ][pool-4-thread-1][AgentClusterDemo] DEMO: 
Starting embedded nodes for demo...
[2018-04-27 09:10:32,854][ERROR][demo-nodes-start-0][] Failed to resolve 
default logging config file: config/java.util.logging.properties
Console logging handler is not configured.
{code}

> Web console: error on web agent start in case if demo is opened in browser
> --
>
> Key: IGNITE-7298
> URL: https://issues.apache.org/jira/browse/IGNITE-7298
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> {code}
> [ERROR][demo-nodes-start-0][] Failed to resolve default logging config file: 
> config/java.util.logging.properties
> Console logging handler is not configured.
> {code}



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

[jira] [Assigned] (IGNITE-7298) Web console: error on web agent start in case if demo is opened in browser

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7298:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Web console: error on web agent start in case if demo is opened in browser
> --
>
> Key: IGNITE-7298
> URL: https://issues.apache.org/jira/browse/IGNITE-7298
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> {code}
> [ERROR][demo-nodes-start-0][] Failed to resolve default logging config file: 
> config/java.util.logging.properties
> Console logging handler is not configured.
> {code}



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

[jira] [Commented] (IGNITE-7298) Web console: error on web agent start in case if demo is opened in browser

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7298:


Here is what I see when I start console from the branch
{code}
[2018-04-27 09:10:29,927][INFO ][main][AgentLauncher] Starting Apache Ignite 
Web Console Agent...

Agent configuration:
User's security tokens: 3W5D
URI to Ignite node REST server: http://localhost:8080
URI to Ignite Console server  : http://192.168.1.221
Path to agent property file   : default.properties
Path to JDBC drivers folder   : C:\work\ignite-web-agent-9.9.9\jdbc-drivers
Demo mode : enabled

[2018-04-27 09:10:30,951][INFO ][main][AgentLauncher] Connecting to: 
http://192.168.1.221
[2018-04-27 09:10:31,035][INFO ][EventThread][AgentLauncher] Connection 
established.
[2018-04-27 09:10:31,120][INFO ][EventThread][AgentLauncher] Authentication 
success.
[2018-04-27 09:10:31,167][INFO ][pool-4-thread-1][AgentClusterDemo] DEMO: 
Starting embedded nodes for demo...
[2018-04-27 09:10:32,854][ERROR][demo-nodes-start-0][] Failed to resolve 
default logging config file: config/java.util.logging.properties
Console logging handler is not configured.
{code}

> Web console: error on web agent start in case if demo is opened in browser
> --
>
> Key: IGNITE-7298
> URL: https://issues.apache.org/jira/browse/IGNITE-7298
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
>
> {code}
> [ERROR][demo-nodes-start-0][] Failed to resolve default logging config file: 
> config/java.util.logging.properties
> Console logging handler is not configured.
> {code}



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

[jira] [Commented] (IGNITE-5819) SQL: add support for TRUNCATE TABLE command.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5819:


Github user shroman closed the pull request at:

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


> SQL: add support for TRUNCATE TABLE command.
> 
>
> Key: IGNITE-5819
> URL: https://issues.apache.org/jira/browse/IGNITE-5819
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Add support for  "TRUNCATE TABLE" command syntax.



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

[jira] [Assigned] (IGNITE-5819) SQL: add support for TRUNCATE TABLE command.

[Roman Shtykh (JIRA)]

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

Roman Shtykh reassigned IGNITE-5819:


Assignee: (was: Roman Shtykh)

> SQL: add support for TRUNCATE TABLE command.
> 
>
> Key: IGNITE-5819
> URL: https://issues.apache.org/jira/browse/IGNITE-5819
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Add support for  "TRUNCATE TABLE" command syntax.



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

[jira] [Commented] (IGNITE-5819) SQL: add support for TRUNCATE TABLE command.

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-5819:
--

Hi [~vozerov],

Thanks a lot for the explanations! Got it.

> SQL: add support for TRUNCATE TABLE command.
> 
>
> Key: IGNITE-5819
> URL: https://issues.apache.org/jira/browse/IGNITE-5819
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Roman Shtykh
>Priority: Major
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Add support for  "TRUNCATE TABLE" command syntax.



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

[jira] [Closed] (IGNITE-8052) Clear error message needed when using a non-existing column name for CREATE TABLE primary key

[Roman Shtykh (JIRA)]

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

Roman Shtykh closed IGNITE-8052.


> Clear error message needed when using a non-existing column name for CREATE 
> TABLE primary key
> -
>
> Key: IGNITE-8052
> URL: https://issues.apache.org/jira/browse/IGNITE-8052
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Minor
>  Labels: usability
> Fix For: 2.5
>
>
> On _CREATE TABLE_ with a misspelled column name for _PRIMARY KEY_ we have the 
> following error with assertions enabled
> {code:java}
> java.lang.AssertionError
>     at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseCreateTable(GridSqlQueryParser.java:1044)
>     at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1647)
>     at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:245)
>     ...
> {code}
> and when disabled
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: null
>     at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:492)
>     at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1643)
>     at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1577)
>     ...
> {code}



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

[jira] [Updated] (IGNITE-8198) Document how to use username/password for REST, drivers and thin clients

[Prachi Garg (JIRA)]

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

Prachi Garg updated IGNITE-8198:

Description: 
Overall, we have to update the following protocols/driving explaining how to 
open a secured connection:
 * JDBC/ODBC
 * Binary Client Protocol: 
[https://apacheignite.readme.io/docs/binary-client-protocol#section-handshake]
 * Thin clients (Java and Net)
 * REST protocol - [https://apacheignite.readme.io/docs/rest-api]

Set  in ignite 
configuration when persistence is enabled.

Talk to [~vozerov] and [~taras.ledkov] to get more details and support. They've 
been working on this functionality: 
https://issues.apache.org/jira/browse/IGNITE-7436

  was:
Overall, we have to update the following protocols/driving explaining how to 
open a secured connection:
* JDBC/ODBC
* Binary Client Protocol: 
https://apacheignite.readme.io/docs/binary-client-protocol#section-handshake
* Thin clients (Java and Net)
* REST protocol - [https://apacheignite.readme.io/docs/rest-api]

Talk to [~vozerov] and [~taras.ledkov] to get more details and support. They've 
been working on this functionality: 
https://issues.apache.org/jira/browse/IGNITE-7436


> Document how to use username/password for REST, drivers and thin clients
> 
>
> Key: IGNITE-8198
> URL: https://issues.apache.org/jira/browse/IGNITE-8198
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
>Reporter: Prachi Garg
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Overall, we have to update the following protocols/driving explaining how to 
> open a secured connection:
>  * JDBC/ODBC
>  * Binary Client Protocol: 
> [https://apacheignite.readme.io/docs/binary-client-protocol#section-handshake]
>  * Thin clients (Java and Net)
>  * REST protocol - [https://apacheignite.readme.io/docs/rest-api]
> Set  in ignite 
> configuration when persistence is enabled.
> Talk to [~vozerov] and [~taras.ledkov] to get more details and support. 
> They've been working on this functionality: 
> https://issues.apache.org/jira/browse/IGNITE-7436



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

[jira] [Commented] (IGNITE-8330) Docs: Put JDBC/ODBC URL in Brackets When Connecting From Bash

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-8330:
-

Fixed on  SQLLine page. 
[https://apacheignite-sql.readme.io/v2.4/docs/sqlline-25#section-using-authentication]
 

Need to document - https://issues.apache.org/jira/browse/IGNITE-8198 first 
before adding a callout to JDBC/ODBC pages.

> Docs: Put JDBC/ODBC URL in Brackets When Connecting From Bash
> -
>
> Key: IGNITE-8330
> URL: https://issues.apache.org/jira/browse/IGNITE-8330
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> We need to add a warning callout with the content below to both JDBC and ODBC 
> documentation pages:
> Title: Put JDBC/ODBC URL in Brackets When Connecting From Bash
> Description:
> Make sure to put the connection URL in " brackets when opening it up from a 
> bash environment, as follows: 
> "jdbc:ignite:thin://[address]:[port];user=ignite;password=[password]"



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

[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-8075:
--

Ok, I'll remove it. Do you have other remarks? 

> .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, 
> setTxTimeoutOnPartitionMapExchange
> 
>
> Key: IGNITE-8075
> URL: https://issues.apache.org/jira/browse/IGNITE-8075
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Alexei Scherbakov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.6
>
>
> Neet to add new methods as part of .NET API:
> org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange
>  - timeout for automatic rollback on exchange.
> org.apache.ignite.IgniteTransactions#withLabel - tx label
> org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local 
> active transactions.
> org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange
> Java implementation is currently available at a branch [1]
> [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2



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

[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-8075:


[~ivandasch] I agree with FxCop here. We do not expect a failure there, no need 
to catch any exceptions.
The {{Dispose method should not throw an exception}} rule is mostly about 
explicit {{throw}} or some expected exceptions.

If current Dispose method throws we are screwed anyway, because something has 
went very wrong. Trying to hide this will do no good.

> .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, 
> setTxTimeoutOnPartitionMapExchange
> 
>
> Key: IGNITE-8075
> URL: https://issues.apache.org/jira/browse/IGNITE-8075
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Alexei Scherbakov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.6
>
>
> Neet to add new methods as part of .NET API:
> org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange
>  - timeout for automatic rollback on exchange.
> org.apache.ignite.IgniteTransactions#withLabel - tx label
> org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local 
> active transactions.
> org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange
> Java implementation is currently available at a branch [1]
> [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2



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

[jira] [Commented] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised on-heap cache configuration

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin commented on IGNITE-8237:
--

[~dpavlov], the fix is need in 2.5

> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration 
> --
>
> Key: IGNITE-8237
> URL: https://issues.apache.org/jira/browse/IGNITE-8237
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration. Consider moving IGNITE_DISABLE_ONHEAP_CACHE 
> system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Comment Edited] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[David Harvey (JIRA)]

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

David Harvey edited comment on IGNITE-8406 at 4/26/18 8:15 PM:
---

I believe that the code will throw a {{CacheException as described, except I 
think there is a small window where it will not.}}
 * DataStreamerImpl.flush() calls EnterBusy while activeFuts is non empty.  
This seems to be the last test of "cancelled" in EnterBusy.   If there were 
exceptional completions before this, flush() will throw due to the code in 
EnterBusy().
 * Before doFlush() looks at activeFuts, activeFuts becomes empty because a 
buffer asynchronously had an exceptional completion.  Because activeFuts is 
empty, doFlush and flush will return without an exception, even though some 
futures previously returned by addData() have had exceptions thrown.

In addition to the documentation change, an inelegant fix would be to call 
"EnterBusy();leaveBusy();" at the end of flush()


was (Author: syssoftsol):
I believe that the code will throw a throw {{CacheException as described, 
except I think there is a small window where it will not.}}
 * DataStreamerImpl.flush() calls EnterBusy while activeFuts is non empty.  
This seems to be the last test of "cancelled" in EnterBusy.   If there were 
exceptional completions before this, flush() will throw due to the code in 
EnterBusy().
 * Before doFlush() looks at activeFuts, activeFuts becomes empty because a 
buffer asynchronously had an exceptional completion.  Because activeFuts is 
empty, doFlush and flush will return without an exception, even though some 
futures previously returned by addData() have had exceptions thrown.

In addition to the documentation change, an inelegant fix would be to call 
"EnterBusy();leaveBusy();" at the end of flush()

> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or 
> more futures previously returned by {{addData()}} have been completed 
> exceptionally. This behavior should be described in {{IgniteDataStreamer}} 
> javadoc.



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

[jira] [Commented] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[David Harvey (JIRA)]

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

David Harvey commented on IGNITE-8406:
--

I believe that the code will throw a throw {{CacheException as described, 
except I think there is a small window where it will not.}}
 * DataStreamerImpl.flush() calls EnterBusy while activeFuts is non empty.  
This seems to be the last test of "cancelled" in EnterBusy.   If there were 
exceptional completions before this, flush() will throw due to the code in 
EnterBusy().
 * Before doFlush() looks at activeFuts, activeFuts becomes empty because a 
buffer asynchronously had an exceptional completion.  Because activeFuts is 
empty, doFlush and flush will return without an exception, even though some 
futures previously returned by addData() have had exceptions thrown.

In addition to the documentation change, an inelegant fix would be to call 
"EnterBusy();leaveBusy();" at the end of flush()

> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or 
> more futures previously returned by {{addData()}} have been completed 
> exceptionally. This behavior should be described in {{IgniteDataStreamer}} 
> javadoc.



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

[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-2313:


Hello, Igniters!

I have updated PR and refreshed tests. Only flacky tests failed. Can you look 
changes?

> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
>
> Currently atomic operations within a transaction succeed without alarming a 
> user that no transaction really occurs. We should add a mode to fail such 
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following 
> error message: {{Transaction spans operations on atomic cache (consider 
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to 
> true)}}



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

[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL

[Amir Akhmedov (JIRA)]

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

Amir Akhmedov commented on IGNITE-3999:
---

[~dpavlov], conflicts resolved.

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Currently case insensitive search is possible only with the help of 
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add 
> a respective property to {{@QuerySqlField}} annotation.



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

[jira] [Created] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8406:


 Summary: Update IgniteDataStreamer.flush() javadoc
 Key: IGNITE-8406
 URL: https://issues.apache.org/jira/browse/IGNITE-8406
 Project: Ignite
  Issue Type: Task
  Components: streaming
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
 Fix For: 2.6


Current {{flush()}} implementation can throw {{CacheException}} if one or more 
futures previously returned by {{addData()}} have been completed exceptionally. 
This behavior should be described in {{IgniteDataStreamer}} javadoc.



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

[jira] [Commented] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8393:
--

I think I got it, wakeupForCheckpoint may return early if there is an ongoing 
checkpoint. Looks good to me.

>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
> 2018-04-26 11:35:25.391 [INFO 
> ][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed 
> class: GridDeployment [ts=1524730971870, depMode=SHARED, 
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
>  clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
>  pendingUndeploy=false, undeployed=true, usage=0]
> 2018-04-26 11:35:25.400 [INFO 
> ][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
> We should softly handle this situation: print message in log and continue the 
> compression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Commented] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8393:
--

[~ivan.glukos], in the test you are trying to start two checkpoints, however 
the second checkpoint will be skipped (or may be skipped) because there are no 
modified pages after the first checkpoint. Please double-check the behavior.

>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
> 2018-04-26 11:35:25.391 [INFO 
> ][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed 
> class: GridDeployment [ts=1524730971870, depMode=SHARED, 
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
>  clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
>  pendingUndeploy=false, undeployed=true, usage=0]
> 2018-04-26 11:35:25.400 [INFO 
> ][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
> We should softly handle this situation: print message in log and continue the 
> compression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Commented] (IGNITE-8405) Sql query may see intermediate results of topology changes and perform mapping incorrectly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8405:


GitHub user Jokser opened a pull request:

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

IGNITE-8405 Update partition owners during exchange in 1 operation



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

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

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

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


commit 158fa123464426a8188f60a6af0bfb04752a487d
Author: Pavel Kovalenko 
Date:   2018-04-26T17:55:57Z

IGNITE-8405 Update partition owners during exchange in 1 operation.




> Sql query may see intermediate results of topology changes and perform 
> mapping incorrectly
> --
>
> Key: IGNITE-8405
> URL: https://issues.apache.org/jira/browse/IGNITE-8405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>
> Affected test: IgniteStableBaselineCacheQueryNodeRestartsSelfTest
> Sql query do mapping in following way:
> 1) If there is at least 1 moving partition query will be mapped to current 
> partition owners
> 2) In other case affinity mapping will be used.
> In case of first approach query may see not final partition state if mapping 
> happens during PME. There is "setOwners()" method which does partition 
> movement one-by-one, each time obtaining topology write lock. If query 
> mapping happens in this time it may see that there is some moving partition 
> and performed mapping to OWNING partition which will be moved to MOVING on 
> next "setOwners()" invocation.
> As result we may query from invalid partitions.
> As intermediate solution "setOwners()" method should be refactored in a batch 
> way to perform ALL partitions state changes to MOVING in one operation.
> As general solution query mapping should be revisited, especially 
> "isPreloadingActive" method, to take into account given topology version.



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

[jira] [Updated] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised on-heap cache configuration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8237:
---
Fix Version/s: (was: 2.5)
   2.6

> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration 
> --
>
> Key: IGNITE-8237
> URL: https://issues.apache.org/jira/browse/IGNITE-8237
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration. Consider moving IGNITE_DISABLE_ONHEAP_CACHE 
> system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Updated] (IGNITE-8405) Sql query may see intermediate results of topology changes and perform mapping incorrectly

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-8405:

Summary: Sql query may see intermediate results of topology changes and 
perform mapping incorrectly  (was: Sql query may see intermediate results of 
topology changes and do mapping incorrectly)

> Sql query may see intermediate results of topology changes and perform 
> mapping incorrectly
> --
>
> Key: IGNITE-8405
> URL: https://issues.apache.org/jira/browse/IGNITE-8405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>
> Affected test: IgniteStableBaselineCacheQueryNodeRestartsSelfTest
> Sql query do mapping in following way:
> 1) If there is at least 1 moving partition query will be mapped to current 
> partition owners
> 2) In other case affinity mapping will be used.
> In case of first approach query may see not final partition state if mapping 
> happens during PME. There is "setOwners()" method which does partition 
> movement one-by-one, each time obtaining topology write lock. If query 
> mapping happens in this time it may see that there is some moving partition 
> and performed mapping to OWNING partition which will be moved to MOVING on 
> next "setOwners()" invocation.
> As result we may query from invalid partitions.
> As intermediate solution "setOwners()" method should be refactored in a batch 
> way to perform ALL partitions state changes to MOVING in one operation.
> As general solution query mapping should be revisited, especially 
> "isPreloadingActive" method, to take into account given topology version.



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

[jira] [Created] (IGNITE-8405) Sql query may see intermediate results of topology changes and do mapping incorrectly

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8405:
---

 Summary: Sql query may see intermediate results of topology 
changes and do mapping incorrectly
 Key: IGNITE-8405
 URL: https://issues.apache.org/jira/browse/IGNITE-8405
 Project: Ignite
  Issue Type: Bug
  Components: cache, sql
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko


Affected test: IgniteStableBaselineCacheQueryNodeRestartsSelfTest

Sql query do mapping in following way:
1) If there is at least 1 moving partition query will be mapped to current 
partition owners
2) In other case affinity mapping will be used.

In case of first approach query may see not final partition state if mapping 
happens during PME. There is "setOwners()" method which does partition movement 
one-by-one, each time obtaining topology write lock. If query mapping happens 
in this time it may see that there is some moving partition and performed 
mapping to OWNING partition which will be moved to MOVING on next "setOwners()" 
invocation.

As result we may query from invalid partitions.

As intermediate solution "setOwners()" method should be refactored in a batch 
way to perform ALL partitions state changes to MOVING in one operation.

As general solution query mapping should be revisited, especially 
"isPreloadingActive" method, to take into account given topology version.



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

[jira] [Comment Edited] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov edited comment on IGNITE-8393 at 4/26/18 5:38 PM:
-

TC run: https://ci.ignite.apache.org/viewLog.html?buildId=1251013


was (Author: ivan.glukos):
TC run: https://ci.ignite.apache.org/viewLog.html?buildId=1251005;

>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
> 2018-04-26 11:35:25.391 [INFO 
> ][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed 
> class: GridDeployment [ts=1524730971870, depMode=SHARED, 
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
>  clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
>  pendingUndeploy=false, undeployed=true, usage=0]
> 2018-04-26 11:35:25.400 [INFO 
> ][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
> We should softly handle this situation: print message in log and continue the 
> compression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Commented] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-8393:


TC run: https://ci.ignite.apache.org/viewLog.html?buildId=1251005;

>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
> 2018-04-26 11:35:25.391 [INFO 
> ][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed 
> class: GridDeployment [ts=1524730971870, depMode=SHARED, 
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
>  clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
>  pendingUndeploy=false, undeployed=true, usage=0]
> 2018-04-26 11:35:25.400 [INFO 
> ][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
> We should softly handle this situation: print message in log and continue the 
> compression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Commented] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8393:


GitHub user glukos opened a pull request:

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

IGNITE-8393 Unexpected error during WAL compression



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

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

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

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


commit 216c18e9e1b46b019283f54e724c28e437715b58
Author: Ivan Rakov 
Date:   2018-04-26T17:12:29Z

IGNITE-8393 Unexpected error during WAL compression




>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
> 2018-04-26 11:35:25.391 [INFO 
> ][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed 
> class: GridDeployment [ts=1524730971870, depMode=SHARED, 
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
>  clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
>  pendingUndeploy=false, undeployed=true, usage=0]
> 2018-04-26 11:35:25.400 [INFO 
> ][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
> We should softly handle this situation: print message in log and continue the 
> compression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Resolved] (IGNITE-8404) NPE when shutting down non-initialized mapped file memory provier

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-8404.
--
Resolution: Fixed

Fixed in master and ignite-2.5

> NPE when shutting down non-initialized mapped file memory provier
> -
>
> Key: IGNITE-8404
> URL: https://issues.apache.org/jira/browse/IGNITE-8404
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> If a node has mapped file memory provider and node initialization fails, I 
> get the following exception:
> {code}
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.mem.file.MappedFileMemoryProvider.shutdown(MappedFileMemoryProvider.java:97)
> at 
> org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.stop(PageMemoryNoStoreImpl.java:239)
> at 
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.stop0(IgniteCacheDatabaseSharedManager.java:649)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:888)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2109)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1987)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1074)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1062)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:948)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:847)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:717)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:686)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> {code}
> The cause is obvious - we try to access an uninitialized field.



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

[jira] [Updated] (IGNITE-8404) NPE when shutting down non-initialized mapped file memory provier

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8404:
-
Fix Version/s: 2.5

> NPE when shutting down non-initialized mapped file memory provier
> -
>
> Key: IGNITE-8404
> URL: https://issues.apache.org/jira/browse/IGNITE-8404
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> If a node has mapped file memory provider and node initialization fails, I 
> get the following exception:
> {code}
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.mem.file.MappedFileMemoryProvider.shutdown(MappedFileMemoryProvider.java:97)
> at 
> org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.stop(PageMemoryNoStoreImpl.java:239)
> at 
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.stop0(IgniteCacheDatabaseSharedManager.java:649)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:888)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2109)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1987)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1074)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1062)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:948)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:847)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:717)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:686)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> {code}
> The cause is obvious - we try to access an uninitialized field.



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

[jira] [Assigned] (IGNITE-8267) Web console: cluster client connector configuration fields are too narrow

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8267:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Web console: cluster client connector configuration fields are too narrow
> -
>
> Key: IGNITE-8267
> URL: https://issues.apache.org/jira/browse/IGNITE-8267
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.6
>
> Attachments: image-2018-04-16-11-31-15-136.png, screenshot-1.png
>
>
> *How to reproduce:*
> 1. Go to advanced cluster configuration.
> 2. Open "client connector configuration" section.
> *What happens:*
> "Socket send buffer size" and "Socket receive buffer size" field labels wrap 
> to second line.
>  !image-2018-04-16-11-31-15-136.png! 
> *What should happen:*
> "Socket send buffer size" and "Socket receive buffer size" field labels 
> should be on a single line.



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

[jira] [Updated] (IGNITE-8077) Implement new JMX metrics for transactions

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-8077:
---
Description: 
These additional metrics should be implemented to monitor transactions.

{code}
class TransactionMetricsMxBean{
/** The number of transactions which were committed. */
long getTransactionsCommittedNumber();
/** The number of transactions which was rollbacked. */
long getTransactionsRolledBackNumber();
/** The number of transactions holding at least one key lock. */
long getTransactionsHoldingLockNumber();
/** The number of keys locked on the node. */
long getLockedKeysNumber();
/** The number of transactions for which node is the initiator. */
int getOwnerTransactionsNumber();
}
{code}

For more details see in IgniteTxAdapter and IgniteTxManager.

  was:
These additional metrics should be implemented to monitor transactions.

{code}
class TransactionMetricsMxBean{
/** The number of transactions which was commited. */
long getTxCommited();
/** The number of transactions which was rollbacked. */
long getTxRolledBack();
/** The number of transactions holding at least one key lock. */
long getTxHoldingLock();
/** The number of keys locked on the node. */
long getLockedKeys();
/** The number of transactions for which node is the initiator. */
int getOwnerTxs();
}
{code}

For more details see in IgniteTxAdapter and IgniteTxManager.


> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionMetricsMxBean{
> /** The number of transactions which were committed. */
> long getTransactionsCommittedNumber();
> /** The number of transactions which was rollbacked. */
> long getTransactionsRolledBackNumber();
> /** The number of transactions holding at least one key lock. */
> long getTransactionsHoldingLockNumber();
> /** The number of keys locked on the node. */
> long getLockedKeysNumber();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTransactionsNumber();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Commented] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised on-heap cache configuration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8237:


Merged PR to master (2.6), and added javadoc for parameter description for 
authorizeCacheChange & authorizeCacheCreate

> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration 
> --
>
> Key: IGNITE-8237
> URL: https://issues.apache.org/jira/browse/IGNITE-8237
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration. Consider moving IGNITE_DISABLE_ONHEAP_CACHE 
> system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Updated] (IGNITE-8077) Implement new JMX metrics for transactions

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-8077:
---
Description: 
These additional metrics should be implemented to monitor transactions.

{code}
class TransactionMetricsMxBean{
/** The number of transactions which was commited. */
long getTxCommited();
/** The number of transactions which was rollbacked. */
long getTxRolledBack();
/** The number of transactions holding at least one key lock. */
long getTxHoldingLock();
/** The number of keys locked on the node. */
long getLockedKeys();
/** The number of transactions for which node is the initiator. */
int getOwnerTxs();
}
{code}

For more details see in IgniteTxAdapter and IgniteTxManager.

  was:
These additional metrics should be implemented to monitor transactions.

{code}
class TransactionsMXbean{
/** The number of transactions which was commited. */
long getTxCommited();
/** The number of transactions which was rollbacked. */
long getTxRolledBack();
/** The number of transactions holding at least one key lock. */
long getTxHoldingLock();
/** The number of keys locked on the node. */
long getLockedKeys();
/** The number of transactions for which node is the initiator. */
int getOwnerTxs();
}
{code}

For more details see in IgniteTxAdapter and IgniteTxManager.


> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionMetricsMxBean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Commented] (IGNITE-8394) ODBC: Can not establish SSL connection to remote host.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8394:


Github user asfgit closed the pull request at:

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


> ODBC: Can not establish SSL connection to remote host.
> --
>
> Key: IGNITE-8394
> URL: https://issues.apache.org/jira/browse/IGNITE-8394
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc, ssl, tls
> Fix For: 2.5
>
>
> Driver connects to the local server, but when connecting to remote server 
> client sometimes returns error when trying to establish async connection, 
> though the connection established successfully, if the error is ignored.



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

[jira] [Commented] (IGNITE-8394) ODBC: Can not establish SSL connection to remote host.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-8394:
-

Thanks, [~skalashnikov]

> ODBC: Can not establish SSL connection to remote host.
> --
>
> Key: IGNITE-8394
> URL: https://issues.apache.org/jira/browse/IGNITE-8394
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc, ssl, tls
> Fix For: 2.5
>
>
> Driver connects to the local server, but when connecting to remote server 
> client sometimes returns error when trying to establish async connection, 
> though the connection established successfully, if the error is ignored.



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

[jira] [Commented] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised on-heap cache configuration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8237:


Github user asfgit closed the pull request at:

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


> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration 
> --
>
> Key: IGNITE-8237
> URL: https://issues.apache.org/jira/browse/IGNITE-8237
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration. Consider moving IGNITE_DISABLE_ONHEAP_CACHE 
> system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Commented] (IGNITE-8394) ODBC: Can not establish SSL connection to remote host.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-8394:


[~isapego], I have reviewed the changes. Generally it looks good, but I have 
concerns regarding the function {{SecureSocketClient::AsyncConnectInternal()}}.
1. The name of the function is confusing since it doesn't actually return 
control until connection is established or failure happens.
2. When it does return {{false}}, the call to {{ssl::SSL_free(sslIO)}} is 
missing.

> ODBC: Can not establish SSL connection to remote host.
> --
>
> Key: IGNITE-8394
> URL: https://issues.apache.org/jira/browse/IGNITE-8394
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc, ssl, tls
> Fix For: 2.5
>
>
> Driver connects to the local server, but when connecting to remote server 
> client sometimes returns error when trying to establish async connection, 
> though the connection established successfully, if the error is ignored.



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

[jira] [Comment Edited] (IGNITE-7823) Separate cache for non collocated IgniteSet.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-7823 at 4/26/18 4:36 PM:
---

LGTM


was (Author: alexey kuznetsov):
LBTM

> Separate cache for non collocated IgniteSet.
> 
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
>  Issue Type: New Feature
>  Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.6
>
>
> Existing collocated version of {{IgniteSet}} datastructure is good enough for 
> small sets.
> For big sets it's too expensive to maintain redundant onheap data copies. 
> Thus it would be better to use separate cache for non collocated 
> {{IgniteSet}} version. The difference between these two kinds of sets should 
> be properly documented afterwards. 



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

[jira] [Updated] (IGNITE-8394) ODBC: Can not establish SSL connection to remote host.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-8394:

Fix Version/s: (was: 2.6)
   2.5

> ODBC: Can not establish SSL connection to remote host.
> --
>
> Key: IGNITE-8394
> URL: https://issues.apache.org/jira/browse/IGNITE-8394
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc, ssl, tls
> Fix For: 2.5
>
>
> Driver connects to the local server, but when connecting to remote server 
> client sometimes returns error when trying to establish async connection, 
> though the connection established successfully, if the error is ignored.



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

[jira] [Commented] (IGNITE-7823) Separate cache for non collocated IgniteSet.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-7823:
--

LBTM

> Separate cache for non collocated IgniteSet.
> 
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
>  Issue Type: New Feature
>  Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.6
>
>
> Existing collocated version of {{IgniteSet}} datastructure is good enough for 
> small sets.
> For big sets it's too expensive to maintain redundant onheap data copies. 
> Thus it would be better to use separate cache for non collocated 
> {{IgniteSet}} version. The difference between these two kinds of sets should 
> be properly documented afterwards. 



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

[jira] [Created] (IGNITE-8404) NPE when shutting down non-initialized mapped file memory provier

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8404:


 Summary: NPE when shutting down non-initialized mapped file memory 
provier
 Key: IGNITE-8404
 URL: https://issues.apache.org/jira/browse/IGNITE-8404
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk


If a node has mapped file memory provider and node initialization fails, I get 
the following exception:
{code}
java.lang.NullPointerException
at 
org.apache.ignite.internal.mem.file.MappedFileMemoryProvider.shutdown(MappedFileMemoryProvider.java:97)
at 
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.stop(PageMemoryNoStoreImpl.java:239)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.stop0(IgniteCacheDatabaseSharedManager.java:649)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:888)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2109)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1987)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1074)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1062)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:948)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:847)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:717)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:686)
at org.apache.ignite.Ignition.start(Ignition.java:347)
at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
{code}

The cause is obvious - we try to access an uninitialized field.



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

[jira] [Commented] (IGNITE-8219) B+Tree operation may result in an infinite loop in some case

[Alexey Stelmak (JIRA)]

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

Alexey Stelmak commented on IGNITE-8219:


Fixed: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1242138=queuedBuildOverviewTab]

>  B+Tree operation may result in an infinite loop in some case
> -
>
> Key: IGNITE-8219
> URL: https://issues.apache.org/jira/browse/IGNITE-8219
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Stelmak
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.5
>
>
> B+Tree operation may result in an infinite loop in case. Test 
> DynamicIndexServerCoordinatorBasicSelfTest#testCreateIndexWithInlineSizePartitionedAtomic
>  region size = 512Mb, KEY_BEFORE=1, KEY_AFTER=2



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

[jira] [Commented] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised on-heap cache configuration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8237:


TC is OK

> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration 
> --
>
> Key: IGNITE-8237
> URL: https://issues.apache.org/jira/browse/IGNITE-8237
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration. Consider moving IGNITE_DISABLE_ONHEAP_CACHE 
> system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-8075:
--

[~ptupitsyn] Hi! Here are latest TC build results. It seems OK for me. However, 
there is one fxcop warning about too common catch and swallow exceptions in 
Dispose in TransactionCollectionImpl. I'm considering this as false positive. 
Dispose should not throw any error and I wanna dispose all transactions in any 
circumstances. Your thoughts?

> .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, 
> setTxTimeoutOnPartitionMapExchange
> 
>
> Key: IGNITE-8075
> URL: https://issues.apache.org/jira/browse/IGNITE-8075
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Alexei Scherbakov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.6
>
>
> Neet to add new methods as part of .NET API:
> org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange
>  - timeout for automatic rollback on exchange.
> org.apache.ignite.IgniteTransactions#withLabel - tx label
> org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local 
> active transactions.
> org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange
> Java implementation is currently available at a branch [1]
> [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2



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

[jira] [Commented] (IGNITE-8310) CPP: Remove strong dependency on Boost 1.58.0

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-8310:
-

[~NIzhikov], well, currently we are testing with VS2010, but we should support 
last versions as well. Is this bug affects many versions of `boost`? I'm not 
sure we want to support all of them. This seems as a boost issue to me. Maybe 
we should mention that there is an issue with this version in \{{DEVNOTES.txt}}.

> CPP: Remove strong dependency on Boost 1.58.0
> -
>
> Key: IGNITE-8310
> URL: https://issues.apache.org/jira/browse/IGNITE-8310
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc, platforms
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: boost, cpp, odbc
> Fix For: 2.6
>
>
> Currently, tests for C++ client and ODBC depend on the Boost 1.58.0. There is 
> a strong dependency on the exact version, which causes troubles for the 
> developers and which should not be there from the very beginning as we do not 
> really need some features from this particular version.



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

[jira] [Assigned] (IGNITE-8214) Web console: add validation for Persistent + Swap file for data region configuration

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8214:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master.

> Web console: add validation for Persistent + Swap file for data region 
> configuration
> 
>
> Key: IGNITE-8214
> URL: https://issues.apache.org/jira/browse/IGNITE-8214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
>
> The 'Swap file' option can be set only if 'Persistent Enable' is OFF.
> Please add corresponding validation.



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

[jira] [Commented] (IGNITE-7343) Add guard to prevent concurrent usage the JDBC thin connection

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7343:
--

[~vozerov], great comment. Thanks. Fixed at {{start}} and {{sendrRequest}} 
methods too.

> Add guard to prevent concurrent usage the JDBC thin connection
> --
>
> Key: IGNITE-7343
> URL: https://issues.apache.org/jira/browse/IGNITE-7343
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> I propose to add multi-thread guard into {{JdbcThinTcpIo#sendRequest}} method 
> to diagnostic concurrency usage of the Ignite JDBC connection. 
> The related ticket: IGNITE-7335



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

[jira] [Comment Edited] (IGNITE-7343) Add guard to prevent concurrent usage the JDBC thin connection

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-7343 at 4/26/18 3:29 PM:
---

[~vozerov], great comment. Thanks. Fixed at {{start}} and {{sendRequest}} 
methods too.


was (Author: tledkov-gridgain):
[~vozerov], great comment. Thanks. Fixed at {{start}} and {{sendrRequest}} 
methods too.

> Add guard to prevent concurrent usage the JDBC thin connection
> --
>
> Key: IGNITE-7343
> URL: https://issues.apache.org/jira/browse/IGNITE-7343
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> I propose to add multi-thread guard into {{JdbcThinTcpIo#sendRequest}} method 
> to diagnostic concurrency usage of the Ignite JDBC connection. 
> The related ticket: IGNITE-7335



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

[jira] [Updated] (IGNITE-8250) Adopt Fuzzy CMeans to PartitionedDatasets

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8250:
-
Description: Add Model/Trainer, tests, example

> Adopt Fuzzy CMeans to PartitionedDatasets
> -
>
> Key: IGNITE-8250
> URL: https://issues.apache.org/jira/browse/IGNITE-8250
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Add Model/Trainer, tests, example



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

[jira] [Resolved] (IGNITE-8168) [ML] Add KMeans version for Partitioned Datasets

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev resolved IGNITE-8168.
--
Resolution: Fixed

> [ML] Add KMeans version for Partitioned Datasets
> 
>
> Key: IGNITE-8168
> URL: https://issues.apache.org/jira/browse/IGNITE-8168
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Resolved] (IGNITE-8170) [ML] Adopt KMeans example to the Partitioned Dataset

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev resolved IGNITE-8170.
--
Resolution: Fixed

> [ML] Adopt KMeans example to the Partitioned Dataset
> 
>
> Key: IGNITE-8170
> URL: https://issues.apache.org/jira/browse/IGNITE-8170
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Commented] (IGNITE-8394) ODBC: Can not establish SSL connection to remote host.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-8394:
-

The issue was that when using asynchronous connection it is preferred to use 
{{SSL_connect}} instead of \{{BIO_do_connect}}. Also, it is needed to check 
return of the {{SSL_get_error_}} after connect for {{SSL_ERROR_WANT_WRITE}}, 
{{SSL_ERROR_WANT_READ}} and {{SSL_ERROR_WANT_CONNECT}} values, as they are not 
errors, but instructions on the next connection step. Weirdly enough, 
reproduced only on the remote host (maybe because of the longer network delay).

> ODBC: Can not establish SSL connection to remote host.
> --
>
> Key: IGNITE-8394
> URL: https://issues.apache.org/jira/browse/IGNITE-8394
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc, ssl, tls
> Fix For: 2.6
>
>
> Driver connects to the local server, but when connecting to remote server 
> client sometimes returns error when trying to establish async connection, 
> though the connection established successfully, if the error is ignored.



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

[jira] [Resolved] (IGNITE-6969) Move constants with influence on performance to separate config

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev resolved IGNITE-6969.
--
Resolution: Not A Problem

There is no such constants and problems in current version of source code

> Move constants with influence on performance to separate config
> ---
>
> Key: IGNITE-6969
> URL: https://issues.apache.org/jira/browse/IGNITE-6969
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Minor
>
> Move constants like BLOCK_SIZE in block matrix and block vector to a separate 
> config.
> Also a few constants in Decision Trees can be placed there.
> Motivation: Developer can tune this parameters to increase throughput.
> Comment: We need more detailed review to find other constants which can be 
> changed or override by developers. Please add them in comments



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

[jira] [Resolved] (IGNITE-6968) Move similar Cache configurations in matrices and models to one Java or XML config

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev resolved IGNITE-6968.
--
Resolution: Not A Problem

Currently it's not a problem.

> Move similar Cache configurations in matrices and models to one Java or XML 
> config
> --
>
> Key: IGNITE-6968
> URL: https://issues.apache.org/jira/browse/IGNITE-6968
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> There are a lot of copy-paste cache configs in matrices and vectors in method 
> newCache() which returns configured cache for different data structures
> For example
> * SparseDistributedMatrixStorage
> * BlockVectorStorage
> * BlockMatrixStorage
> * SplitCache
> * FeatureCache
> * ProjectionCache
> * SparseDistributedVectorStorage
> and others
> Also, all strategies of cache usage should be documented better (with 
> description of choosing one or another parameter value)



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

[jira] [Assigned] (IGNITE-8215) Web console: some fields are not generated

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8215:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good for me. Merged to master.

> Web console: some fields are not generated
> --
>
> Key: IGNITE-8215
> URL: https://issues.apache.org/jira/browse/IGNITE-8215
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
>
> Data Region Configuration 
> - Metrics sub interval count
> - Metrics rate time interval
> Discovery
> - Max heartbeats miss w/o init:
> - Max missed client heartbeats



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

[jira] [Updated] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8403:
-
Description: 
Add binary logistic regression implementation based on partitioned dataset and 
MLP(Multi-layered perceptron) architecture with SGD (Stochastic Gradient 
Descent).

Provide test, example, model and trainer

  was:Add binary logistic regression implementation based on partitioned 
datasets and MLP with SGD


> [ML] Add Binary Logistic Regression based on partitioned datasets and MLP
> -
>
> Key: IGNITE-8403
> URL: https://issues.apache.org/jira/browse/IGNITE-8403
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Add binary logistic regression implementation based on partitioned dataset 
> and MLP(Multi-layered perceptron) architecture with SGD (Stochastic Gradient 
> Descent).
> Provide test, example, model and trainer



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

[jira] [Assigned] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-8393:
--

Assignee: Ivan Rakov

>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
> 2018-04-26 11:35:25.391 [INFO 
> ][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed 
> class: GridDeployment [ts=1524730971870, depMode=SHARED, 
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
>  clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
>  pendingUndeploy=false, undeployed=true, usage=0]
> 2018-04-26 11:35:25.400 [INFO 
> ][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
> We should softly handle this situation: print message in log and continue the 
> compression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Comment Edited] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev edited comment on IGNITE-8403 at 4/26/18 3:00 PM:
---

IGNITE-5059 is out of date and more than year there is no commits. The new 
architecture with MLP + Partitoned Dataset was added and that implementation on 
the new architecture is very simple


was (Author: zaleslaw):
IGNITE-5059 is out of date and more than year there is no commits. We added new 
architecture MLP + Partitoned Dataset and need fast implementation on the new 
architecture

> [ML] Add Binary Logistic Regression based on partitioned datasets and MLP
> -
>
> Key: IGNITE-8403
> URL: https://issues.apache.org/jira/browse/IGNITE-8403
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Add binary logistic regression implementation based on partitioned datasets 
> and MLP with SGD



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

[jira] [Updated] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8403:
-
Description: Add binary logistic regression implementation based on 
partitioned datasets and MLP with SGD

> [ML] Add Binary Logistic Regression based on partitioned datasets and MLP
> -
>
> Key: IGNITE-8403
> URL: https://issues.apache.org/jira/browse/IGNITE-8403
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Add binary logistic regression implementation based on partitioned datasets 
> and MLP with SGD



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

[jira] [Commented] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev commented on IGNITE-8403:
--

IGNITE-5059 is out of date and more than year there is no commits. We added new 
architecture MLP + Partitoned Dataset and need fast implementation on the new 
architecture

> [ML] Add Binary Logistic Regression based on partitioned datasets and MLP
> -
>
> Key: IGNITE-8403
> URL: https://issues.apache.org/jira/browse/IGNITE-8403
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Commented] (IGNITE-8295) Possible deadlock on partition eviction.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8295:


Github user AMashenkov closed the pull request at:

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


> Possible deadlock on partition eviction.
> 
>
> Key: IGNITE-8295
> URL: https://issues.apache.org/jira/browse/IGNITE-8295
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.6
>
> Attachments: deadlock.stack
>
>
> GridCacheOffheapManager.recreateCacheDataStore() calls 
> updatePartitionCounter() under partStoreLock which may try to acquire 
> checkpointReadLock.
> recreateCacheDataStore() method can be called with checkpointReadLock (on 
> GridDhtPartitionsExchangeFuture.updatePartitionFullMap) 
> or without checkpointReadLock (GridDhtPartitionEvictor thread calls 
> evictPartitionAsync),
> So, checkpoint can cause a deadlock if it happens in between.
> Seems, we should acquire checkpointReadLock before partStoreLock. 
>   



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

[jira] [Assigned] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6937:
---

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

> SQL TX: Support SELECT FOR UPDATE
> -
>
> Key: IGNITE-6937
> URL: https://issues.apache.org/jira/browse/IGNITE-6937
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> Normally in SQL world readers do not block writers. This is how our SELECT 
> operations should work by default. But we need to add a support for {{SELECT 
> ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 
> In this mode we lock entries as usual, but then send data back to the caller. 
> First page can be returned directly in our {{LockResponse}}. Next pages 
> should be requested in separate requests. With this approach {{SELECT ,,, FOR 
> UPDATE}} will require only single round-trip to both lock and read data in 
> case of small updates.
> Update {{SELECT}} statement syntax once this feature is supported:
> https://apacheignite-sql.readme.io/docs/select



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

[jira] [Assigned] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6937:
---

Assignee: Vladimir Ozerov  (was: Alexander Paschenko)

> SQL TX: Support SELECT FOR UPDATE
> -
>
> Key: IGNITE-6937
> URL: https://issues.apache.org/jira/browse/IGNITE-6937
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> Normally in SQL world readers do not block writers. This is how our SELECT 
> operations should work by default. But we need to add a support for {{SELECT 
> ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 
> In this mode we lock entries as usual, but then send data back to the caller. 
> First page can be returned directly in our {{LockResponse}}. Next pages 
> should be requested in separate requests. With this approach {{SELECT ,,, FOR 
> UPDATE}} will require only single round-trip to both lock and read data in 
> case of small updates.
> Update {{SELECT}} statement syntax once this feature is supported:
> https://apacheignite-sql.readme.io/docs/select



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

[jira] [Commented] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6937:
-

[~al.psc], my comments:
1) {{GridCacheMapEntry}} - my preference would be to avoid duplicated logic in 
lock method and callback. Looks like common method could be implemented for 
both scenarios - callback should simply delegate to lock method
2) {{GridDhtTransactionalCacheAdapter}} - why did we remove exception handling? 
I understand that {{IgniteCheckedException}} is never throws, but shouldn't we 
catch all exceptions instead of ignoring all of them?
3) {{GridCacheOperation}} - new member should be in the end of the list
4) {{GridH2QueryRequest}} - embedding enlist request with almost all the same 
fields is definitely not a good idea. Please suggest a design without 
duplicated data being sent over the wire.
5) {{GridReduceQueryExecutor}} - lines 604 and 607 - why do we call it twice?
6) {{GridMapQueryExecutor.txLockMsgLog}} - dead code?
7) {{GridMapQueryExecutor:751}} - can we perform rewrite only once on reducer 
node instead of doing it multiple times on map nodes?
8) {{QueryPageEnlistFutureSupplier}} - please avoid C1 and anonymous classes
9) {{GridMapQueryExecutor#sendNextPage}} - is it ok that we call {{fut.init()}} 
on every call this method? Looks wrong to me. Do we have tests for multi-page 
query?
10) Looking at amount of code changes on reducer side I doubt that assembling 
everything on reducer side was correct decision. It seems that we'd better to 
process everything on mapper side and return the very first page when 
everything is already locked. In fact, we already work this way - in non-lazy 
mode H2 moves everything to local heap result set first, and in current 
implementation lazy flag is prohibited explicitly for SFU. Can we simply do the 
following:
- Execute the request
- Extract result from {{ResultSet}} which always would be heap-based 
{{org.h2.result.LocalResult}}
- Lock these entries
- Send results in pages cutting {{_KEY}} column
It seems that with this approach significant amount of complexity would go away.
11) {{CacheMvccSelectForUpdateQueryTest}} - tests do not work (hang)

> SQL TX: Support SELECT FOR UPDATE
> -
>
> Key: IGNITE-6937
> URL: https://issues.apache.org/jira/browse/IGNITE-6937
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> Normally in SQL world readers do not block writers. This is how our SELECT 
> operations should work by default. But we need to add a support for {{SELECT 
> ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 
> In this mode we lock entries as usual, but then send data back to the caller. 
> First page can be returned directly in our {{LockResponse}}. Next pages 
> should be requested in separate requests. With this approach {{SELECT ,,, FOR 
> UPDATE}} will require only single round-trip to both lock and read data in 
> case of small updates.
> Update {{SELECT}} statement syntax once this feature is supported:
> https://apacheignite-sql.readme.io/docs/select



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

[jira] [Comment Edited] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-6937 at 4/26/18 2:45 PM:
--

[~al.psc], my comments:
1) {{GridCacheMapEntry}} - my preference would be to avoid duplicated logic in 
lock method and callback. Looks like common method could be implemented for 
both scenarios - callback should simply delegate to lock method
2) {{GridDhtTransactionalCacheAdapter}} - why did we remove exception handling? 
I understand that {{IgniteCheckedException}} is never throws, but shouldn't we 
catch all exceptions instead of ignoring all of them?
3) {{GridCacheOperation}} - new member should be in the end of the list
4) {{GridH2QueryRequest}} - embedding enlist request with almost all the same 
fields is definitely not a good idea. Please suggest a design without 
duplicated data being sent over the wire.
5) {{GridReduceQueryExecutor}} - lines 604 and 607 - why do we call it twice?
6) {{GridMapQueryExecutor.txLockMsgLog}} - dead code?
7) {{GridMapQueryExecutor:751}} - can we perform rewrite only once on reducer 
node instead of doing it multiple times on map nodes?
8) {{QueryPageEnlistFutureSupplier}} - please avoid C1 and anonymous classes
9) {{GridMapQueryExecutor#sendNextPage}} - is it ok that we call {{fut.init()}} 
on every call this method? Looks wrong to me. Do we have tests for multi-page 
query?
10) Looking at amount of code changes on reducer side I doubt that assembling 
everything on reducer side was correct decision. It seems that we'd better to 
process everything on mapper side and return the very first page when 
everything is already locked. In fact, we already work this way - in non-lazy 
mode H2 moves everything to local heap result set first, and in current 
implementation lazy flag is prohibited explicitly for SFU. Can we simply do the 
following:
- Execute the request
- Extract result from {{ResultSet}} which always would be heap-based 
{{org.h2.result.LocalResult}}
- Lock these entries
- Send results in pages cutting {{_KEY}} column
It seems that with this approach significant amount of complexity would go away.

11) {{CacheMvccSelectForUpdateQueryTest}} - tests do not work (hang)


was (Author: vozerov):
[~al.psc], my comments:
1) {{GridCacheMapEntry}} - my preference would be to avoid duplicated logic in 
lock method and callback. Looks like common method could be implemented for 
both scenarios - callback should simply delegate to lock method
2) {{GridDhtTransactionalCacheAdapter}} - why did we remove exception handling? 
I understand that {{IgniteCheckedException}} is never throws, but shouldn't we 
catch all exceptions instead of ignoring all of them?
3) {{GridCacheOperation}} - new member should be in the end of the list
4) {{GridH2QueryRequest}} - embedding enlist request with almost all the same 
fields is definitely not a good idea. Please suggest a design without 
duplicated data being sent over the wire.
5) {{GridReduceQueryExecutor}} - lines 604 and 607 - why do we call it twice?
6) {{GridMapQueryExecutor.txLockMsgLog}} - dead code?
7) {{GridMapQueryExecutor:751}} - can we perform rewrite only once on reducer 
node instead of doing it multiple times on map nodes?
8) {{QueryPageEnlistFutureSupplier}} - please avoid C1 and anonymous classes
9) {{GridMapQueryExecutor#sendNextPage}} - is it ok that we call {{fut.init()}} 
on every call this method? Looks wrong to me. Do we have tests for multi-page 
query?
10) Looking at amount of code changes on reducer side I doubt that assembling 
everything on reducer side was correct decision. It seems that we'd better to 
process everything on mapper side and return the very first page when 
everything is already locked. In fact, we already work this way - in non-lazy 
mode H2 moves everything to local heap result set first, and in current 
implementation lazy flag is prohibited explicitly for SFU. Can we simply do the 
following:
- Execute the request
- Extract result from {{ResultSet}} which always would be heap-based 
{{org.h2.result.LocalResult}}
- Lock these entries
- Send results in pages cutting {{_KEY}} column
It seems that with this approach significant amount of complexity would go away.
11) {{CacheMvccSelectForUpdateQueryTest}} - tests do not work (hang)

> SQL TX: Support SELECT FOR UPDATE
> -
>
> Key: IGNITE-6937
> URL: https://issues.apache.org/jira/browse/IGNITE-6937
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> Normally in SQL world readers do not block writers. This is how our SELECT 
> operations should work by default. But we need to add a 

[jira] [Assigned] (IGNITE-7926) Web console: demo faled to start under java 9

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7926:


Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

> Web console: demo faled to start under java 9
> -
>
> Key: IGNITE-7926
> URL: https://issues.apache.org/jira/browse/IGNITE-7926
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Minor
> Fix For: 2.6
>
>
> We need to add support for Java 9 to web console demo.



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

[jira] [Commented] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov commented on IGNITE-7986:
--

[~dpavlov] Done.

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Fix For: 2.6
>
> Attachments: GridPartitionStateMapBench.java, fullResult.txt
>
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



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

[jira] [Commented] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8403:


Please fill ticket description, so community members could easily understand 
what is to be changed

> [ML] Add Binary Logistic Regression based on partitioned datasets and MLP
> -
>
> Key: IGNITE-8403
> URL: https://issues.apache.org/jira/browse/IGNITE-8403
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-7683) ContinuousQueryWithTransformer needs to be documented

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-7683:
---

Assignee: Denis Magda  (was: Nikolay Izhikov)

> ContinuousQueryWithTransformer needs to be documented
> -
>
> Key: IGNITE-7683
> URL: https://issues.apache.org/jira/browse/IGNITE-7683
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.5
>
>
> New API - ContinuousQueryWithTransformer should be documented.



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

[jira] [Commented] (IGNITE-7683) ContinuousQueryWithTransformer needs to be documented

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7683:
-

[~dmagda] 

1. I made a clone of ContinuousQuery page.
2. I made a paragraph about ContinuousQueryWithTransformer [1].

Please, take a look.

[1] 
https://apacheignite.readme.io/v2.4/docs/continuous-queries-25#section-remote-transformer

> ContinuousQueryWithTransformer needs to be documented
> -
>
> Key: IGNITE-7683
> URL: https://issues.apache.org/jira/browse/IGNITE-7683
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> New API - ContinuousQueryWithTransformer should be documented.



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

[jira] [Updated] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8393:
---
Description: 
In WAL segment compression fails with exception, FileCompressed will print 
errors in endless loop without any progress:

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]

We should softly handle this situation: print message in log and continue the 
compression with next segment.
We also should handle "skipped" segments and don't delete them in 
deleteObsoleteRawSegments().

  was:
In WAL segment compression fails with exception, FileCompressed will print 
errors in endless loop without any progress:

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]

We should softly handle this situation: print message in log and continue the 
compression with next segment.


>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Priority: Critical
>  Labels: WAL
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
>   at 
> 

[jira] [Updated] (IGNITE-8402) Long running transaction JMX

[Ivan Kapralov (JIRA)]

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

Ivan Kapralov updated IGNITE-8402:
--
Description: 
Facing necessity in Long Running Transactions JMX metric implementation.

Needed: transaction start time, node ID, duration, cache full qualified name, 
originator ID.

 

  was:
Facing necessity in Long Running Transactions JMX metric implementation.

Needed: transaction start time, node ID, duration, cache ID, originator ID 
comma separated in the same string. Info about transactions that are hung up 
for more than 600 sec.

 


> Long running transaction JMX
> 
>
> Key: IGNITE-8402
> URL: https://issues.apache.org/jira/browse/IGNITE-8402
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Ivan Kapralov
>Priority: Major
> Fix For: None
>
>
> Facing necessity in Long Running Transactions JMX metric implementation.
> Needed: transaction start time, node ID, duration, cache full qualified name, 
> originator ID.
>  



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

[jira] [Updated] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8393:
---
Description: 
In WAL segment compression fails with exception, FileCompressed will print 
errors in endless loop without any progress:

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]

We should softly handle this situation: print message in log and continue the 
compression with next segment.

  was:
In WAL segment compression fails with 

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
...
2018-04-26 11:40:00.004 [ERROR][RMI TCP 
Connection(276)-10.116.206.1][com.sbt.dpl.gridgain.mbean.GridNode] Не удалось 
определить общее количество узлов. Сброшен флаг доступности.
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=DPL_GRID%DplGridNodeName, state=STOPPED]


>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Priority: Critical
>  Labels: WAL
>
> In WAL segment compression fails with exception, FileCompressed will print 
> errors in endless loop without any progress:
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> 

[jira] [Commented] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8403:


GitHub user zaleslaw opened a pull request:

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

IGNITE-8403: Added Logistic Regression

Also fixed a few examples with out-of-date information

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

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

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

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


commit d60ace95c3b6bc24b0d5087962ac18a4c1613a16
Author: zaleslaw 
Date:   2018-04-19T16:09:01Z

LogRegression

commit d98b122cca699dd91378b784e1aad85d8afaef84
Author: zaleslaw 
Date:   2018-04-26T14:12:59Z

Fixed LogRegression and added tests

commit 4b628f8f6b40e1b1cd514232bd553f92037a2ea2
Author: zaleslaw 
Date:   2018-04-26T14:15:10Z

Merge branch 'master' into ignite-8403




> [ML] Add Binary Logistic Regression based on partitioned datasets and MLP
> -
>
> Key: IGNITE-8403
> URL: https://issues.apache.org/jira/browse/IGNITE-8403
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Commented] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7986:


[~VitaliyB] please merge conflicts. Currently I can't run plugin tests with 
this change

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Fix For: 2.6
>
> Attachments: GridPartitionStateMapBench.java, fullResult.txt
>
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



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

[jira] [Updated] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8393:
---
Description: 
In WAL segment compression fails with 

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
...
2018-04-26 11:40:00.004 [ERROR][RMI TCP 
Connection(276)-10.116.206.1][com.sbt.dpl.gridgain.mbean.GridNode] Не удалось 
определить общее количество узлов. Сброшен флаг доступности.
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=DPL_GRID%DplGridNodeName, state=STOPPED]

  was:
In case one of WAL segments 

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
...
2018-04-26 11:40:00.004 [ERROR][RMI TCP 
Connection(276)-10.116.206.1][com.sbt.dpl.gridgain.mbean.GridNode] Не удалось 
определить общее количество узлов. Сброшен флаг доступности.
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=DPL_GRID%DplGridNodeName, state=STOPPED]


>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Priority: Critical
>  Labels: WAL
>
> In WAL segment compression fails with 
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> 

[jira] [Updated] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-8393:
---
Description: 
In case one of WAL segments 

2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
...
2018-04-26 11:40:00.004 [ERROR][RMI TCP 
Connection(276)-10.116.206.1][com.sbt.dpl.gridgain.mbean.GridNode] Не удалось 
определить общее количество узлов. Сброшен флаг доступности.
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=DPL_GRID%DplGridNodeName, state=STOPPED]

  was:
2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
...
2018-04-26 11:40:00.004 [ERROR][RMI TCP 
Connection(276)-10.116.206.1][com.sbt.dpl.gridgain.mbean.GridNode] Не удалось 
определить общее количество узлов. Сброшен флаг доступности.
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=DPL_GRID%DplGridNodeName, state=STOPPED]


>  Unexpected error during WAL compression java.io.EOFException: EOF at 
> position [0] expected to read [29] bytes
> --
>
> Key: IGNITE-8393
> URL: https://issues.apache.org/jira/browse/IGNITE-8393
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Filatov
>Priority: Critical
>  Labels: WAL
>
> In case one of WAL segments 
> 2018-04-26 11:35:25.152 
> [ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Unexpected error during WAL compression
> java.io.EOFException: EOF at position [0] expected to read [29] bytes
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
>    at 
> 

[jira] [Created] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8403:


 Summary: [ML] Add Binary Logistic Regression based on partitioned 
datasets and MLP
 Key: IGNITE-8403
 URL: https://issues.apache.org/jira/browse/IGNITE-8403
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Created] (IGNITE-8402) Long running transaction JMX

[Ivan Kapralov (JIRA)]

Ivan Kapralov created IGNITE-8402:
-

 Summary: Long running transaction JMX
 Key: IGNITE-8402
 URL: https://issues.apache.org/jira/browse/IGNITE-8402
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.4
Reporter: Ivan Kapralov
 Fix For: None


Facing necessity in Long Running Transactions JMX metric implementation.

Needed: transaction start time, node ID, duration, cache ID, originator ID 
comma separated in the same string. Info about transactions that are hung up 
for more than 600 sec.

 



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

[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8286:
--

[~roman_s], I think that instead of returning an empty result set, we must 
thrown an exception explaining that local flag was set to true, but partition 
could not be found on node. In this case a user can take an action and remap 
the query. If we return an empty iterator, there is no way to distinguish 
between an actually empty partition and a partition that was moved to another 
node.

> ScanQuery ignore setLocal with non local partition
> --
>
> Key: IGNITE-8286
> URL: https://issues.apache.org/jira/browse/IGNITE-8286
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.6
>
>
> 1) Create partitioned cache on 2+ nodes cluster
> 2) Select some partition N, local node should not be OWNER of partition N
> 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N))
> Expected result:
> empty result (probaply with logging smth like "Trying to execute local query 
>  with non local partition N") or even throw exception
> Actual result:
> executing (with ScanQueryFallbackClosableIterator) query on remote node.
> Problem is that we execute local query on remote node.
> Same behaviour can be achieved if we get empty node list from 
> GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" 
> query from non data node from given cache (see 
> GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in 
> GridcacheQueryAdapter.executeScanQuery()



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

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] please review proposed change.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



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

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6528:


GitHub user alamar opened a pull request:

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

IGNITE-6528 Print warnings when actual data type not equal to expected 
Indexed Type.



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

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

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

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


commit 925ad48468f82053005031f3b5b5eca85323b019
Author: Ilya Kasnacheev 
Date:   2018-04-26T13:40:27Z

IGNITE-6528 Print warnings when actual data type not equal to expected 
Indexed Type.




> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8400:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8400 IgniteTopologyValidatorGridSplitCacheTest.testTopologyVal…

…idatorWithCacheGroup node failure fix

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

$ git pull https://github.com/alex-plekhanov/ignite ignite-8400

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

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


commit 7c68ac55dd9ec9957b7bf0769811ee7a0663325a
Author: Aleksey Plekhanov 
Date:   2018-04-26T13:27:51Z

IGNITE-8400 
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup 
node failure fix (50 times)




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



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

[jira] [Commented] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised on-heap cache configuration

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8237:
--

Changes look good to me given that TC passes.

> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration 
> --
>
> Key: IGNITE-8237
> URL: https://issues.apache.org/jira/browse/IGNITE-8237
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite blocks on SecurityException in exchange-worker due to unauthorised 
> on-heap cache configuration. Consider moving IGNITE_DISABLE_ONHEAP_CACHE 
> system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Commented] (IGNITE-8390) WAL historical rebalance is not able to process cache.remove() updates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8390:


Github user asfgit closed the pull request at:

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


> WAL historical rebalance is not able to process cache.remove() updates
> --
>
> Key: IGNITE-8390
> URL: https://issues.apache.org/jira/browse/IGNITE-8390
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Blocker
> Fix For: 2.5
>
>
> WAL historical rebalance fails on supplier when process entry remove with 
> following assertion:
> {noformat}
> java.lang.AssertionError: GridCacheEntryInfo [key=KeyCacheObjectImpl 
> [part=-1, val=2, hasValBytes=true], cacheId=94416770, val=null, ttl=0, 
> expireTime=0, ver=GridCacheVersion [topVer=136155335, order=1524675346187, 
> nodeOrder=1], isNew=false, deleted=false]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplyMessage.addEntry0(GridDhtPartitionSupplyMessage.java:220)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:381)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:379)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Obviously this assertion will work correctly only for full rebalance. We 
> should either soft assertion for historical rebalance case or disable it.
> In case of disabled assertion everything works well and rebalance finished 
> properly.



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

[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7993:


Hi [~guseinov], there is several suspicious tests, so I've retriggered these 
suites.

ZK is defenetely not related to fix.

> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped 
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following 
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid 
> stripedPool thread pool size (must be greater than 0), actual value: 0
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   ... 7 more
> {noformat}



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

[jira] [Commented] (IGNITE-8310) CPP: Remove strong dependency on Boost 1.58.0

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8310:
-

Hello, [~isapego].

I found that in the latest Visual Studio 2017 there are some break changes.
They are leads to different issues with boost. 
[1], for example

Can you give me an advice?
What is target visual studio version we have to support?

[1] https://github.com/Microsoft/vcpkg/issues/2444 

> CPP: Remove strong dependency on Boost 1.58.0
> -
>
> Key: IGNITE-8310
> URL: https://issues.apache.org/jira/browse/IGNITE-8310
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc, platforms
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: boost, cpp, odbc
> Fix For: 2.6
>
>
> Currently, tests for C++ client and ODBC depend on the Boost 1.58.0. There is 
> a strong dependency on the exact version, which causes troubles for the 
> developers and which should not be there from the very beginning as we do not 
> really need some features from this particular version.



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

[jira] [Updated] (IGNITE-8401) Assertion error ocurred in JettyRestProcessorAuthenticationWithCredsSelfTest

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8401:
---
Issue Type: Test  (was: Improvement)

> Assertion error ocurred in JettyRestProcessorAuthenticationWithCredsSelfTest
> 
>
> Key: IGNITE-8401
> URL: https://issues.apache.org/jira/browse/IGNITE-8401
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Stanilovsky Evgeny
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> Following tests began to fail after merge 
> https://issues.apache.org/jira/browse/IGNITE-8066
> with assertion added in this ticket.
> *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithCredsSelfTest.testDeactivateActivate[ 
> (fail rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2035731000398727816=%3Cdefault%3E=testDetails]*
>       *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithCredsSelfTest.testRemove[ (fail rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5513793448643455005=%3Cdefault%3E=testDetails]*
>       *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithCredsSelfTest.testRemoveAll[ (fail rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1721357182035817455=%3Cdefault%3E=testDetails]*
>       *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithCredsSelfTest.testVisorGateway[ (fail 
> rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2028785123619746743=%3Cdefault%3E=testDetails]*
>       *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithTokenSelfTest.testDeactivateActivate[ 
> (fail rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-334626288130660999=%3Cdefault%3E=testDetails]*
>       *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithTokenSelfTest.testRemove[ (fail rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5504915680838168777=%3Cdefault%3E=testDetails]*
>       *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithTokenSelfTest.testRemoveAll[ (fail rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1220211038727255366=%3Cdefault%3E=testDetails]*
>  
> *IgniteClientTestSuite: 
> JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway[ (fail 
> rate 
> 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2613252696282859254=%3Cdefault%3E=testDetails]*
>  



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

[jira] [Created] (IGNITE-8401) Assertion error ocurred in JettyRestProcessorAuthenticationWithCredsSelfTest

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8401:
--

 Summary: Assertion error ocurred in 
JettyRestProcessorAuthenticationWithCredsSelfTest
 Key: IGNITE-8401
 URL: https://issues.apache.org/jira/browse/IGNITE-8401
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Stanilovsky Evgeny


Following tests began to fail after merge 

https://issues.apache.org/jira/browse/IGNITE-8066

with assertion added in this ticket.

*IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testDeactivateActivate[ (fail 
rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2035731000398727816=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testRemove[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5513793448643455005=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testRemoveAll[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1721357182035817455=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testVisorGateway[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2028785123619746743=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testDeactivateActivate[ (fail 
rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-334626288130660999=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testRemove[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5504915680838168777=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testRemoveAll[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1220211038727255366=%3Cdefault%3E=testDetails]*
 
*IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2613252696282859254=%3Cdefault%3E=testDetails]*
 



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

[jira] [Commented] (IGNITE-8390) WAL historical rebalance is not able to process cache.remove() updates

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8390:
--

Looks good to me.

> WAL historical rebalance is not able to process cache.remove() updates
> --
>
> Key: IGNITE-8390
> URL: https://issues.apache.org/jira/browse/IGNITE-8390
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Blocker
> Fix For: 2.5
>
>
> WAL historical rebalance fails on supplier when process entry remove with 
> following assertion:
> {noformat}
> java.lang.AssertionError: GridCacheEntryInfo [key=KeyCacheObjectImpl 
> [part=-1, val=2, hasValBytes=true], cacheId=94416770, val=null, ttl=0, 
> expireTime=0, ver=GridCacheVersion [topVer=136155335, order=1524675346187, 
> nodeOrder=1], isNew=false, deleted=false]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplyMessage.addEntry0(GridDhtPartitionSupplyMessage.java:220)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:381)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:379)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Obviously this assertion will work correctly only for full rebalance. We 
> should either soft assertion for historical rebalance case or disable it.
> In case of disabled assertion everything works well and rebalance finished 
> properly.



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

[jira] [Commented] (IGNITE-6140) JDBC thin: implement DataSource interface

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6140:
--

[~vozerov] URL composing is reverted.

> JDBC thin: implement DataSource interface
> -
>
> Key: IGNITE-6140
> URL: https://issues.apache.org/jira/browse/IGNITE-6140
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> Implemented {{DataSource}} interface is required for JDBC compliance.
> Also it us useful for external connection pool implementation.



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

[jira] [Updated] (IGNITE-8399) Add documentation for SVM Binary and Multi-class classification (release 2.5)

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8399:
-
Summary: Add documentation for SVM Binary and Multi-class classification 
(release 2.5)  (was: Add documentation for kNN classification (release 2.5))

> Add documentation for SVM Binary and Multi-class classification (release 2.5)
> -
>
> Key: IGNITE-8399
> URL: https://issues.apache.org/jira/browse/IGNITE-8399
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> In Apache Ignite 2.5 we have added a SVM Binary and Multi-class 
> classification working on top of partition based dataset and now we need to 
> update documentation for this feature.
> Add page [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-25]
> Add page 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-multi-class-classification-25]
>  
>  



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

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

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-8400:
-

 Summary: Flaky failure of 
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup 
(Grid is in invalid state)
 Key: IGNITE-8400
 URL: https://issues.apache.org/jira/browse/IGNITE-8400
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov


Test fails sometimes on TeamCity with exception:

{noformat}
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=cache.IgniteTopologyValidatorGridSplitCacheTest6, 
state=STOPPED]
{noformat}

Before this exception node is dropped out of topology by coordinator:

{noformat}
[tcp-disco-msg-worker-#7831%cache.IgniteTopologyValidatorGridSplitCacheTest6%][IgniteCacheTopologySplitAbstractTest$SplitTcpDiscoverySpi]
 Node is out of topology (probably, due to short-time network problems).
{noformat}




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

[jira] [Created] (IGNITE-8399) Add documentation for kNN classification (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8399:


 Summary: Add documentation for kNN classification (release 2.5)
 Key: IGNITE-8399
 URL: https://issues.apache.org/jira/browse/IGNITE-8399
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have added a SVM Binary and Multi-class classification 
working on top of partition based dataset and now we need to update 
documentation for this feature.

Add page [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-25]

Add page 
[https://dash.readme.io/project/apacheignite/v2.4/docs/svm-multi-class-classification-25]

 

 



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

[jira] [Created] (IGNITE-8398) Update documentation for KMeans clustering (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8398:


 Summary: Update documentation for KMeans clustering (release 2.5)
 Key: IGNITE-8398
 URL: https://issues.apache.org/jira/browse/IGNITE-8398
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have changed a kMeans clustering and remove FuzzyCMeans 
working on top of partition based dataset and now we need to update 
documentation for this feature.

 

Previous version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering]

update with

New version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering-25]

 

IMPORTANT: Remove page 
[https://dash.readme.io/project/apacheignite/v2.4/docs/fuzzy-c-means-clustering]

 



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

[jira] [Commented] (IGNITE-7806) SQL TX: Backup update protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7806:
-

[~rkondakov],
1) GridCacheMapEntry.allVersionsInfo - appears to be wrong to me, because you 
set ttl, expireTime, ver, new and deleted flags from current entry, rather than 
specific version. All infos would have the same values of these properties. If 
these values are not needed fo MVCC case, may be it makes sense to introduce 
separate value object to transfer them? Or may be it doesn't make sense because 
AFAIK we are going to remove force keys request altogether soon. 
2) Message content looks less than optimal to me. Specifically:
- {{GridDhtTxQueryEnlistResponse}} may omit {{lockVer}} as it is already 
available on primary node
- after the first batch was sent to backup, there is no need to populate full 
{{GridDhtTxQueryEnlistRequest}} on next attempts - we only need to pass 
{{batchId}}, {{keys}}, {{vals}] and {{op}}, right?
3) {{GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest0}} - does 
it make sense to group key-value pairs by partitions to minimize number of 
reservations? 

> SQL TX: Backup update protocol
> --
>
> Key: IGNITE-7806
> URL: https://issues.apache.org/jira/browse/IGNITE-7806
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> Currently TX SQL protocol works as follows:
> 1) Lock request is sent to {{PRIMARY}} node where updates are applied 
> immediately.
> 2) Updated values are stored in-memory
> 3) When commit command is issued, updates are propagated to {{BACKUP}}s.
> This requires data to be stored in memory at some point. We should design 
> better protocol which will allow for updates to be propagated to backups 
> efficiently.
> Ticket is related (or may be even duplicates) to IGNITE-7186.



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

[jira] [Comment Edited] (IGNITE-7806) SQL TX: Backup update protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-7806 at 4/26/18 11:56 AM:
---

[~rkondakov],
1) GridCacheMapEntry.allVersionsInfo - appears to be wrong to me, because you 
set ttl, expireTime, ver, new and deleted flags from current entry, rather than 
specific version. All infos would have the same values of these properties. If 
these values are not needed fo MVCC case, may be it makes sense to introduce 
separate value object to transfer them? Or may be it doesn't make sense because 
AFAIK we are going to remove force keys request altogether soon. 
2) Message content looks less than optimal to me. Specifically:
- {{GridDhtTxQueryEnlistResponse}} may omit {{lockVer}} as it is already 
available on primary node
- after the first batch was sent to backup, there is no need to populate full 
{{GridDhtTxQueryEnlistRequest}} on next attempts - we only need to pass 
{{batchId}}, {{keys}}, {{vals}] and {{op}}, right?

3) {{GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest0}} - does 
it make sense to group key-value pairs by partitions to minimize number of 
reservations? 


was (Author: vozerov):
[~rkondakov],
1) GridCacheMapEntry.allVersionsInfo - appears to be wrong to me, because you 
set ttl, expireTime, ver, new and deleted flags from current entry, rather than 
specific version. All infos would have the same values of these properties. If 
these values are not needed fo MVCC case, may be it makes sense to introduce 
separate value object to transfer them? Or may be it doesn't make sense because 
AFAIK we are going to remove force keys request altogether soon. 
2) Message content looks less than optimal to me. Specifically:
- {{GridDhtTxQueryEnlistResponse}} may omit {{lockVer}} as it is already 
available on primary node
- after the first batch was sent to backup, there is no need to populate full 
{{GridDhtTxQueryEnlistRequest}} on next attempts - we only need to pass 
{{batchId}}, {{keys}}, {{vals}] and {{op}}, right?
3) {{GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest0}} - does 
it make sense to group key-value pairs by partitions to minimize number of 
reservations? 

> SQL TX: Backup update protocol
> --
>
> Key: IGNITE-7806
> URL: https://issues.apache.org/jira/browse/IGNITE-7806
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> Currently TX SQL protocol works as follows:
> 1) Lock request is sent to {{PRIMARY}} node where updates are applied 
> immediately.
> 2) Updated values are stored in-memory
> 3) When commit command is issued, updates are propagated to {{BACKUP}}s.
> This requires data to be stored in memory at some point. We should design 
> better protocol which will allow for updates to be propagated to backups 
> efficiently.
> Ticket is related (or may be even duplicates) to IGNITE-7186.



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

[jira] [Updated] (IGNITE-7806) SQL TX: Backup update protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7806:

Fix Version/s: 2.6

> SQL TX: Backup update protocol
> --
>
> Key: IGNITE-7806
> URL: https://issues.apache.org/jira/browse/IGNITE-7806
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> Currently TX SQL protocol works as follows:
> 1) Lock request is sent to {{PRIMARY}} node where updates are applied 
> immediately.
> 2) Updated values are stored in-memory
> 3) When commit command is issued, updates are propagated to {{BACKUP}}s.
> This requires data to be stored in memory at some point. We should design 
> better protocol which will allow for updates to be propagated to backups 
> efficiently.
> Ticket is related (or may be even duplicates) to IGNITE-7186.



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

[jira] [Created] (IGNITE-8397) Update documentation for kNN regression (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8397:


 Summary: Update documentation for kNN regression (release 2.5)
 Key: IGNITE-8397
 URL: https://issues.apache.org/jira/browse/IGNITE-8397
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have changed a kNN regression working on top of 
partition based dataset and now we need to update documentation for this 
feature.

 

Previous version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/knn-regression]

update with

New version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-regression-25|http://example.com]



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

[jira] [Updated] (IGNITE-8396) Update documentation for kNN classification (release 2.5)

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8396:
-
Description: 
In Apache Ignite 2.5 we have changed a kNN classification working on top of 
partition based dataset and now we need to update documentation for this 
feature.

 

Previous version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/knn-classification]

update with

New version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-classification-25]

 

  was:
In Apache Ignite 2.5 we have added a normalization preprocessor working on top 
of partition based dataset and now we need to add documentation for this 
feature.

 

Previous version: 
https://dash.readme.io/project/apacheignite/v2.4/docs/knn-classification

update with

New version: 
https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-classification-25

 


> Update documentation for kNN classification (release 2.5)
> -
>
> Key: IGNITE-8396
> URL: https://issues.apache.org/jira/browse/IGNITE-8396
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> In Apache Ignite 2.5 we have changed a kNN classification working on top of 
> partition based dataset and now we need to update documentation for this 
> feature.
>  
> Previous version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/knn-classification]
> update with
> New version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-classification-25]
>  



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