[jira] [Created] (IGNITE-6670) Web console: Check demo node configuration

2017-10-18 Thread Vasiliy Sisko (JIRA)
Vasiliy Sisko created IGNITE-6670:
-

 Summary: Web console: Check demo node configuration
 Key: IGNITE-6670
 URL: https://issues.apache.org/jira/browse/IGNITE-6670
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


On start of demo the Web agent shows a lot of debug messages in log. 
Configuration should be changed to reduce information shown on start.




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


[jira] [Assigned] (IGNITE-5909) Web console: Implement editable list

2017-10-18 Thread Andrey Novikov (JIRA)

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

Andrey Novikov reassigned IGNITE-5909:
--

Assignee: Dmitriy Shabalin  (was: Andrey Novikov)

> Web console: Implement editable list
> 
>
> Key: IGNITE-5909
> URL: https://issues.apache.org/jira/browse/IGNITE-5909
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>




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


[jira] [Commented] (IGNITE-5909) Web console: Implement editable list

2017-10-18 Thread Andrey Novikov (JIRA)

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

Andrey Novikov commented on IGNITE-5909:


Reviewed. Please resolve notes 
https://reviews.ignite.apache.org/apache-ignite/review/IG-CR-17

> Web console: Implement editable list
> 
>
> Key: IGNITE-5909
> URL: https://issues.apache.org/jira/browse/IGNITE-5909
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>




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


[jira] [Updated] (IGNITE-5909) Web console: Implement editable list

2017-10-18 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov updated IGNITE-5909:
-
Fix Version/s: 2.4

> Web console: Implement editable list
> 
>
> Key: IGNITE-5909
> URL: https://issues.apache.org/jira/browse/IGNITE-5909
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>




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


[jira] [Closed] (IGNITE-6647) Web Console: Implement schema migration

2017-10-18 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov closed IGNITE-6647.


Merged to master.

> Web Console: Implement schema migration
> ---
>
> Key: IGNITE-6647
> URL: https://issues.apache.org/jira/browse/IGNITE-6647
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> We need to support schema updates for Web Console new versions.



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


[jira] [Commented] (IGNITE-6560) Web console: New api for memory and persistence configuration

2017-10-18 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-6560:


Tested in branch

> Web console: New api for memory and persistence configuration
> -
>
> Key: IGNITE-6560
> URL: https://issues.apache.org/jira/browse/IGNITE-6560
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.2
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




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


[jira] [Assigned] (IGNITE-6560) Web console: New api for memory and persistence configuration

2017-10-18 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov reassigned IGNITE-6560:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: New api for memory and persistence configuration
> -
>
> Key: IGNITE-6560
> URL: https://issues.apache.org/jira/browse/IGNITE-6560
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.2
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>




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


[jira] [Assigned] (IGNITE-6656) SQLLine Documentation

2017-10-18 Thread Prachi Garg (JIRA)

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

Prachi Garg reassigned IGNITE-6656:
---

Assignee: Denis Magda  (was: Prachi Garg)

> SQLLine Documentation
> -
>
> Key: IGNITE-6656
> URL: https://issues.apache.org/jira/browse/IGNITE-6656
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
>  Labels: docuentation
> Fix For: 2.3
>
>
> SQLLine is officially used as a default command line tool for SQL 
> connectivity in Ignite. Document the tool usage on a dedicated page:
> https://apacheignite-sql.readme.io/docs/sqlline
> Consider the following sections:
> # The tool overview with a list of commands that are supported and not by 
> Ignite. The current list is here [1]. Split the list into 2 parts on 
> readme.io (supported and not) and briefly describe eache command.
> # Connectivity section. Start a cluster and connect to the tool using 
> {{./ignitesql.sh --color=true --verbose=true -u 
> jdbc:ignite:thin://127.0.0.1/}} script. Add a tab for ignite.bat file as well.
> # Usage section. Execute DDL and DML commands taken from the getting started 
> as it's done here [2]. When tables and indexes are created, run {{!metadata}} 
> to show the structure.
> Use private 2.3 builds generated by TC to make sure the doc is ready for the 
> release.
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Overview+sqlline+tool
> [2] https://apacheignite-sql.readme.io/v2.1/docs/sql-tooling



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


[jira] [Commented] (IGNITE-6656) SQLLine Documentation

2017-10-18 Thread Prachi Garg (JIRA)

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

Prachi Garg commented on IGNITE-6656:
-

Added documentation for SQLLine - 
https://apacheignite-sql.readme.io/v2.1/docs/sqlline.

[~dmagda], Please review.

> SQLLine Documentation
> -
>
> Key: IGNITE-6656
> URL: https://issues.apache.org/jira/browse/IGNITE-6656
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Blocker
>  Labels: docuentation
> Fix For: 2.3
>
>
> SQLLine is officially used as a default command line tool for SQL 
> connectivity in Ignite. Document the tool usage on a dedicated page:
> https://apacheignite-sql.readme.io/docs/sqlline
> Consider the following sections:
> # The tool overview with a list of commands that are supported and not by 
> Ignite. The current list is here [1]. Split the list into 2 parts on 
> readme.io (supported and not) and briefly describe eache command.
> # Connectivity section. Start a cluster and connect to the tool using 
> {{./ignitesql.sh --color=true --verbose=true -u 
> jdbc:ignite:thin://127.0.0.1/}} script. Add a tab for ignite.bat file as well.
> # Usage section. Execute DDL and DML commands taken from the getting started 
> as it's done here [2]. When tables and indexes are created, run {{!metadata}} 
> to show the structure.
> Use private 2.3 builds generated by TC to make sure the doc is ready for the 
> release.
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Overview+sqlline+tool
> [2] https://apacheignite-sql.readme.io/v2.1/docs/sql-tooling



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


[jira] [Closed] (IGNITE-6283) Document ALTER TABLE ADD COLUMN command

2017-10-18 Thread Denis Magda (JIRA)

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

Denis Magda closed IGNITE-6283.
---

> Document ALTER TABLE ADD COLUMN command
> ---
>
> Key: IGNITE-6283
> URL: https://issues.apache.org/jira/browse/IGNITE-6283
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>




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


[jira] [Commented] (IGNITE-6283) Document ALTER TABLE ADD COLUMN command

2017-10-18 Thread Alexander Paschenko (JIRA)

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

Alexander Paschenko commented on IGNITE-6283:
-

[~dmagda], the answer is "yes" for both questions.

> Document ALTER TABLE ADD COLUMN command
> ---
>
> Key: IGNITE-6283
> URL: https://issues.apache.org/jira/browse/IGNITE-6283
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>




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


[jira] [Updated] (IGNITE-6669) CacheStoreSessionListener#onSessionStart() #onSessionEnd() methods are called by GridCacheStoreManagerAdapter even if a store operation should not be performed.

2017-10-18 Thread Vyacheslav Koptilin (JIRA)

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

Vyacheslav Koptilin updated IGNITE-6669:

Attachment: Reproducer.java

> CacheStoreSessionListener#onSessionStart() #onSessionEnd() methods are called 
> by GridCacheStoreManagerAdapter even if a store operation should not be 
> performed.
> 
>
> Key: IGNITE-6669
> URL: https://issues.apache.org/jira/browse/IGNITE-6669
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Affects Versions: 1.8
>Reporter: Vyacheslav Koptilin
> Attachments: Reproducer.java
>
>
> In the case of transactional cache, which is configured using {{CacheStore}} 
> and {{CacheJdbcStoreSessionListener}}, every update triggers 
> {{CacheStoreSessionListener # onSessionStart()}} that results in creating the 
> connection to an underlying database, even if read-through and write-through 
> modes are disabled.



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


[jira] [Created] (IGNITE-6669) CacheStoreSessionListener#onSessionStart() #onSessionEnd() methods are called by GridCacheStoreManagerAdapter even if a store operation should not be performed.

2017-10-18 Thread Vyacheslav Koptilin (JIRA)
Vyacheslav Koptilin created IGNITE-6669:
---

 Summary: CacheStoreSessionListener#onSessionStart() 
#onSessionEnd() methods are called by GridCacheStoreManagerAdapter even if a 
store operation should not be performed.
 Key: IGNITE-6669
 URL: https://issues.apache.org/jira/browse/IGNITE-6669
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: cache
Affects Versions: 1.8
Reporter: Vyacheslav Koptilin


In the case of transactional cache, which is configured using {{CacheStore}} 
and {{CacheJdbcStoreSessionListener}}, every update triggers 
{{CacheStoreSessionListener # onSessionStart()}} that results in creating the 
connection to an underlying database, even if read-through and write-through 
modes are disabled.



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


[jira] [Commented] (IGNITE-6030) Allow enabling persistence per-cache

2017-10-18 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-6030:
-

[~ivan.glukos], please consider the following before closing the ticket:
* Update all the persistence and memory pools related examples to the new 
configuration format. Run a compilation and make sure there is no single 
example that prints out the class deprecated warning. For instance, these two 
have to be adopted -  {{PersistentStoreExample}}, {{MemoryPoliciesExample}}. 
The latter should be renamed to {{DataRegionsConfigurationExample}}.
* Make sure that every property gets sufficient javadoc for our users to 
understand.
* Reassign the ticket on me for documentation updates on readme.io side. I'll 
rely on the javadoc provided by you. 

> Allow enabling persistence per-cache
> 
>
> Key: IGNITE-6030
> URL: https://issues.apache.org/jira/browse/IGNITE-6030
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: important
> Fix For: 2.3
>
>
> Also, when cache native persistence is disabled, we need to make sure that 
> different {{CacheStores}} can be configured on per-cache basis.
> New storage configuration design draft:
> {noformat}
> DataStorageConfiguration
>   // memory configuration
>   getConcurrencyLevel
>   getDefaultDataRegionConfiguration
>   getDataRegionConfigurations
>   getPageSize
>   getSystemRegionInitialSize
>   getSystemRegionMaxSize
>   // persistence coniguration
>   getCheckpointFrequency
>   getCheckpointPageBufferSize
>   getCheckpointThreads
>   getCheckpointWriteOrder
>   getFileIOFactory
>   getLockWaitTime
>   getStoragePath // storage for index and partition files
>   getMetricsRateTimeInterval
>   getMetricsSubIntervalCount
>   getWalThreadLocalBufferSize
>   getWalArchivePath // archived WAL segments
>   getWalAutoArchiveAfterInactivity
>   getWalFlushFrequency
>   getWalFsyncDelayNanos
>   getWalHistorySize
>   getWalMode
>   getWalRecordIteratorBufferSize
>   getWalSegments
>   getWalSegmentSize
>   getWalPath // working set of WAL segments
>   isAlwaysWriteFullPages
>   isMetricsEnabled
>   isWriteThrottlingEnabled
> DataRegionConfiguration
>   // memory policy configuration
>   isPersistenceEnabled (default = false)
>   getEmptyPagesPoolSize
>   getEvictionThreshold
>   getInitialSize
>   getMaxSize
>   getName
>   getPageEvictionMode
>   getMetricsRateTimeInterval
>   getMetricsSubIntervalCount
>   getSwapPath
>   isMetricsEnabled
> {noformat}
> New metrics and MBean classes:
> {noformat}
> PersistenceMetrics -> DataStorageMetrics
> PersistenceMetricsMXBean -> DataStorageMetricsMXBean
> MemoryMetrics -> DataRegionMetrics
> MemoryMetricsMXBean -> DataRegionMetricsMXBean
> {noformat}
> Please note that old versions of all classes and methods are retained in 
> codebase as deprecated.



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


[jira] [Updated] (IGNITE-6667) Allow discovery cache instance reuse if only minor topology change has occured.

2017-10-18 Thread Alexei Scherbakov (JIRA)

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

Alexei Scherbakov updated IGNITE-6667:
--
Description: 
Currently we always recreating DiscoCache instance even if only minor topology 
change has occured and cache may be reused.

Profiling shows what initialization of such object tooks up tens of millis 
which adds to ring latency delay and especially sensitive for large topologies.

Solution: reuse current discovery cache instance whenever possible.



  was:
Currently we always recreating DiscoCache instance even if only minor topology 
change has occured and cache may be reused.

Profiling shows what initialization of such object tooks up tens of millis 
which adds to ring latency delay and especially sensitive for large topologies.

Solution: reuse current discovery cache instance if possible.




> Allow discovery cache instance reuse if only minor topology change has 
> occured.
> ---
>
> Key: IGNITE-6667
> URL: https://issues.apache.org/jira/browse/IGNITE-6667
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.4
>
>
> Currently we always recreating DiscoCache instance even if only minor 
> topology change has occured and cache may be reused.
> Profiling shows what initialization of such object tooks up tens of millis 
> which adds to ring latency delay and especially sensitive for large 
> topologies.
> Solution: reuse current discovery cache instance whenever possible.



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


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

2017-10-18 Thread Nikolay Tikhonov (JIRA)

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

Nikolay Tikhonov commented on IGNITE-6660:
--

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

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



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


[jira] [Commented] (IGNITE-6515) .NET: Enable persistence on per-cache basis

2017-10-18 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-6515:


API updated according to IGNITE-6030 again.

> .NET: Enable persistence on per-cache basis
> ---
>
> Key: IGNITE-6515
> URL: https://issues.apache.org/jira/browse/IGNITE-6515
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, important
> Fix For: 2.3
>
>
> Propagate new configuration to .NET: IGNITE-6030



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


[jira] [Created] (IGNITE-6668) Binary metadata read must not block if called from discovery thread.

2017-10-18 Thread Sergey Chugunov (JIRA)
Sergey Chugunov created IGNITE-6668:
---

 Summary: Binary metadata read must not block if called from 
discovery thread.
 Key: IGNITE-6668
 URL: https://issues.apache.org/jira/browse/IGNITE-6668
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
 Fix For: 2.4


Some actions like {{Messaging.RemoteListen}} from .NET functionality involve 
reading binary metadata when handling message in discovery thread.

This may cause a deadlock as metadata read can block and wait for another 
discovery event to arrive.

To avoid deadlock we can check if current thread executing metadata read call 
is discovery thread and return current value right away.



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


[jira] [Created] (IGNITE-6667) Allow discovery cache instance reuse if only minor topology change has occured.

2017-10-18 Thread Alexei Scherbakov (JIRA)
Alexei Scherbakov created IGNITE-6667:
-

 Summary: Allow discovery cache instance reuse if only minor 
topology change has occured.
 Key: IGNITE-6667
 URL: https://issues.apache.org/jira/browse/IGNITE-6667
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2.4


Currently we always recreating DiscoCache instance even if only minor topology 
change has occured and cache may be reused.

Profiling shows what initialization of such object tooks up tens of millis 
which adds to ring latency delay and especially sensitive for large topologies.

Solution: reuse current discovery cache instance if possible.





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


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

2017-10-18 Thread Oleg Ostanin (JIRA)

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

Oleg Ostanin commented on IGNITE-6660:
--

[~ntikho...@apache.org]
Please review the changes
https://github.com/apache/ignite/pull/2879

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



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


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

2017-10-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6660:


GitHub user oleg-ostanin opened a pull request:

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

IGNITE-6660 fixed Python Redis example (print statements)



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

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

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

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


commit 5b2329fb1f75de4c41592868c58be92fa5a908da
Author: oleg-ostanin 
Date:   2017-10-18T15:16:19Z

IGNITE-6660 fixed Python Redis example (print statements)




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



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


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

2017-10-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-:


GitHub user NSAmelchev opened a pull request:

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

IGNITE-

Defined the variable totalLen for TIME type in method 
BinaryObjectImpl.writeFieldByOrder.

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

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

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

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


commit 727b47e704310cac7ae3cb4dc23a8153f48123d0
Author: NSAmelchev 
Date:   2017-10-18T15:09:52Z

add fix and test




> BinaryObjectImpl.writeFieldByOrder method does not support TIME
> ---
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: binary
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>
> The variable totalLen is not define for TIME in method 
> BinaryObjectImpl.writeFieldByOrder.



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


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

2017-10-18 Thread Amelchev Nikita (JIRA)
Amelchev Nikita created IGNITE-:
---

 Summary: BinaryObjectImpl.writeFieldByOrder method does not 
support TIME
 Key: IGNITE-
 URL: https://issues.apache.org/jira/browse/IGNITE-
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: binary
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


The variable totalLen is not define for TIME in method 
BinaryObjectImpl.writeFieldByOrder.



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


[jira] [Updated] (IGNITE-6665) Client node re-joins only to the list from disco configuration and ignores the rest nodes

2017-10-18 Thread Mikhail Cherkasov (JIRA)

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

Mikhail Cherkasov updated IGNITE-6665:
--
Attachment: ClientReJoinTest.java

> Client node re-joins only to the list from disco configuration and ignores 
> the rest nodes
> -
>
> Key: IGNITE-6665
> URL: https://issues.apache.org/jira/browse/IGNITE-6665
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.2
>Reporter: Mikhail Cherkasov
> Fix For: 2.4
>
> Attachments: ClientReJoinTest.java
>
>
> Client node re-joins only to the list from disco configuration and ignores 
> the rest nodes.
> if we have a cluster with 3 server nodes and in client discovery 
> configuration only 1 is mentioned and this server node left cluster, client 
> node will try to re-join only to this one and will ignore the rest 2 server 
> nodes.
> Reproducer is attached.



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


[jira] [Created] (IGNITE-6665) Client node re-joins only to the list from disco configuration and ignores the rest nodes

2017-10-18 Thread Mikhail Cherkasov (JIRA)
Mikhail Cherkasov created IGNITE-6665:
-

 Summary: Client node re-joins only to the list from disco 
configuration and ignores the rest nodes
 Key: IGNITE-6665
 URL: https://issues.apache.org/jira/browse/IGNITE-6665
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: general
Affects Versions: 2.2
Reporter: Mikhail Cherkasov
 Fix For: 2.4


Client node re-joins only to the list from disco configuration and ignores the 
rest nodes.
if we have a cluster with 3 server nodes and in client discovery configuration 
only 1 is mentioned and this server node left cluster, client node will try to 
re-join only to this one and will ignore the rest 2 server nodes.

Reproducer is attached.



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


[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

2017-10-18 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn updated IGNITE-6627:
---
Component/s: (was: cache)

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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


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

2017-10-18 Thread Ilya Lantukh (JIRA)

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

Ilya Lantukh commented on IGNITE-5852:
--

Fixed this bug, please review.

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



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


[jira] [Updated] (IGNITE-6587) Ignite watchdog service

2017-10-18 Thread Sergey Puchnin (JIRA)

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

Sergey Puchnin updated IGNITE-6587:
---
Labels: IEP-5  (was: )

> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>  Labels: IEP-5
> Fix For: 2.4
>
>
> We need to come up with a 'watchdog service' to monitor for Ignite node local 
> health and kill the process under some critical conditions.
> For example, if one of the mission-critical Ignite threads die, the Ignite 
> node must be stopped.
> At the first glance, the list of critical threads is:
> All TCP discovery threads
> All communication NIO threads (acceptor and workers)
> Exchange worker
> Striped pool threads
> Timeout Worker
> Checkpointer 
> WAL archiver
> The mechanism should support pluggable components so that self-check can be 
> extended via plugins.



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


[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

2017-10-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6627:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-6627 .NET: Fix repeated known metadata updates

Previous commit has broken the BinaryStructureTracker optimization

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

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

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

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


commit d3c4a3e61a32343aeee012c1b751a96b490fb1bc
Author: Pavel Tupitsyn 
Date:   2017-10-18T13:03:48Z

IGNITE-6627 .NET: Fix structure tracker optimization




> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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


[jira] [Reopened] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

2017-10-18 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn reopened IGNITE-6627:

  Assignee: Pavel Tupitsyn  (was: Alexey Popov)

Merged fix defeats {{BinaryStructureTracker}} purpose, which is to avoid 
sending already known metadata to the cluster. Investigating.

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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


[jira] [Commented] (IGNITE-6662) SQL: affinity key column is resolved incorrectly in GridH2Table

2017-10-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6662:


Github user devozerov closed the pull request at:

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


> SQL: affinity key column is resolved incorrectly in GridH2Table
> ---
>
> Key: IGNITE-6662
> URL: https://issues.apache.org/jira/browse/IGNITE-6662
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> Reproducer:
> 1) Start empty node;
> 2) Execute {{CREATE TABLE Department (id LONG PRIMARY KEY, name VARCHAR)}}
> 3) Observe in debugger how additional "AFFINITY KEY" index is created for the 
> table.
> Root cause: we do not check whether resolved affinity key column is 
> effectively an alias to the {{_KEY}}.



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


[jira] [Created] (IGNITE-6664) Memcached example refactoring

2017-10-18 Thread Sergey Kozlov (JIRA)
Sergey Kozlov created IGNITE-6664:
-

 Summary: Memcached example refactoring
 Key: IGNITE-6664
 URL: https://issues.apache.org/jira/browse/IGNITE-6664
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: examples
Affects Versions: 2.2
Reporter: Sergey Kozlov
 Fix For: 2.4


The memcached example {{examples/memcached/memcached-example.php}} looks like 
outpdated and doesn't work for php 7.0/7.1.



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


[jira] [Commented] (IGNITE-6336) .NET: Thin client: Create cache

2017-10-18 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-6336:


Let's skip complex {{CacheConfiguration}} properties (which involve user code 
inside) for now:
* {{CacheStoreFactory}}
* {{EvictionPolicy}}
* {{AffinityFunction}}
* {{ExpiryPolicyFactory}}

Support all simple properties and {{QueryEntities}}.

> .NET: Thin client: Create cache
> ---
>
> Key: IGNITE-6336
> URL: https://issues.apache.org/jira/browse/IGNITE-6336
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Create, destroy and observer caches from thin client (by name and from 
> {{CacheConfiguration}}).
> * {{IIgniteClient.CreateCache}}, {{GetOrCreateCache}} overloads
> * {{ICacheClient.GetConfiguration}}
> * {{IIgnite.GetCacheNames}}
> * {{IIgniteClient.DestroyCache}}



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


[jira] [Updated] (IGNITE-6336) .NET: Thin client: Create cache

2017-10-18 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn updated IGNITE-6336:
---
Description: 
Create, destroy and observer caches from thin client (by name and from 
{{CacheConfiguration}}).

* {{IIgniteClient.CreateCache}}, {{GetOrCreateCache}} overloads
* {{ICacheClient.GetConfiguration}}
* {{IIgnite.GetCacheNames}}
* {{IIgniteClient.DestroyCache}}

  was:
Create caches from thin client (by name and from {{CacheConfiguration}}).

Implement {{ICache.GetConfiguration}}.


> .NET: Thin client: Create cache
> ---
>
> Key: IGNITE-6336
> URL: https://issues.apache.org/jira/browse/IGNITE-6336
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Create, destroy and observer caches from thin client (by name and from 
> {{CacheConfiguration}}).
> * {{IIgniteClient.CreateCache}}, {{GetOrCreateCache}} overloads
> * {{ICacheClient.GetConfiguration}}
> * {{IIgnite.GetCacheNames}}
> * {{IIgniteClient.DestroyCache}}



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


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

2017-10-18 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov resolved IGNITE-5608.
-
Resolution: Fixed

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



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


[jira] [Assigned] (IGNITE-6425) Races during transaction finalization

2017-10-18 Thread Eduard Shangareev (JIRA)

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

Eduard Shangareev reassigned IGNITE-6425:
-

Assignee: (was: Eduard Shangareev)

> Races during transaction finalization
> -
>
> Key: IGNITE-6425
> URL: https://issues.apache.org/jira/browse/IGNITE-6425
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Critical
>
> I have found during stress-test (start-stop nodes during transactions 
> running):
> {code}
> [2017-09-20 12:37:04,224][ERROR][updater-1][GridDhtColocatedCache]  
> Failed to rollback transaction (cache may contain stale locks): 
> GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl [mapping=null], 
> nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null, 
> hasRemoteLocks=false, thread=updater-1, mappings=IgniteTxMappingsSingleImpl 
> [mapping=null], super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, 
> nearNodes=[], dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=117380231, 
> order=1505900296519, nodeOrder=1], writeVer=null, implicit=true, loc=true, 
> threadId=15914, startTime=1505900224068, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, startVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], endVer=null, 
> isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0, 
> sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], finalizing=NONE, 
> invalidParts=null, state=ROLLED_BACK, timedOut=false, 
> topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], duration=153ms, 
> onePhaseCommit=false], size=1]]]
> class org.apache.ignite.IgniteCheckedException: Failed to commit transaction: 
> GridNearTxLocal[id=749f6ae9e51--06ff-1487--0001, 
> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK, 
> invalidate=false, rollbackOnly=true, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, duration=153]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3310)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2411)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2393)
>   at 
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:340)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:69)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>   at 
> 

[jira] [Created] (IGNITE-6663) SQL: optimize primary key equality lookup

2017-10-18 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-6663:
---

 Summary: SQL: optimize primary key equality lookup
 Key: IGNITE-6663
 URL: https://issues.apache.org/jira/browse/IGNITE-6663
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.4


H2 perform every index search through {{BaseIndex.find}} method. It contains 
both {{first}} and {{last}} rows. If condition looks like {{attr = ?}}, then 
both bounds are the same. When this call is propagated to our {{BPlusTree}}, 
then two index lookups occur:
- Lower bound: {{BPlusTree#findInsertionPoint}}
- Upper bound: {{BPlusTree.ForwardCursor#findUpperBound}}

This is done for a reason because we do not know in advance how many elements 
are in between the bounds, so one lookup + scan is not an option in general 
case. But in case of PK lookup with equality condition, when we know in advance 
that only one row will be returned, this leads to additional unnecessary 
comparisons. 

Suggested fix:
1) Make sure that all rows in {{GridH2PlainRowFactory}} has correct {{equals}} 
implementation.
2) Inside {{H2TreeIndex#find}}: if this is PK index (see constructor args) and 
{{lower.equals(upper)}}, then use {{BPlusTree.findOne}} instead of 
{{BPlusTree.find}}.



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


[jira] [Updated] (IGNITE-6663) SQL: optimize primary key equality lookup

2017-10-18 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-6663:

Labels: performance  (was: )

> SQL: optimize primary key equality lookup
> -
>
> Key: IGNITE-6663
> URL: https://issues.apache.org/jira/browse/IGNITE-6663
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> H2 perform every index search through {{BaseIndex.find}} method. It contains 
> both {{first}} and {{last}} rows. If condition looks like {{attr = ?}}, then 
> both bounds are the same. When this call is propagated to our {{BPlusTree}}, 
> then two index lookups occur:
> - Lower bound: {{BPlusTree#findInsertionPoint}}
> - Upper bound: {{BPlusTree.ForwardCursor#findUpperBound}}
> This is done for a reason because we do not know in advance how many elements 
> are in between the bounds, so one lookup + scan is not an option in general 
> case. But in case of PK lookup with equality condition, when we know in 
> advance that only one row will be returned, this leads to additional 
> unnecessary comparisons. 
> Suggested fix:
> 1) Make sure that all rows in {{GridH2PlainRowFactory}} has correct 
> {{equals}} implementation.
> 2) Inside {{H2TreeIndex#find}}: if this is PK index (see constructor args) 
> and {{lower.equals(upper)}}, then use {{BPlusTree.findOne}} instead of 
> {{BPlusTree.find}}.



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


[jira] [Commented] (IGNITE-6662) SQL: affinity key column is resolved incorrectly in GridH2Table

2017-10-18 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-6662:
-

Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=897354

> SQL: affinity key column is resolved incorrectly in GridH2Table
> ---
>
> Key: IGNITE-6662
> URL: https://issues.apache.org/jira/browse/IGNITE-6662
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> Reproducer:
> 1) Start empty node;
> 2) Execute {{CREATE TABLE Department (id LONG PRIMARY KEY, name VARCHAR)}}
> 3) Observe in debugger how additional "AFFINITY KEY" index is created for the 
> table.
> Root cause: we do not check whether resolved affinity key column is 
> effectively an alias to the {{_KEY}}.



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


[jira] [Commented] (IGNITE-6662) SQL: affinity key column is resolved incorrectly in GridH2Table

2017-10-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6662:


GitHub user devozerov opened a pull request:

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

IGNITE-6662



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

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

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

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


commit cf6b28e6e0676db0f8637358581462002401e3ac
Author: devozerov 
Date:   2017-10-18T10:56:22Z

IGNITE-6662




> SQL: affinity key column is resolved incorrectly in GridH2Table
> ---
>
> Key: IGNITE-6662
> URL: https://issues.apache.org/jira/browse/IGNITE-6662
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> Reproducer:
> 1) Start empty node;
> 2) Execute {{CREATE TABLE Department (id LONG PRIMARY KEY, name VARCHAR)}}
> 3) Observe in debugger how additional "AFFINITY KEY" index is created for the 
> table.
> Root cause: we do not check whether resolved affinity key column is 
> effectively an alias to the {{_KEY}}.



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


[jira] [Created] (IGNITE-6662) SQL: affinity key column is resolved incorrectly in GridH2Table

2017-10-18 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-6662:
---

 Summary: SQL: affinity key column is resolved incorrectly in 
GridH2Table
 Key: IGNITE-6662
 URL: https://issues.apache.org/jira/browse/IGNITE-6662
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.3


Reproducer:
1) Start empty node;
2) Execute {{CREATE TABLE Department (id LONG PRIMARY KEY, name VARCHAR)}}
3) Observe in debugger how additional "AFFINITY KEY" index is created for the 
table.

Root cause: we do not check whether resolved affinity key column is effectively 
an alias to the {{_KEY}}.



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


[jira] [Assigned] (IGNITE-6587) Ignite watchdog service

2017-10-18 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov reassigned IGNITE-6587:
--

Assignee: Dmitriy Pavlov

> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> We need to come up with a 'watchdog service' to monitor for Ignite node local 
> health and kill the process under some critical conditions.
> For example, if one of the mission-critical Ignite threads die, the Ignite 
> node must be stopped.
> At the first glance, the list of critical threads is:
> All TCP discovery threads
> All communication NIO threads (acceptor and workers)
> Exchange worker
> Striped pool threads
> Timeout Worker
> Checkpointer 
> WAL archiver
> The mechanism should support pluggable components so that self-check can be 
> extended via plugins.



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


[jira] [Commented] (IGNITE-6658) Add a version of Ignite instance to logger category

2017-10-18 Thread Anton Vinogradov (JIRA)

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

Anton Vinogradov commented on IGNITE-6658:
--

[~daradurvs]
Could you share log example?

> Add a version of Ignite instance to logger category
> ---
>
> Key: IGNITE-6658
> URL: https://issues.apache.org/jira/browse/IGNITE-6658
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Minor
> Fix For: 2.4
>
>
> Needs to add a version of Ignite instance to logger category in Compatibility 
> Testing Framework.
> This would make it easier to analyze the tests logged output.
> The improvement suggested by [~avinogradov].



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


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

2017-10-18 Thread Oleg Ostanin (JIRA)

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

Oleg Ostanin reassigned IGNITE-6660:


Assignee: Oleg Ostanin

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



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


[jira] [Created] (IGNITE-6661) fix client deadlock in 2.x

2017-10-18 Thread Konstantin Dudkov (JIRA)
Konstantin Dudkov created IGNITE-6661:
-

 Summary: fix client deadlock in 2.x
 Key: IGNITE-6661
 URL: https://issues.apache.org/jira/browse/IGNITE-6661
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 2.3
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov






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


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

2017-10-18 Thread Sergey Kozlov (JIRA)
Sergey Kozlov created IGNITE-6660:
-

 Summary: Python Redis example fails for python 3 run
 Key: IGNITE-6660
 URL: https://issues.apache.org/jira/browse/IGNITE-6660
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: examples
Affects Versions: 2.2, 2.1, 2.0, 1.9, 1.8
Reporter: Sergey Kozlov
 Fix For: 2.3


Looks like python redis example fails due to design python 2. But for python 3 
run raised the following error:
{noformat}
  File 
"/var/lib/teamcity/data/work/17028f058b6ef75f/i2test/var/suite-examples/gg-pro-fab/examples/redis/redis-example.py",
 line 32
print 'Value for "k1": %s' % r.get('k1')
 ^
SyntaxError: invalid syntax
{noformat}

The suggested fix is to put brackets for print calls: 
-{{print 'Value for "k1": %s' % r.get('k1')}}-
{{print('Value for "k1": %s' % r.get('k1'))}}




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


[jira] [Commented] (IGNITE-6658) Add a version of Ignite instance to logger category

2017-10-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6658:


GitHub user daradurvs opened a pull request:

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

IGNITE-6658 Add a version of Ignite instance to logger category



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

$ git pull https://github.com/daradurvs/ignite ignite-6658

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

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


commit ec4f32b342a2f8df08148f89272637841be0f6f9
Author: Vyacheslav Daradur 
Date:   2017-10-18T09:53:03Z

ignite-6658: added a version of Ignite instance to logger category




> Add a version of Ignite instance to logger category
> ---
>
> Key: IGNITE-6658
> URL: https://issues.apache.org/jira/browse/IGNITE-6658
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Minor
> Fix For: 2.4
>
>
> Needs to add a version of Ignite instance to logger category in Compatibility 
> Testing Framework.
> This would make it easier to analyze the tests logged output.
> The improvement suggested by [~avinogradov].



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


[jira] [Updated] (IGNITE-6030) Allow enabling persistence per-cache

2017-10-18 Thread Ivan Rakov (JIRA)

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

Ivan Rakov updated IGNITE-6030:
---
Description: 
Also, when cache native persistence is disabled, we need to make sure that 
different {{CacheStores}} can be configured on per-cache basis.

New storage configuration design draft:
{noformat}
DataStorageConfiguration
// memory configuration
getConcurrencyLevel
getDefaultDataRegionConfiguration
getDataRegionConfigurations
getPageSize
getSystemRegionInitialSize
getSystemRegionMaxSize
// persistence coniguration
getCheckpointFrequency
getCheckpointPageBufferSize
getCheckpointThreads
getCheckpointWriteOrder
getFileIOFactory
getLockWaitTime
getStoragePath // storage for index and partition files
getMetricsRateTimeInterval
getMetricsSubIntervalCount
getWalThreadLocalBufferSize
getWalArchivePath // archived WAL segments
getWalAutoArchiveAfterInactivity
getWalFlushFrequency
getWalFsyncDelayNanos
getWalHistorySize
getWalMode
getWalRecordIteratorBufferSize
getWalSegments
getWalSegmentSize
getWalPath // working set of WAL segments
isAlwaysWriteFullPages
isMetricsEnabled
isWriteThrottlingEnabled

DataRegionConfiguration
// memory policy configuration
isPersistenceEnabled (default = false)
getEmptyPagesPoolSize
getEvictionThreshold
getInitialSize
getMaxSize
getName
getPageEvictionMode
getMetricsRateTimeInterval
getMetricsSubIntervalCount
getSwapPath
isMetricsEnabled
{noformat}

New metrics and MBean classes:
{noformat}
PersistenceMetrics -> DataStorageMetrics
PersistenceMetricsMXBean -> DataStorageMetricsMXBean
MemoryMetrics -> DataRegionMetrics
MemoryMetricsMXBean -> DataRegionMetricsMXBean
{noformat}

Please note that old versions of all classes and methods are retained in 
codebase as deprecated.

  was:
Also, when cache native persistence is disabled, we need to make sure that 
different {{CacheStores}} can be configured on per-cache basis.

New storage configuration design draft:
{noformat}
DataStorageConfiguration
// memory configuration
getConcurrencyLevel
getDefaultDataRegionConfiguration
getDataRegionConfigurations
getPageSize
getSystemRegionInitialSize
getSystemRegionMaxSize
// persistence coniguration
getCheckpointFrequency
getCheckpointPageBufferSize
getCheckpointThreads
getCheckpointWriteOrder
getFileIOFactory
getLockWaitTime
getStoragePath // storage for index and partition files
getMetricsRateTimeInterval
getMetricsSubIntervalCount
getWalTlbSize
getWalArchivePath // archived WAL segments
getWalAutoArchiveAfterInactivity
getWalFlushFrequency
getWalFsyncDelayNanos
getWalHistorySize
getWalMode
getWalRecordIteratorBufferSize
getWalSegments
getWalSegmentSize
getWalPath // working set of WAL segments
isAlwaysWriteFullPages
isMetricsEnabled
isWriteThrottlingEnabled

DataRegionConfiguration
// memory policy configuration
isPersistenceEnabled (default = false)
getEmptyPagesPoolSize
getEvictionThreshold
getInitialSize
getMaxSize
getName
getPageEvictionMode
getMetricsRateTimeInterval
getMetricsSubIntervalCount
getSwapPath
isMetricsEnabled
{noformat}

New metrics and MBean classes:
{noformat}
PersistenceMetrics -> DataStorageMetrics
PersistenceMetricsMXBean -> DataStorageMetricsMXBean
MemoryMetrics -> DataRegionMetrics
MemoryMetricsMXBean -> DataRegionMetricsMXBean
{noformat}

Please note that old versions of all classes and methods are retained in 
codebase as deprecated.


> Allow enabling persistence per-cache
> 
>
> Key: IGNITE-6030
> URL: https://issues.apache.org/jira/browse/IGNITE-6030
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: important
> Fix For: 2.3
>
>
> Also, when cache native persistence is disabled, we need to make sure that 
> different {{CacheStores}} can be configured on per-cache basis.
> New storage configuration design draft:
> {noformat}
> DataStorageConfiguration
>   // memory configuration
>   getConcurrencyLevel
>   getDefaultDataRegionConfiguration
>   getDataRegionConfigurations
>   getPageSize
>  

[jira] [Updated] (IGNITE-6659) Check that public API is not called in sensitive system threads

2017-10-18 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk updated IGNITE-6659:
-
Description: 
We need to add a check that public (or semi-public) blocking API is not called 
from sensitive system threads.
For example, cache operations, service deploy must not be called in disco* 
threads, exchange-worker, system thread pool because this will cause a 
cluster-wide deadlock.

Need to consider which other threads and APIs are affected.

Any invalid call must throw an exception.

  was:
We need to add a check that public (or semi-public) blocking API is not called 
from sensitive system threads.
For example, cache operations, service deploy must not be called in disco* 
threads, exchange-worker, system thread pool.

Need to consider which other threads and APIs are affected.


> Check that public API is not called in sensitive system threads
> ---
>
> Key: IGNITE-6659
> URL: https://issues.apache.org/jira/browse/IGNITE-6659
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
> Fix For: 2.4
>
>
> We need to add a check that public (or semi-public) blocking API is not 
> called from sensitive system threads.
> For example, cache operations, service deploy must not be called in disco* 
> threads, exchange-worker, system thread pool because this will cause a 
> cluster-wide deadlock.
> Need to consider which other threads and APIs are affected.
> Any invalid call must throw an exception.



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


[jira] [Created] (IGNITE-6659) Check that public API is not called in sensitive system threads

2017-10-18 Thread Alexey Goncharuk (JIRA)
Alexey Goncharuk created IGNITE-6659:


 Summary: Check that public API is not called in sensitive system 
threads
 Key: IGNITE-6659
 URL: https://issues.apache.org/jira/browse/IGNITE-6659
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Alexey Goncharuk
 Fix For: 2.4


We need to add a check that public (or semi-public) blocking API is not called 
from sensitive system threads.
For example, cache operations, service deploy must not be called in disco* 
threads, exchange-worker, system thread pool.

Need to consider which other threads and APIs are affected.



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


[jira] [Created] (IGNITE-6658) Add a version of Ignite instance to logger category

2017-10-18 Thread Vyacheslav Daradur (JIRA)
Vyacheslav Daradur created IGNITE-6658:
--

 Summary: Add a version of Ignite instance to logger category
 Key: IGNITE-6658
 URL: https://issues.apache.org/jira/browse/IGNITE-6658
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Priority: Minor
 Fix For: 2.4


Needs to add a version of Ignite instance to logger category in Compatibility 
Testing Framework.

This would make it easier to analyze the tests logged output.

The improvement suggested by [~avinogradov].



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


[jira] [Commented] (IGNITE-6595) rebuildIndexesFromHash does not touch cache entries

2017-10-18 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk commented on IGNITE-6595:
--

Added touch() for cache entry during index rebuild

> rebuildIndexesFromHash does not touch cache entries
> ---
>
> Key: IGNITE-6595
> URL: https://issues.apache.org/jira/browse/IGNITE-6595
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.3
>
>
> rebuildIndexesFromHash does not touch cache entry after ensureIndex(), which 
> leads to memory leak.



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


[jira] [Updated] (IGNITE-6595) rebuildIndexesFromHash does not touch cache entries

2017-10-18 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk updated IGNITE-6595:
-
Fix Version/s: (was: 2.4)
   2.3

> rebuildIndexesFromHash does not touch cache entries
> ---
>
> Key: IGNITE-6595
> URL: https://issues.apache.org/jira/browse/IGNITE-6595
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.3
>
>
> rebuildIndexesFromHash does not touch cache entry after ensureIndex(), which 
> leads to memory leak.



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


[jira] [Commented] (IGNITE-6560) Web console: New api for memory and persistence configuration

2017-10-18 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-6560:


# WAL mode - unavailable
# Storage path - I assume it should has a default path

> Web console: New api for memory and persistence configuration
> -
>
> Key: IGNITE-6560
> URL: https://issues.apache.org/jira/browse/IGNITE-6560
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.2
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




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