[jira] [Updated] (IGNITE-7520) Provide util-methods to get baseline from context

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7520:

Fix Version/s: (was: 2.4)
   2.5

> Provide util-methods to get baseline from context
> -
>
> Key: IGNITE-7520
> URL: https://issues.apache.org/jira/browse/IGNITE-7520
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now it's not trivial to memorize or find way how to get instance of baseline 
> topology. 
> One solution is providing util-method which would accumulate knowledge where 
> baseline is kept.



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

[jira] [Updated] (IGNITE-7521) Add new assertions to FilePageStore and provide page content if read page is broken

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7521:

Fix Version/s: (was: 2.4)
   2.5

> Add new assertions to FilePageStore and provide page content if read page is 
> broken
> ---
>
> Key: IGNITE-7521
> URL: https://issues.apache.org/jira/browse/IGNITE-7521
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> There is lack of information to troubleshoot a problem with reading corrupted 
> data.
> Add some information FilePageStore - assertions, page content.



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

[jira] [Assigned] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin reassigned IGNITE-7366:


Assignee: Pavel Pereslegin

> Affinity assignment exception in service processor during multiple nodes join
> -
>
> Key: IGNITE-7366
> URL: https://issues.apache.org/jira/browse/IGNITE-7366
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Pereslegin
>Priority: Major
>
> When two nodes which are deploying services join at the same time, and 
> exception is observed:
> {code}
> SEVERE: Error when executing service: null
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=245d4bec-0384-4808-b66d-d2340930207f..., discPort=37500, order=2, 
> intOrder=2, lastExchangeTime=1515394551283, loc=true, 
> ver=2.3.0#20171028-sha1:8add7fd5, isClient=false], grp=ignite-sys-cache, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], 
> head=AffinityTopologyVersion [topVer=4, minorTopVer=0], 
> history=[AffinityTopologyVersion [topVer=2, minorTopVer=0], 
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion 
> [topVer=4, minorTopVer=0]]]
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> This may be caused by exchange merges. There are 4 nodes joining topology. 
> When nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are 
> merged. But, TopologyListener in service processor is notified about topVer 
> [3, 0], for which there is no affinity because exchange has already moved 
> forward to [4, 0].



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

[jira] [Assigned] (IGNITE-7192) JDBC: support FQDN to multiple IPs during connection establishment

[Roman Guseinov (JIRA)]

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

Roman Guseinov reassigned IGNITE-7192:
--

Assignee: Roman Guseinov

> JDBC: support FQDN to multiple IPs during connection establishment
> --
>
> Key: IGNITE-7192
> URL: https://issues.apache.org/jira/browse/IGNITE-7192
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Roman Guseinov
>Priority: Major
>
> Thin JDBC driver may have FQDN (host name) at a connection string.
> Currently, it resolves this FQDN to one IP and tries to connect to this IP 
> only.
> It is better to try to connect to multiple IPs one-by-one if DNS returns 
> multiple A-records (FQDN can be resolved to several IPs) until successful 
> connection. It could give a simple fallback option for the JDBC thin driver 
> users.
> A similar functionality is already implemented in ODBC driver.



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

[jira] [Updated] (IGNITE-7323) Update Storm dependencies to 1.1.1

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-7323:
-
Fix Version/s: (was: 2.4)
   2.5

> Update Storm dependencies to 1.1.1
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.5
>
>
> http://storm.apache.org/2017/08/01/storm111-released.html



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

[jira] [Assigned] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7408:
---

Assignee: Andrey Gura  (was: Denis Magda)

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
>  Labels: documentation
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Commented] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7408:
-

Did a primary review.

 

[~agura] , could you validate the whole page making sure that it 100% 
technically correct?

https://apacheignite.readme.io/v2.3/docs/write-ahead-log-24

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Gura
>Assignee: Denis Magda
>Priority: Major
>  Labels: documentation
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Commented] (IGNITE-6899) Adding GA Grid to Apache Ignite ML module.

[Turik Campbell (JIRA)]

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

Turik Campbell commented on IGNITE-6899:


[~techbysample], Please review my changes.

>>Turik C: Fixed 'typo' ("generes" updated to "genres") in MovieFitnessFunction.

> Adding GA Grid to Apache Ignite ML module.
> --
>
> Key: IGNITE-6899
> URL: https://issues.apache.org/jira/browse/IGNITE-6899
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Turik Campbell
>Priority: Major
> Fix For: 2.5
>
> Attachments: coverage.zip
>
>
> We want to add GA Grid to our ML Module.
> This is the first iteration of this integration. On this step we will simple 
> add GA Grid to the separate package in ML module.
> (i) This is a good package for GA Grid: org.apache.ignite.ml.genetic 
> (i) For GA Grid we need unit tests as well as examples



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

[jira] [Assigned] (IGNITE-7491) Documentation: add new data region metrics description

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7491:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Documentation: add new data region metrics description
> --
>
> Key: IGNITE-7491
> URL: https://issues.apache.org/jira/browse/IGNITE-7491
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Newly created data region metrics should be documented.
> * `getTotalAllocatedSize` -- same as `getTotalAllocatedPages` but in bytes.
> * `getPhysicalMemorySize` -- same as `getPhysicalMemoryPages` but in bytes.
> * `getCheckpointBufferPages` -- gets checkpoint buffer size in pages.
> * `getCheckpointBufferSize` -- gets checkpoint buffer size in bytes.
> * `getPageSize` -- gets memory page size.



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

[jira] [Comment Edited] (IGNITE-7491) Documentation: add new data region metrics description

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-7491 at 1/24/18 11:28 PM:
---

[~pgarg] , please document the new memory metrics on this page (create a hidden 
for 2.4):

[https://apacheignite.readme.io/docs/memory-metrics]

Update the existing code snippet of the data region metrics to show how to use 
{{getTotalAllocatedSize}} and {{getPhysicalMemorySize. }}

{{Refer to DataRegionMetrics}} JavaDoc for more details.


was (Author: dmagda):
[~pgarg] , please document the new memory metrics on this page (create a hidden 
for 2.4):

[https://apacheignite.readme.io/docs/memory-metrics]

Update the existing code snippet of the data region metrics to show how to use 
\{{getTotalAllocatedSize}} and {{getPhysicalMemorySize. }}

{{Refer to {{}}DataRegionMetrics}} JavaDoc for more details.

> Documentation: add new data region metrics description
> --
>
> Key: IGNITE-7491
> URL: https://issues.apache.org/jira/browse/IGNITE-7491
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Newly created data region metrics should be documented.
> * `getTotalAllocatedSize` -- same as `getTotalAllocatedPages` but in bytes.
> * `getPhysicalMemorySize` -- same as `getPhysicalMemoryPages` but in bytes.
> * `getCheckpointBufferPages` -- gets checkpoint buffer size in pages.
> * `getCheckpointBufferSize` -- gets checkpoint buffer size in bytes.
> * `getPageSize` -- gets memory page size.



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

[jira] [Commented] (IGNITE-7491) Documentation: add new data region metrics description

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7491:
-

[~pgarg] , please document the new memory metrics on this page (create a hidden 
for 2.4):

[https://apacheignite.readme.io/docs/memory-metrics]

Update the existing code snippet of the data region metrics to show how to use 
\{{getTotalAllocatedSize}} and {{getPhysicalMemorySize. }}

{{Refer to {{}}DataRegionMetrics}} JavaDoc for more details.

> Documentation: add new data region metrics description
> --
>
> Key: IGNITE-7491
> URL: https://issues.apache.org/jira/browse/IGNITE-7491
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Newly created data region metrics should be documented.
> * `getTotalAllocatedSize` -- same as `getTotalAllocatedPages` but in bytes.
> * `getPhysicalMemorySize` -- same as `getPhysicalMemoryPages` but in bytes.
> * `getCheckpointBufferPages` -- gets checkpoint buffer size in pages.
> * `getCheckpointBufferSize` -- gets checkpoint buffer size in bytes.
> * `getPageSize` -- gets memory page size.



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

[jira] [Comment Edited] (IGNITE-7403) Improve content on What's Ignite page

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-7403 at 1/24/18 11:03 PM:
---

[~vabramova] , thanks for the suggestions.

[~pgarg] , could you please:
 # apply the changes from "What_v4.png" and "What_v4_1.png"
 # Create a version of the page with "ignite_architecture.png" picture instead 
of the one with the durable memory. In my opinion, the Ignite architecture 
diagram conveys better what Ignite does.


was (Author: dmagda):
[~vabramova] , thanks for the suggestions. [~pgarg] , could you please apply 
the changes from "What_v4.png" and "What_v4_1.png"?

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png, 
> What_v4_1.png, ignite_architecture.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Updated] (IGNITE-7403) Improve content on What's Ignite page

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7403:

Attachment: ignite_architecture.png

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png, 
> What_v4_1.png, ignite_architecture.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Commented] (IGNITE-7403) Improve content on What's Ignite page

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7403:
-

[~vabramova] , thanks for the suggestions. [~pgarg] , could you please apply 
the changes from "What_v4.png" and "What_v4_1.png"?

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png, 
> What_v4_1.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Assigned] (IGNITE-7403) Improve content on What's Ignite page

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7403:
---

Assignee: Prachi Garg  (was: Vica Abramova)

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png, 
> What_v4_1.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Commented] (IGNITE-7507) Ignite node performance drop during checkpoint start: store metapage eviction causes long checkpoint lock hold time

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7507:


[~agoncharuk], thank you for review

> Ignite node performance drop during checkpoint start: store metapage eviction 
> causes long checkpoint lock hold time
> ---
>
> Key: IGNITE-7507
> URL: https://issues.apache.org/jira/browse/IGNITE-7507
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> Store metadata Page eviction becomes very expensive operation during 
> checkpoint start.
> These pages reads hands ignite node until metadata will be loaded from disk.
> Following store (paritition) metapages:
> - Partition Metadata Page
> - Freelist Meta Page
> - Partition Counters IO
> required during execution of saveStoreMetadata() & markCheckpointBegin()
> If this page is not available in memory, it is loaded from disk.
> But such loads are done while holding checkpointLock (in write mode).
> Example of timing:
> - checkpointLockWait=75ms, checkpointLockHoldTime=2653ms, pages=696120
> All this time worker threads are not able to put any data to any cache.
> It is required to avoid eviction of such pages (evict it with lowest priority 
> than dirty page).
> (Full stacktrace) 
> {noformat} db-checkpoint-thread-#40%checkpoint.IgniteMassLoadSandboxTest1% 
> Id=63 WAITING  
>   
> at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:324)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:306)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:291)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:656)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:576)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:130)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.saveMetadata(PagesList.java:301)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.saveStoreMetadata(GridCacheOffheapManager.java:196)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onCheckpointBegin(GridCacheOffheapManager.java:168)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3022)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2719)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2644)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Assigned] (IGNITE-7522) Web console: Wrong cluster active status after delete work folder

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-7522:


Assignee: Alexey Kuznetsov  (was: Dmitriy Shabalin)

[~kuaw26] fixed pls, pls check it

> Web console: Wrong cluster active status after delete work folder
> -
>
> Key: IGNITE-7522
> URL: https://issues.apache.org/jira/browse/IGNITE-7522
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>Priority: Major
>




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

[jira] [Created] (IGNITE-7523) Exception on data expiration after sharedRDD.saveValues call

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-7523:
-

 Summary: Exception on data expiration after sharedRDD.saveValues 
call
 Key: IGNITE-7523
 URL: https://issues.apache.org/jira/browse/IGNITE-7523
 Project: Ignite
  Issue Type: Bug
  Components: spark
Affects Versions: 2.3
Reporter: Mikhail Cherkasov
 Fix For: 2.5


Reproducer:

package rdd_expiration;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.UUID;
import java.util.concurrent.atomic.AtomicLong;
import javax.cache.Cache;
import javax.cache.expiry.CreatedExpiryPolicy;
import javax.cache.expiry.Duration;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.DataRegionConfiguration;
import org.apache.ignite.configuration.DataStorageConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.lang.IgniteOutClosure;
import org.apache.ignite.spark.JavaIgniteContext;
import org.apache.ignite.spark.JavaIgniteRDD;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.spark.SparkConf;
import org.apache.spark.api.java.JavaRDD;
import org.apache.spark.api.java.JavaSparkContext;

import static org.apache.ignite.cache.CacheAtomicityMode.ATOMIC;
import static org.apache.ignite.cache.CacheMode.PARTITIONED;
import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;

/**
* This example demonstrates how to create an JavaIgnitedRDD and share it with 
multiple spark workers. The goal of this
* particular example is to provide the simplest code example of this logic.
* 
* This example will start Ignite in the embedded mode and will start an 
JavaIgniteContext on each Spark worker node.
* 
* The example can work in the standalone mode as well that can be enabled by 
setting JavaIgniteContext's
* \{@code standalone} property to \{@code true} and running an Ignite node 
separately with
* `examples/config/spark/example-shared-rdd.xml` config.
*/
public class RddExpiration {
/**
* Executes the example.
* @param args Command line arguments, none required.
*/
public static void main(String args[]) throws InterruptedException {

Ignite server = null;

for (int i = 0; i < 4; i++) {
IgniteConfiguration serverCfg = createIgniteCfg();
serverCfg.setClientMode(false);
serverCfg.setIgniteInstanceName("Server" + i);
server = Ignition.start(serverCfg);
}

server.active(true);


// Spark Configuration.
SparkConf sparkConf = new SparkConf()
.setAppName("JavaIgniteRDDExample")
.setMaster("local")
.set("spark.executor.instances", "2");

// Spark context.
JavaSparkContext sparkContext = new JavaSparkContext(sparkConf);

// Adjust the logger to exclude the logs of no interest.
Logger.getRootLogger().setLevel(Level.ERROR);
Logger.getLogger("org.apache.ignite").setLevel(Level.INFO);

// Creates Ignite context with specific configuration and runs Ignite in the 
embedded mode.
JavaIgniteContext igniteContext = new JavaIgniteContext(
sparkContext,
new IgniteOutClosure() {
@Override public IgniteConfiguration apply() {
return createIgniteCfg();
}
},
true);

// Create a Java Ignite RDD of Type (Int,Int) Integer Pair.
JavaIgniteRDD sharedRDD = igniteContext.fromCache("sharedRDD");

long start = System.currentTimeMillis();

long totalLoaded = 0;

while(System.currentTimeMillis() - start < 55_000) {
// Define data to be stored in the Ignite RDD (cache).
List data = new ArrayList<>(20_000);

for (int i = 0; i < 20_000; i++)
data.add(i);

// Preparing a Java RDD.
JavaRDD javaRDD = sparkContext.parallelize(data);

sharedRDD.saveValues(javaRDD);

totalLoaded += 20_000;
}
System.out.println("Loaded " + totalLoaded);

for (;;) {

System.out.println(">>> Iterating over Ignite Shared RDD...");

IgniteCache cache = server.getOrCreateCache("sharedRDD");

AtomicLong recordsLeft = new AtomicLong(0);
for (Cache.Entry entry : cache) {
recordsLeft.incrementAndGet();
}
System.out.println("Left: " + recordsLeft.get());

}
// Close IgniteContext on all the workers.
// igniteContext.close(true);
}

private static IgniteConfiguration createIgniteCfg() {

IgniteConfiguration cfg = new IgniteConfiguration();

cfg.setClientMode(true);

DataStorageConfiguration memCfg = new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setCheckpointPageBufferSize(16 * 1024 * 1024)
.setMaxSize(8 * 16 * 1024 * 1024)
.setPersistenceEnabled(true));

cfg.setDataStorageConfiguration(memCfg);

TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(false);

[jira] [Updated] (IGNITE-7522) Web console: Wrong cluster active status after delete work folder

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin updated IGNITE-7522:
-
Component/s: wizards

> Web console: Wrong cluster active status after delete work folder
> -
>
> Key: IGNITE-7522
> URL: https://issues.apache.org/jira/browse/IGNITE-7522
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
>Priority: Major
>




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

[jira] [Comment Edited] (IGNITE-7521) Add new assertions to FilePageStore and provide page content if read page is broken

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev edited comment on IGNITE-7521 at 1/24/18 7:37 PM:


PR - [https://github.com/apache/ignite/pull/3432]

TC - https://ci.ignite.apache.org/viewQueued.html?itemId=1060457


was (Author: edshanggg):
PR - https://github.com/apache/ignite/pull/3432

> Add new assertions to FilePageStore and provide page content if read page is 
> broken
> ---
>
> Key: IGNITE-7521
> URL: https://issues.apache.org/jira/browse/IGNITE-7521
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.4
>
>
> There is lack of information to troubleshoot a problem with reading corrupted 
> data.
> Add some information FilePageStore - assertions, page content.



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

[jira] [Assigned] (IGNITE-7408) Document WAL changes

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-7408:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Gura
>Assignee: Denis Magda
>Priority: Major
>  Labels: documentation
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Commented] (IGNITE-7408) Document WAL changes

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-7408:
-

[~dmagda], Please review - 
[https://apacheignite.readme.io/v2.3/docs/write-ahead-log-24] , the section 
starting from " Each update is written to a buffer...", and the description for 
"BACKGROUND" mode in the table.

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Gura
>Assignee: Prachi Garg
>Priority: Major
>  Labels: documentation
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Commented] (IGNITE-7521) Add new assertions to FilePageStore and provide page content if read page is broken

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-7521:
---

PR - https://github.com/apache/ignite/pull/3432

> Add new assertions to FilePageStore and provide page content if read page is 
> broken
> ---
>
> Key: IGNITE-7521
> URL: https://issues.apache.org/jira/browse/IGNITE-7521
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.4
>
>
> There is lack of information to troubleshoot a problem with reading corrupted 
> data.
> Add some information FilePageStore - assertions, page content.



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

[jira] [Created] (IGNITE-7521) Add new assertions to FilePageStore and provide page content if read page is broken

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-7521:
-

 Summary: Add new assertions to FilePageStore and provide page 
content if read page is broken
 Key: IGNITE-7521
 URL: https://issues.apache.org/jira/browse/IGNITE-7521
 Project: Ignite
  Issue Type: Improvement
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.4


There is lack of information to troubleshoot a problem with reading corrupted 
data.
Add some information FilePageStore - assertions, page content.



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

[jira] [Updated] (IGNITE-7251) Remove term "fabric" from Ignite deliverables

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7251:

Fix Version/s: (was: 2.4)
   2.5

> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
>  Labels: important
> Fix For: 2.5
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release - 
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been 
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as - 
> {{apache-ignite-\{version}-bin}}.



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

[jira] [Comment Edited] (IGNITE-7520) Provide util-methods to get baseline from context

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev edited comment on IGNITE-7520 at 1/24/18 5:08 PM:


PR - [https://github.com/apache/ignite/pull/3431]

To cover Java Doc and compilation issue I have run 
https://ci.ignite.apache.org/viewQueued.html?itemId=1060360=queuedBuildOverviewTab


was (Author: edshanggg):
PR - https://github.com/apache/ignite/pull/3431

> Provide util-methods to get baseline from context
> -
>
> Key: IGNITE-7520
> URL: https://issues.apache.org/jira/browse/IGNITE-7520
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.4
>
>
> Now it's not trivial to memorize or find way how to get instance of baseline 
> topology. 
> One solution is providing util-method which would accumulate knowledge where 
> baseline is kept.



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

[jira] [Commented] (IGNITE-7520) Provide util-methods to get baseline from context

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-7520:
---

PR - https://github.com/apache/ignite/pull/3431

> Provide util-methods to get baseline from context
> -
>
> Key: IGNITE-7520
> URL: https://issues.apache.org/jira/browse/IGNITE-7520
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.4
>
>
> Now it's not trivial to memorize or find way how to get instance of baseline 
> topology. 
> One solution is providing util-method which would accumulate knowledge where 
> baseline is kept.



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

[jira] [Commented] (IGNITE-7520) Provide util-methods to get baseline from context

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7520:


GitHub user EdShangGG opened a pull request:

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

IGNITE-7520 Provide util-methods to get baseline from context



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

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

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

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


commit 8ac5930025c2003abaf57b4f5fd987adbaac1407
Author: EdShangGG 
Date:   2018-01-24T16:57:47Z

IGNITE-7520 Provide util-methods to get baseline from context




> Provide util-methods to get baseline from context
> -
>
> Key: IGNITE-7520
> URL: https://issues.apache.org/jira/browse/IGNITE-7520
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.4
>
>
> Now it's not trivial to memorize or find way how to get instance of baseline 
> topology. 
> One solution is providing util-method which would accumulate knowledge where 
> baseline is kept.



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

[jira] [Updated] (IGNITE-7520) Provide util-methods to get baseline from context

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-7520:
--
Description: 
Now it's not trivial to memorize or find way how to get instance of baseline 
topology. 

One solution is providing util-method which would accumulate knowledge where 
baseline is kept.

> Provide util-methods to get baseline from context
> -
>
> Key: IGNITE-7520
> URL: https://issues.apache.org/jira/browse/IGNITE-7520
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.4
>
>
> Now it's not trivial to memorize or find way how to get instance of baseline 
> topology. 
> One solution is providing util-method which would accumulate knowledge where 
> baseline is kept.



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

[jira] [Created] (IGNITE-7520) Provide util-methods to get baseline from context

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-7520:
-

 Summary: Provide util-methods to get baseline from context
 Key: IGNITE-7520
 URL: https://issues.apache.org/jira/browse/IGNITE-7520
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.4






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

[jira] [Commented] (IGNITE-6899) Adding GA Grid to Apache Ignite ML module.

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-6899:


I re-checked the most recent changes: unit tests pass as before meaning 
functionality keeps working.

There is an error added in examples code though: class {{MovieFitnessFunction}} 
line 98 typo "generes" instead of "genres".
 This error broke compilation of examples and Teamcity check but after I 
corrected it in my branch the rest went just excellent: Teamcity checks for 
javadocs [all passed on my 
branch|https://ci.ignite.apache.org/viewLog.html?buildId=1059292;].

For the sake of completeness while skimming over code I noticed some 
non-critical deviations from Ignite coding style but I don't see a pressing 
need to polish these now.

-

[~chief] I would appreciate if you take a look at code in [this 
branch|https://github.com/techbysample/ignite/tree/ignite-6899]. I am primarily 
interested to know if it's good enough to merge to master or something else 
needs to be done. (above mentioned typo in {{MovieFitnessFunction}}, it 
definitely needs to be fixed prior to merge but that's minor)


> Adding GA Grid to Apache Ignite ML module.
> --
>
> Key: IGNITE-6899
> URL: https://issues.apache.org/jira/browse/IGNITE-6899
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Turik Campbell
>Priority: Major
> Fix For: 2.5
>
> Attachments: coverage.zip
>
>
> We want to add GA Grid to our ML Module.
> This is the first iteration of this integration. On this step we will simple 
> add GA Grid to the separate package in ML module.
> (i) This is a good package for GA Grid: org.apache.ignite.ml.genetic 
> (i) For GA Grid we need unit tests as well as examples



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

[jira] [Commented] (IGNITE-7507) Ignite node performance drop during checkpoint start: store metapage eviction causes long checkpoint lock hold time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7507:


Github user asfgit closed the pull request at:

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


> Ignite node performance drop during checkpoint start: store metapage eviction 
> causes long checkpoint lock hold time
> ---
>
> Key: IGNITE-7507
> URL: https://issues.apache.org/jira/browse/IGNITE-7507
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> Store metadata Page eviction becomes very expensive operation during 
> checkpoint start.
> These pages reads hands ignite node until metadata will be loaded from disk.
> Following store (paritition) metapages:
> - Partition Metadata Page
> - Freelist Meta Page
> - Partition Counters IO
> required during execution of saveStoreMetadata() & markCheckpointBegin()
> If this page is not available in memory, it is loaded from disk.
> But such loads are done while holding checkpointLock (in write mode).
> Example of timing:
> - checkpointLockWait=75ms, checkpointLockHoldTime=2653ms, pages=696120
> All this time worker threads are not able to put any data to any cache.
> It is required to avoid eviction of such pages (evict it with lowest priority 
> than dirty page).
> (Full stacktrace) 
> {noformat} db-checkpoint-thread-#40%checkpoint.IgniteMassLoadSandboxTest1% 
> Id=63 WAITING  
>   
> at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:324)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:306)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:291)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:656)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:576)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:130)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.saveMetadata(PagesList.java:301)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.saveStoreMetadata(GridCacheOffheapManager.java:196)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onCheckpointBegin(GridCacheOffheapManager.java:168)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3022)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2719)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2644)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-7222) DiscoverySpi based on Apache ZooKeeper

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7222:
-
Labels:   (was: IEP-13)

> DiscoverySpi based on Apache ZooKeeper
> --
>
> Key: IGNITE-7222
> URL: https://issues.apache.org/jira/browse/IGNITE-7222
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-6217:
-

I'm done with testing on minimal non-localhost environment. Didn't find any 
artifacts
In addition, I've updated configuration names: 
${version}-sql-${testedOperation}-${driverName}-r${rangeSize}-${backupsCount}-backup
for example: sql-insert-delete-jdbc2-r1-1-backup

[~tledkov-gridgain] I'm ready to merge

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Created] (IGNITE-7519) DataStreamer suppresses exceptions in IsolatedUpdater

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7519:
---

 Summary: DataStreamer suppresses exceptions in IsolatedUpdater
 Key: IGNITE-7519
 URL: https://issues.apache.org/jira/browse/IGNITE-7519
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


{code:java}
 catch (IgniteCheckedException ex) {
    IgniteLogger log = cache.unwrap(Ignite.class).log();
 
    U.error(log, "Failed to set initial value for cache 
entry: " + e, ex);
 }{code}
 

This is problematic because the problem is never reported to DataStreamer so it 
will be close()d with no exceptions and data loss!



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

[jira] [Created] (IGNITE-7518) Get rid of org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-7518:


 Summary: Get rid of org.jsr166.LongAdder8, 
org.jsr166.ThreadLocalRandom
 Key: IGNITE-7518
 URL: https://issues.apache.org/jira/browse/IGNITE-7518
 Project: Ignite
  Issue Type: Sub-task
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.5






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

[jira] [Comment Edited] (IGNITE-7329) .NET: Thin client: SSL

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7329 at 1/24/18 3:38 PM:
-

The question is - what to we add to {{IgniteClientConfiguration}}?
The most generic way is {{Func}}, which is roughly 
similar to {{SSLContextFactory}} in Java. Predefined implementation will be 
able to load certificates from pfx with a password.


was (Author: ptupitsyn):
The question is - what to we add to {{IgniteClientConfiguration}}?
The most generic way is {{Func}}, which is roughly 
similar to {{SSLContextFactory}} in Java.

> .NET: Thin client: SSL
> --
>
> Key: IGNITE-7329
> URL: https://issues.apache.org/jira/browse/IGNITE-7329
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Allow secure .NET thin client connection.



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

[jira] [Created] (IGNITE-7517) Get rid of org.jsr166.ConcurrentLinkedDeque8

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-7517:


 Summary: Get rid of org.jsr166.ConcurrentLinkedDeque8
 Key: IGNITE-7517
 URL: https://issues.apache.org/jira/browse/IGNITE-7517
 Project: Ignite
  Issue Type: Sub-task
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.5






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

[jira] [Comment Edited] (IGNITE-7329) .NET: Thin client: SSL

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7329 at 1/24/18 3:36 PM:
-

The question is - what to we add to {{IgniteClientConfiguration}}?
The most generic way is {{Func}}, which is roughly 
similar to {{SSLContextFactory}} in Java.


was (Author: ptupitsyn):
The question is - what to we add to {{IgniteClientConfiguration}}?
The most generic way is Func, which is roughly similar to 
{{SSLContextFactory}} in Java.

> .NET: Thin client: SSL
> --
>
> Key: IGNITE-7329
> URL: https://issues.apache.org/jira/browse/IGNITE-7329
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Allow secure .NET thin client connection.



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

[jira] [Commented] (IGNITE-7329) .NET: Thin client: SSL

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7329:


The question is - what to we add to {{IgniteClientConfiguration}}?
The most generic way is Func, which is roughly similar to 
{{SSLContextFactory}} in Java.

> .NET: Thin client: SSL
> --
>
> Key: IGNITE-7329
> URL: https://issues.apache.org/jira/browse/IGNITE-7329
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Allow secure .NET thin client connection.



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

[jira] [Created] (IGNITE-7516) Get rid of org.jsr166.ConcurrentLinkedHashMap

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-7516:


 Summary: Get rid of org.jsr166.ConcurrentLinkedHashMap
 Key: IGNITE-7516
 URL: https://issues.apache.org/jira/browse/IGNITE-7516
 Project: Ignite
  Issue Type: Sub-task
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.5






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

[jira] [Updated] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7386:
-
Description: 
|Since we're dropping java7 support there is no need now to use 
\{{LongAdder8}}, \{{ConcurrentHashMap8}}, ... 
 
We should remove all classes from \{{org.jsr166}} namespace and use 
corresponding classes from jdk8.|

  was:Since we're switching to java8 there is no need now to use these classes 
anymore.


> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> |Since we're dropping java7 support there is no need now to use 
> \{{LongAdder8}}, \{{ConcurrentHashMap8}}, ... 
>  
> We should remove all classes from \{{org.jsr166}} namespace and use 
> corresponding classes from jdk8.|



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

[jira] [Updated] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7386:
-
Summary: Get rid of LongAdder8, ConcurrentHashMap8, etc  (was: Get rid of 
org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom)

> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Since we're switching to java8 there is no need now to use these classes 
> anymore.



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

[jira] [Updated] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7513:
-
Issue Type: Sub-task  (was: Task)
Parent: IGNITE-7386

> Get rid of org.jsr166.ConcurrentHashMap8
> 
>
> Key: IGNITE-7513
> URL: https://issues.apache.org/jira/browse/IGNITE-7513
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> This class was made of ConcurrentHashMapV8, an intermediate implementation of 
> Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, 
> we'll have to check for performance implications.



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

[jira] [Commented] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova commented on IGNITE-7403:
---

[~dmagda], see my recommendations on sketches.

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png, 
> What_v4_1.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Updated] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-7403:
--
Attachment: What_v4_1.png

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png, 
> What_v4_1.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Updated] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7389:
-
Fix Version/s: 2.5

> DataStreamer hangs if exception was thrown during addData which isn't 
> IgniteException
> -
>
> Key: IGNITE-7389
> URL: https://issues.apache.org/jira/browse/IGNITE-7389
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.5
>
>
> I have written test which starts cache on one node and right after that 
> starts dataStreamer on another node. Which hangs on close method because 
> {{resFut}} will never be done. 
> {code}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4], 
> history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
>   at 
> org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
>   at 
> org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> The best solution is waiting for topology on which cache should be started.



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

[jira] [Resolved] (IGNITE-6797) Handle IO errors in LFS files

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-6797.
--
Resolution: Duplicate

> Handle IO errors in LFS files
> -
>
> Key: IGNITE-6797
> URL: https://issues.apache.org/jira/browse/IGNITE-6797
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Pavel Kovalenko
>Priority: Minor
> Attachments: IgnitePdsThreadInterruptionTest.java
>
>
> If some thread was interrupted while IO operation with LFS file (for example 
> - read page) then JVM close FileChannel of such file and mark it as closed by 
> interrupt. If next thread try to load any page from closed file it get 
> ClosedChannelException, but PageMemoryImpl first register page in segment 
> FillPageIdTable loadedPages and didn't clear it after IO error, so third 
> thread will find empty page in it and throw Unknown page type: 0 
> IgniteCheckedException.
> To fix it we should try to restore FileChannel after ClosedChannelException 
> (for first time) and stop node if we get any other exception or get some 
> error while reopening by ClosedChannelException in FilePageStore.
> Read from closed channel exception:
> {noformat}
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
> at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
> at 
> com.google.common.eventbus.AsyncEventBus.access$001(AsyncEventBus.java:34)
> at 
> com.google.common.eventbus.AsyncEventBus$1.run(AsyncEventBus.java:117)
> 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)
> Caused by: org.apache.ignite.IgniteCheckedException: Runtime failure on 
> lookup row: 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@5678e76a
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:406)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:780)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:360)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:254)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:237)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:161)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:878)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:892)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:131)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:129)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Commented] (IGNITE-6832) handle IO errors while checkpointing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6832:


Github user asfgit closed the pull request at:

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


> handle IO errors while checkpointing
> 
>
> Key: IGNITE-6832
> URL: https://issues.apache.org/jira/browse/IGNITE-6832
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.4
>
>
> If we get some IO error (like "No spece left on device") during checkpointing 
> (GridCacheDatabaseSharedManager$WriteCheckpointPages:2509) node didn't stop 
> as when get same error while writting WAL log and clients will get some "Long 
> running cache futures". We must stop node in this case! Better - add some 
> internal healthcheck and stop node anyway if  it won't pass for few times (do 
> it with different issue).



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

[jira] [Updated] (IGNITE-6797) Handle IO errors in LFS files

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-6797:
-
Fix Version/s: 2.4

> Handle IO errors in LFS files
> -
>
> Key: IGNITE-6797
> URL: https://issues.apache.org/jira/browse/IGNITE-6797
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Pavel Kovalenko
>Priority: Minor
> Fix For: 2.4
>
> Attachments: IgnitePdsThreadInterruptionTest.java
>
>
> If some thread was interrupted while IO operation with LFS file (for example 
> - read page) then JVM close FileChannel of such file and mark it as closed by 
> interrupt. If next thread try to load any page from closed file it get 
> ClosedChannelException, but PageMemoryImpl first register page in segment 
> FillPageIdTable loadedPages and didn't clear it after IO error, so third 
> thread will find empty page in it and throw Unknown page type: 0 
> IgniteCheckedException.
> To fix it we should try to restore FileChannel after ClosedChannelException 
> (for first time) and stop node if we get any other exception or get some 
> error while reopening by ClosedChannelException in FilePageStore.
> Read from closed channel exception:
> {noformat}
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
> at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
> at 
> com.google.common.eventbus.AsyncEventBus.access$001(AsyncEventBus.java:34)
> at 
> com.google.common.eventbus.AsyncEventBus$1.run(AsyncEventBus.java:117)
> 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)
> Caused by: org.apache.ignite.IgniteCheckedException: Runtime failure on 
> lookup row: 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@5678e76a
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:406)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:780)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:360)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:254)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:237)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:161)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:878)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:892)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:131)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:129)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Assigned] (IGNITE-7502) Baseline topology should affect only persistent caches

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-7502:


Assignee: Ilya Lantukh

> Baseline topology should affect only persistent caches
> --
>
> Key: IGNITE-7502
> URL: https://issues.apache.org/jira/browse/IGNITE-7502
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.4
>
>
> Non-persistent caches shouldn't restrict affinity assignment to baseline 
> nodes.



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

[jira] [Updated] (IGNITE-7403) Improve content on What's Ignite page

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-7403:
--
Attachment: What_v4.png

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png, What_v3.png, What_v4.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Updated] (IGNITE-6832) handle IO errors while checkpointing

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-6832:
-
Fix Version/s: 2.4

> handle IO errors while checkpointing
> 
>
> Key: IGNITE-6832
> URL: https://issues.apache.org/jira/browse/IGNITE-6832
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.4
>
>
> If we get some IO error (like "No spece left on device") during checkpointing 
> (GridCacheDatabaseSharedManager$WriteCheckpointPages:2509) node didn't stop 
> as when get same error while writting WAL log and clients will get some "Long 
> running cache futures". We must stop node in this case! Better - add some 
> internal healthcheck and stop node anyway if  it won't pass for few times (do 
> it with different issue).



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

[jira] [Assigned] (IGNITE-7464) Add property to configure time between node connection attempts

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov reassigned IGNITE-7464:
--

Assignee: Stanislav Lukyanov

> Add property to configure time between node connection attempts
> ---
>
> Key: IGNITE-7464
> URL: https://issues.apache.org/jira/browse/IGNITE-7464
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> Currently when a node attempts to join the cluster, the connection algorithm 
> will be repeated until successful or timed out. The time between the attempts 
> is hardcoded - 2 seconds.
> It might be useful to adjust that time via a property (say, in SPI config) 
> based on the network quality, application constraints, etc.



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-425:
-

[~NIzhikov],

Please, see my comments at upsource.

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



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

[jira] [Updated] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7515:
---
Description: 
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 
{{
AC_CACHE_CHECK(
  [for support of strerror_r that returns int],
  [odbc_have_int_strerror_r],
  [AC_RUN_IFELSE(
[AC_LANG_SOURCE[
  #include 
  #include 

  int main(int argc, char** argv) {
char buf[256] = {0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
  }
]],
[odbc_have_int_strerror_r=yes],
[odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
  AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
}}

  was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{quote}
AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)
{
char buf[256];

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
{quote}


> ODBC: Socket error messages may be missing on linux
> ---
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Sergey Kalashnikov
>Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 
> 2 flavors. 
>  One returns error code and another character string.
>  Current code seems to expect the XSI version, which returns an int.
>  But if we happen to compile against the other version, the error messages 
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two 
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro 
> to tell what {{strerror_r()}} variant we have.
>  
> {{
> AC_CACHE_CHECK(
>   [for support of strerror_r that returns int],
>   [odbc_have_int_strerror_r],
>   [AC_RUN_IFELSE(
> [AC_LANG_SOURCE[
>   #include 
>   #include 
>   int main(int argc, char** argv) {
> char buf[256] = {0};
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
>   }
> ]],
> [odbc_have_int_strerror_r=yes],
> [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
>   AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
> strerror_r])
> }}



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

[jira] [Updated] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7515:
---
Description: 
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{quote}
AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)
{
char buf[256];

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
{quote}

  was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{quote}
AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)
{
char buf[256] = \\{0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
{quote}


> ODBC: Socket error messages may be missing on linux
> ---
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Sergey Kalashnikov
>Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 
> 2 flavors. 
>  One returns error code and another character string.
>  Current code seems to expect the XSI version, which returns an int.
>  But if we happen to compile against the other version, the error messages 
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two 
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro 
> to tell what {{strerror_r()}} variant we have.
>  
> {quote}
> AC_CACHE_CHECK(
>  [for support of strerror_r that returns int],
>  [odbc_have_int_strerror_r],
>  [AC_RUN_IFELSE(
>  [AC_LANG_SOURCE[
>  #include 
>  #include 
> int main(int argc, char** argv)
> {
> char buf[256];
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
>  }
>  ]],
>  [odbc_have_int_strerror_r=yes],
>  [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
>  AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
> strerror_r])
> {quote}



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

[jira] [Updated] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7515:
---
Description: 
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{quote}
AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)
{
char buf[256] = \\{0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
{quote}

  was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{quote}
AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)
{
char buf[256] = {0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
{quote}


> ODBC: Socket error messages may be missing on linux
> ---
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Sergey Kalashnikov
>Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 
> 2 flavors. 
>  One returns error code and another character string.
>  Current code seems to expect the XSI version, which returns an int.
>  But if we happen to compile against the other version, the error messages 
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two 
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro 
> to tell what {{strerror_r()}} variant we have.
>  
> {quote}
> AC_CACHE_CHECK(
>  [for support of strerror_r that returns int],
>  [odbc_have_int_strerror_r],
>  [AC_RUN_IFELSE(
>  [AC_LANG_SOURCE[
>  #include 
>  #include 
> int main(int argc, char** argv)
> {
> char buf[256] = \\{0};
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
>  }
>  ]],
>  [odbc_have_int_strerror_r=yes],
>  [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
>  AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
> strerror_r])
> {quote}



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

[jira] [Updated] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7515:
---
Description: 
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{quote}
AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)
{
char buf[256] = {0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])
{quote}

  was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)

{

char buf[256] = \\{0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])


> ODBC: Socket error messages may be missing on linux
> ---
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Sergey Kalashnikov
>Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 
> 2 flavors. 
>  One returns error code and another character string.
>  Current code seems to expect the XSI version, which returns an int.
>  But if we happen to compile against the other version, the error messages 
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two 
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro 
> to tell what {{strerror_r()}} variant we have.
>  
> {quote}
> AC_CACHE_CHECK(
>  [for support of strerror_r that returns int],
>  [odbc_have_int_strerror_r],
>  [AC_RUN_IFELSE(
>  [AC_LANG_SOURCE[
>  #include 
>  #include 
> int main(int argc, char** argv)
> {
> char buf[256] = {0};
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
>  }
>  ]],
>  [odbc_have_int_strerror_r=yes],
>  [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
>  AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
> strerror_r])
> {quote}



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

[jira] [Updated] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7515:
---
Description: 
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv) {
 char buf[256] = \{0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])

  was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
One returns error code and another character string.
Current code seems to expect the XSI version, which returns an int.
But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{{AC_CACHE_CHECK(}}
{{ [for support of strerror_r that returns int],}}
{{ [odbc_have_int_strerror_r],}}
{{ [AC_RUN_IFELSE(}}
{{ [AC_LANG_SOURCE[}}
{{ #include }}
{{ #include }}{{int main(int argc, char** argv) {}}
{{ char buf[256] = \{0};}}{{int ret = strerror_r(ENOMEM, buf, 
sizeof(buf));}}{{return ret;}}
{{ }}}
{{ ]],}}
{{ [odbc_have_int_strerror_r=yes],}}
{{ [odbc_have_int_strerror_r=no])])}}{{if test "$odbc_have_int_strerror_r" = 
"yes"; then}}
{{ AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])}}


> ODBC: Socket error messages may be missing on linux
> ---
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Sergey Kalashnikov
>Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 
> 2 flavors. 
>  One returns error code and another character string.
>  Current code seems to expect the XSI version, which returns an int.
>  But if we happen to compile against the other version, the error messages 
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two 
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro 
> to tell what {{strerror_r()}} variant we have.
>  
> AC_CACHE_CHECK(
>  [for support of strerror_r that returns int],
>  [odbc_have_int_strerror_r],
>  [AC_RUN_IFELSE(
>  [AC_LANG_SOURCE[
>  #include 
>  #include 
> int main(int argc, char** argv) {
>  char buf[256] = \{0};
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
>  }
>  ]],
>  [odbc_have_int_strerror_r=yes],
>  [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
>  AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
> strerror_r])



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

[jira] [Updated] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7515:
---
Description: 
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv)

{

char buf[256] = \\{0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])

  was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
 One returns error code and another character string.
 Current code seems to expect the XSI version, which returns an int.
 But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

AC_CACHE_CHECK(
 [for support of strerror_r that returns int],
 [odbc_have_int_strerror_r],
 [AC_RUN_IFELSE(
 [AC_LANG_SOURCE[
 #include 
 #include 

int main(int argc, char** argv) {
 char buf[256] = \{0};

int ret = strerror_r(ENOMEM, buf, sizeof(buf));

return ret;
 }
 ]],
 [odbc_have_int_strerror_r=yes],
 [odbc_have_int_strerror_r=no])])

if test "$odbc_have_int_strerror_r" = "yes"; then
 AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])


> ODBC: Socket error messages may be missing on linux
> ---
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Sergey Kalashnikov
>Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 
> 2 flavors. 
>  One returns error code and another character string.
>  Current code seems to expect the XSI version, which returns an int.
>  But if we happen to compile against the other version, the error messages 
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two 
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro 
> to tell what {{strerror_r()}} variant we have.
>  
> AC_CACHE_CHECK(
>  [for support of strerror_r that returns int],
>  [odbc_have_int_strerror_r],
>  [AC_RUN_IFELSE(
>  [AC_LANG_SOURCE[
>  #include 
>  #include 
> int main(int argc, char** argv)
> {
> char buf[256] = \\{0};
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
>  }
>  ]],
>  [odbc_have_int_strerror_r=yes],
>  [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
>  AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
> strerror_r])



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

[jira] [Created] (IGNITE-7515) ODBC: Socket error messages may be missing on linux

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-7515:
--

 Summary: ODBC: Socket error messages may be missing on linux
 Key: IGNITE-7515
 URL: https://issues.apache.org/jira/browse/IGNITE-7515
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.3
Reporter: Sergey Kalashnikov


Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2 
flavors. 
One returns error code and another character string.
Current code seems to expect the XSI version, which returns an int.
But if we happen to compile against the other version, the error messages will 
be missing from the diagnostic messages and logs.

The man page for {{strerror_r()}} provides the macros to distinguish the two 
versions, but that is not very portable.

I suggest that we create a test in {{configure.ac}} to define specific macro to 
tell what {{strerror_r()}} variant we have.

 

{{AC_CACHE_CHECK(}}
{{ [for support of strerror_r that returns int],}}
{{ [odbc_have_int_strerror_r],}}
{{ [AC_RUN_IFELSE(}}
{{ [AC_LANG_SOURCE[}}
{{ #include }}
{{ #include }}{{int main(int argc, char** argv) {}}
{{ char buf[256] = \{0};}}{{int ret = strerror_r(ENOMEM, buf, 
sizeof(buf));}}{{return ret;}}
{{ }}}
{{ ]],}}
{{ [odbc_have_int_strerror_r=yes],}}
{{ [odbc_have_int_strerror_r=no])])}}{{if test "$odbc_have_int_strerror_r" = 
"yes"; then}}
{{ AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int 
strerror_r])}}



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

[jira] [Commented] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-7389:
--

[~avinogradov],

I've changed my patch as you suggested. Please review again.

> DataStreamer hangs if exception was thrown during addData which isn't 
> IgniteException
> -
>
> Key: IGNITE-7389
> URL: https://issues.apache.org/jira/browse/IGNITE-7389
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Major
>
> I have written test which starts cache on one node and right after that 
> starts dataStreamer on another node. Which hangs on close method because 
> {{resFut}} will never be done. 
> {code}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4], 
> history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
>   at 
> org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
>   at 
> org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> The best solution is waiting for topology on which cache should be started.



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

[jira] [Assigned] (IGNITE-7504) Decision tree documentation

[Artem Malykh (JIRA)]

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

Artem Malykh reassigned IGNITE-7504:


Assignee: Denis Magda  (was: Artem Malykh)

> Decision tree documentation
> ---
>
> Key: IGNITE-7504
> URL: https://issues.apache.org/jira/browse/IGNITE-7504
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, ml
>Reporter: Yury Babak
>Assignee: Denis Magda
>Priority: Major
>  Labels: documentation
> Fix For: 2.4
>
>
> We want to add Decision tree documentation



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

[jira] [Commented] (IGNITE-7504) Decision tree documentation

[Artem Malykh (JIRA)]

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

Artem Malykh commented on IGNITE-7504:
--

[~dmagda] , please review the doc: 
[https://dash.readme.io/project/apacheignite/v2.3/docs/decision-trees-24] .

> Decision tree documentation
> ---
>
> Key: IGNITE-7504
> URL: https://issues.apache.org/jira/browse/IGNITE-7504
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, ml
>Reporter: Yury Babak
>Assignee: Artem Malykh
>Priority: Major
>  Labels: documentation
> Fix For: 2.4
>
>
> We want to add Decision tree documentation



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

[jira] [Assigned] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7031:


Assignee: Alexander Kalinin  (was: Alexey Kuznetsov)

I do not like this fix.

Please discuss with [~Klaster_1] how we can fix Confirm service.

May be do not reject on cancelation? And return false for example?

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Commented] (IGNITE-7512) Variable updated should be checked for null before invocation of ctx.validateKeyAndValue(entry.key(), updated) in GridDhtAtomicCache.updateWithBatch

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7512:


GitHub user skalashnikov opened a pull request:

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

IGNITE-7512: fixed NPE when entry processor removes entry and queries…

… are enabled on cache.

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

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

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

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


commit 0338e523f1e138d0acace141083258cdbdb8647d
Author: skalashnikov 
Date:   2018-01-24T13:59:39Z

IGNITE-7512: fixed NPE when entry processor removes entry and queries are 
enabled on cache.




> Variable updated should be checked for null before invocation of 
> ctx.validateKeyAndValue(entry.key(), updated) in 
> GridDhtAtomicCache.updateWithBatch
> 
>
> Key: IGNITE-7512
> URL: https://issues.apache.org/jira/browse/IGNITE-7512
> Project: Ignite
>  Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Sergey Kalashnikov
>Priority: Major
>
> Or it could lead to the NPE



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

[jira] [Assigned] (IGNITE-7512) Variable updated should be checked for null before invocation of ctx.validateKeyAndValue(entry.key(), updated) in GridDhtAtomicCache.updateWithBatch

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-7512:
--

Assignee: Sergey Kalashnikov

> Variable updated should be checked for null before invocation of 
> ctx.validateKeyAndValue(entry.key(), updated) in 
> GridDhtAtomicCache.updateWithBatch
> 
>
> Key: IGNITE-7512
> URL: https://issues.apache.org/jira/browse/IGNITE-7512
> Project: Ignite
>  Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Sergey Kalashnikov
>Priority: Major
>
> Or it could lead to the NPE



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

[jira] [Created] (IGNITE-7514) Affinity assignment isn't recalculated if PRIMARY node isn't OWNER

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-7514:


 Summary: Affinity assignment isn't recalculated if PRIMARY node 
isn't OWNER
 Key: IGNITE-7514
 URL: https://issues.apache.org/jira/browse/IGNITE-7514
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh
 Fix For: 2.4


It can happen after activation or recovery and leads to multiple exceptions / 
assertions during cache operations mapping.



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

[jira] [Commented] (IGNITE-7443) ODBC: use native batching capabilities on the server side

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7443:


Github user asfgit closed the pull request at:

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


> ODBC: use native batching capabilities on the server side
> -
>
> Key: IGNITE-7443
> URL: https://issues.apache.org/jira/browse/IGNITE-7443
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.4
>
>
> We introduced native batching feature recently which could speedup batched 
> requests by a factor of 2-3. However, this optimization is not applied for 
> ODBC for now. Need to fix that.



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

[jira] [Assigned] (IGNITE-7362) ODBC: Third party libraries truncate any inserted varlen data to ColumnSize

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-7362:
---

Assignee: Igor Sapego

> ODBC: Third party libraries truncate any inserted varlen data to ColumnSize
> ---
>
> Key: IGNITE-7362
> URL: https://issues.apache.org/jira/browse/IGNITE-7362
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Third-party frameworks and ODBC bindings for different languages use metadata 
> requests results for columns (such as {{SQL_COLUMN_PRECISION}}) to truncate 
> varlen data, inserted by the user, which is only 64 by default. 
> {code}
>  ini_set("display_errors", 1);
> error_reporting(E_ALL);
> try {
> $ignite = new PDO('odbc:Apache Ignite');
> $ignite->setAttribute(PDO::ATTR_ERRMODE, 
> PDO::ERRMODE_EXCEPTION);
> $sql = 'CREATE TABLE IF NOT EXISTS test_md5 (id int PRIMARY 
> KEY, userkey
> LONGVARCHAR, server LONGVARCHAR, tsession LONGVARCHAR, tpost LONGVARCHAR,
> tget LONGVARCHAR, adddate int) WITH
> "atomicity=transactional,cachegroup=somegroup"';
> $ignite->exec($sql);
> for($i=0; $i <= 10; $i++){
> $dbs = $ignite->prepare("INSERT INTO test_md5 (id, 
> userkey, server,
> tsession, tpost, tget, adddate) VALUES ($i, 'Lorem ipsum dolor sit amet,
> consectetur adipiscing elit, sed do elit, sed', 'b', 'c', 'd', 'e', 1)");
> $dbs->execute();
> }
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
> ?>
> {code}



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

[jira] [Resolved] (IGNITE-7338) can get value by entry.getValue but cann't get value by cache.get(entry.getKey)

[dean (JIRA)]

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

dean resolved IGNITE-7338.
--
Resolution: Fixed

> can get value by entry.getValue but cann't get value by 
> cache.get(entry.getKey)
> ---
>
> Key: IGNITE-7338
> URL: https://issues.apache.org/jira/browse/IGNITE-7338
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: dean
>Priority: Critical
>
> bossapp@Linux-Power-NB-AltiDB2-XT:/home/bossapp6$java -version
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxp6470_27sr4fp15-20171116_01(SR4 
> FP15))
> IBM J9 VM (build 2.7, JRE 1.7.0 Linux ppc64-64 Compressed References 
> 20171011_366929 (JIT enabled, AOT enabled)
> J9VM - R27_Java727_SR4_20171011_1720_B366929
> JIT  - tr.r13.java_20171011_366929
> GC   - R27_Java727_SR4_20171011_1720_B366929_CMPRSS
> J9CL - 20171011_366929)
> JCL - 20171109_01 based on Oracle jdk7u161-b13
> bossapp@Linux-Power-NB-AltiDB2-XT:/home/bossapp6$lsb_release -a
> LSB Version:  
> :core-4.0-noarch:core-4.0-ppc64:graphics-4.0-noarch:graphics-4.0-ppc64:printing-4.0-noarch:printing-4.0-ppc64
> Distributor ID:   n/a
> Description:  redhat-4 
> Release:  n/a
> Codename: n/a
> {color:#d04437}test code:{color}
> if(cacheName.equalsIgnoreCase("tariff-ccb_cdr_charge_rule")){
> CcbCdrChargeRuleKey ccbCdrChargeRuleKey = new CcbCdrChargeRuleKey();
> ccbCdrChargeRuleKey.setFileType("573");
> ccbCdrChargeRuleKey.setSourceType("5");
> Object cacheDate = ignite.cache(cacheName).get(ccbCdrChargeRuleKey);
> logger.debug(LogProperty.LOGTYPE_DETAIL, ccbCdrChargeRuleKey+"Object 
> eKey:" + cacheDate );
> ccbCdrChargeRuleKey.setFileType("1233");
> ccbCdrChargeRuleKey.setSourceType("14");
> Object cacheDate1 = ignite.cache(cacheName).get(ccbCdrChargeRuleKey);
> logger.debug(LogProperty.LOGTYPE_DETAIL, "Object1:" + cacheDate1  
> +"ccbCdrChargeRuleKey"+ccbCdrChargeRuleKey.hashCode());
> IgniteCache cacheDate3 = ignite.cache(cacheName);
> for (Cache.Entry e : cacheDate3) {
>  List cacheModelList = (List) 
> cacheDate3.get(e.getKey());
> 
> {color:#d04437}logger.debug(LogProperty.LOGTYPE_DETAIL,"e.getKey():"+e.getKey()
>  +" cacheModelList:" + cacheModelList );
> logger.debug(LogProperty.LOGTYPE_DETAIL,"e.getValue():"+e.getValue() 
> );{color}
>}
> }
> results:
> 2017-12-2819:17:36,322||DEBUG||frame_thread_nodestart| 
> com.newland.boss.cloud.commons.igniteclient.PlatformInitIgniteClient.test(PlatformInitIgniteClient.java:337)|
>  {color:#d04437}e.getKey():573,5 cacheModelList:null{color}
> 2017-12-2819:17:36,323||DEBUG||frame_thread_nodestart| 
> com.newland.boss.cloud.commons.igniteclient.PlatformInitIgniteClient.test(PlatformInitIgniteClient.java:338)|
>  
> {color:#d04437}e.getValue():[CcbCdrChargeRule{ccbCdrChargeRuleKey=573,5,
>  bizDomainCode='3', conditionGroupId=, fileType='573', 
> preProcessUnitClass='PreProcessGprs', priority=1, rateItemTypes='6', 
> ratingClass='RatingGprs', ruleDesc='国际出访GPRS 专网', sourceType='5', 
> userTariffClass='GetUserTariffInfoGprs', version='0.0.1'}]{color}



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

[jira] [Commented] (IGNITE-7338) can get value by entry.getValue but cann't get value by cache.get(entry.getKey)

[dean (JIRA)]

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

dean commented on IGNITE-7338:
--

@[~andrey-kuznetsov]  i have resolve this problem by rewrite the hashcode 
method in this way：

@Override
 public int hashCode() {
 int result = fileType.hashCode();
 result = (result << 5) - result + sourceType.hashCode();
 return result;
 }

 

thanks all

 

> can get value by entry.getValue but cann't get value by 
> cache.get(entry.getKey)
> ---
>
> Key: IGNITE-7338
> URL: https://issues.apache.org/jira/browse/IGNITE-7338
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: dean
>Priority: Critical
>
> bossapp@Linux-Power-NB-AltiDB2-XT:/home/bossapp6$java -version
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxp6470_27sr4fp15-20171116_01(SR4 
> FP15))
> IBM J9 VM (build 2.7, JRE 1.7.0 Linux ppc64-64 Compressed References 
> 20171011_366929 (JIT enabled, AOT enabled)
> J9VM - R27_Java727_SR4_20171011_1720_B366929
> JIT  - tr.r13.java_20171011_366929
> GC   - R27_Java727_SR4_20171011_1720_B366929_CMPRSS
> J9CL - 20171011_366929)
> JCL - 20171109_01 based on Oracle jdk7u161-b13
> bossapp@Linux-Power-NB-AltiDB2-XT:/home/bossapp6$lsb_release -a
> LSB Version:  
> :core-4.0-noarch:core-4.0-ppc64:graphics-4.0-noarch:graphics-4.0-ppc64:printing-4.0-noarch:printing-4.0-ppc64
> Distributor ID:   n/a
> Description:  redhat-4 
> Release:  n/a
> Codename: n/a
> {color:#d04437}test code:{color}
> if(cacheName.equalsIgnoreCase("tariff-ccb_cdr_charge_rule")){
> CcbCdrChargeRuleKey ccbCdrChargeRuleKey = new CcbCdrChargeRuleKey();
> ccbCdrChargeRuleKey.setFileType("573");
> ccbCdrChargeRuleKey.setSourceType("5");
> Object cacheDate = ignite.cache(cacheName).get(ccbCdrChargeRuleKey);
> logger.debug(LogProperty.LOGTYPE_DETAIL, ccbCdrChargeRuleKey+"Object 
> eKey:" + cacheDate );
> ccbCdrChargeRuleKey.setFileType("1233");
> ccbCdrChargeRuleKey.setSourceType("14");
> Object cacheDate1 = ignite.cache(cacheName).get(ccbCdrChargeRuleKey);
> logger.debug(LogProperty.LOGTYPE_DETAIL, "Object1:" + cacheDate1  
> +"ccbCdrChargeRuleKey"+ccbCdrChargeRuleKey.hashCode());
> IgniteCache cacheDate3 = ignite.cache(cacheName);
> for (Cache.Entry e : cacheDate3) {
>  List cacheModelList = (List) 
> cacheDate3.get(e.getKey());
> 
> {color:#d04437}logger.debug(LogProperty.LOGTYPE_DETAIL,"e.getKey():"+e.getKey()
>  +" cacheModelList:" + cacheModelList );
> logger.debug(LogProperty.LOGTYPE_DETAIL,"e.getValue():"+e.getValue() 
> );{color}
>}
> }
> results:
> 2017-12-2819:17:36,322||DEBUG||frame_thread_nodestart| 
> com.newland.boss.cloud.commons.igniteclient.PlatformInitIgniteClient.test(PlatformInitIgniteClient.java:337)|
>  {color:#d04437}e.getKey():573,5 cacheModelList:null{color}
> 2017-12-2819:17:36,323||DEBUG||frame_thread_nodestart| 
> com.newland.boss.cloud.commons.igniteclient.PlatformInitIgniteClient.test(PlatformInitIgniteClient.java:338)|
>  
> {color:#d04437}e.getValue():[CcbCdrChargeRule{ccbCdrChargeRuleKey=573,5,
>  bizDomainCode='3', conditionGroupId=, fileType='573', 
> preProcessUnitClass='PreProcessGprs', priority=1, rateItemTypes='6', 
> ratingClass='RatingGprs', ruleDesc='国际出访GPRS 专网', sourceType='5', 
> userTariffClass='GetUserTariffInfoGprs', version='0.0.1'}]{color}



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

[jira] [Assigned] (IGNITE-7492) Implement metrics for Memory Regions in UI tools

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7492:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master and 2.4.

> Implement metrics for Memory Regions in UI tools
> 
>
> Key: IGNITE-7492
> URL: https://issues.apache.org/jira/browse/IGNITE-7492
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6920 for list of metrics.



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

[jira] [Resolved] (IGNITE-7492) Implement metrics for Memory Regions in UI tools

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov resolved IGNITE-7492.

Resolution: Fixed

> Implement metrics for Memory Regions in UI tools
> 
>
> Key: IGNITE-7492
> URL: https://issues.apache.org/jira/browse/IGNITE-7492
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6920 for list of metrics.



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

[jira] [Commented] (IGNITE-7492) Implement metrics for Memory Regions in UI tools

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7492:


Tested, no issues noticed

> Implement metrics for Memory Regions in UI tools
> 
>
> Key: IGNITE-7492
> URL: https://issues.apache.org/jira/browse/IGNITE-7492
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6920 for list of metrics.



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

[jira] [Assigned] (IGNITE-7492) Implement metrics for Memory Regions in UI tools

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7492:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Implement metrics for Memory Regions in UI tools
> 
>
> Key: IGNITE-7492
> URL: https://issues.apache.org/jira/browse/IGNITE-7492
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6920 for list of metrics.



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

[jira] [Updated] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7513:
-
Description: This class was made of ConcurrentHashMapV8, an intermediate 
implementation of Java8's ConcurrentHashMap. Now we should switch to standard 
CHM. Possibly, we'll have to check for performance implications.  (was: This 
class was made of ConcurrentHashMapV8, an intermadiate implementation of 
Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, 
we'll have to check for performance implications.)

> Get rid of org.jsr166.ConcurrentHashMap8
> 
>
> Key: IGNITE-7513
> URL: https://issues.apache.org/jira/browse/IGNITE-7513
> Project: Ignite
>  Issue Type: Task
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> This class was made of ConcurrentHashMapV8, an intermediate implementation of 
> Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, 
> we'll have to check for performance implications.



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

[jira] [Commented] (IGNITE-7503) MLP documentation

[Artem Malykh (JIRA)]

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

Artem Malykh commented on IGNITE-7503:
--

[~dmagda] , please review the doc: 
https://dash.readme.io/project/apacheignite/v2.3/docs/multilayer-perceptron

> MLP documentation
> -
>
> Key: IGNITE-7503
> URL: https://issues.apache.org/jira/browse/IGNITE-7503
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, ml
>Reporter: Yury Babak
>Assignee: Denis Magda
>Priority: Major
>  Labels: documentaion
> Fix For: 2.4
>
>
> A need to add documentation about MLP



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

[jira] [Assigned] (IGNITE-7503) MLP documentation

[Artem Malykh (JIRA)]

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

Artem Malykh reassigned IGNITE-7503:


Assignee: Denis Magda  (was: Artem Malykh)

> MLP documentation
> -
>
> Key: IGNITE-7503
> URL: https://issues.apache.org/jira/browse/IGNITE-7503
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, ml
>Reporter: Yury Babak
>Assignee: Denis Magda
>Priority: Major
>  Labels: documentaion
> Fix For: 2.4
>
>
> A need to add documentation about MLP



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

[jira] [Created] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-7513:


 Summary: Get rid of org.jsr166.ConcurrentHashMap8
 Key: IGNITE-7513
 URL: https://issues.apache.org/jira/browse/IGNITE-7513
 Project: Ignite
  Issue Type: Task
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.5


This class was made of ConcurrentHashMapV8, an intermadiate implementation of 
Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, 
we'll have to check for performance implications.



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

[jira] [Updated] (IGNITE-7386) Get rid of org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7386:
-
Summary: Get rid of org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom  
(was: Get rid of LongAdder8, ConcurrentHashMap8, etc)

> Get rid of org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Since we're dropping java7 support there is no need now to use 
> {{LongAdder8}}, {{ConcurrentHashMap8}}, ...
> We should remove all classes from {{org.jsr166}} namespace and use 
> corresponding classes from jdk8.



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

[jira] [Created] (IGNITE-7512) Variable updated should be checked for null before invocation of ctx.validateKeyAndValue(entry.key(), updated) in GridDhtAtomicCache.updateWithBatch

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-7512:
-

 Summary: Variable updated should be checked for null before 
invocation of ctx.validateKeyAndValue(entry.key(), updated) in 
GridDhtAtomicCache.updateWithBatch
 Key: IGNITE-7512
 URL: https://issues.apache.org/jira/browse/IGNITE-7512
 Project: Ignite
  Issue Type: Bug
Reporter: Evgenii Zhuravlev


Or it could lead to the NPE



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

[jira] [Created] (IGNITE-7511) FCM documentation

[Yury Babak (JIRA)]

Yury Babak created IGNITE-7511:
--

 Summary: FCM documentation
 Key: IGNITE-7511
 URL: https://issues.apache.org/jira/browse/IGNITE-7511
 Project: Ignite
  Issue Type: Task
  Components: documentation, ml
Reporter: Yury Babak
Assignee: Oleg Ignatenko
 Fix For: 2.4


We need to update documentation on readme.io and add section about FCM



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

[jira] [Assigned] (IGNITE-7492) Implement metrics for Memory Regions in UI tools

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7492:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Implement metrics for Memory Regions in UI tools
> 
>
> Key: IGNITE-7492
> URL: https://issues.apache.org/jira/browse/IGNITE-7492
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6920 for list of metrics.



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

[jira] [Updated] (IGNITE-7506) GridClusterStateProcessor#compatibilityMode flag never gets reset to false

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7506:

Component/s: persistence

> GridClusterStateProcessor#compatibilityMode flag never gets reset to false
> --
>
> Key: IGNITE-7506
> URL: https://issues.apache.org/jira/browse/IGNITE-7506
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> When Ignite node of version 2.4+ joins cluster with older versions of Ignite 
> running it sets *compatibilityMode* flag to handle **cluster state in a 
> special way (excluding BaselineTopology from discovery exchange process and 
> so on).
> But when all old nodes are turned off there is no way except full cluster 
> restart to enable setting very first **BaselineTopology.
> This should be addressed and some way to exit compatibilityMode without full 
> cluster restart should be provided.



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

[jira] [Commented] (IGNITE-7492) Implement metrics for Memory Regions in UI tools

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-7492:
---

In *node* command implemented showing of data region metrics in extended mode.

> Implement metrics for Memory Regions in UI tools
> 
>
> Key: IGNITE-7492
> URL: https://issues.apache.org/jira/browse/IGNITE-7492
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6920 for list of metrics.



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

[jira] [Updated] (IGNITE-7506) GridClusterStateProcessor#compatibilityMode flag never gets reset to false

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7506:

Affects Version/s: 2.4

> GridClusterStateProcessor#compatibilityMode flag never gets reset to false
> --
>
> Key: IGNITE-7506
> URL: https://issues.apache.org/jira/browse/IGNITE-7506
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> When Ignite node of version 2.4+ joins cluster with older versions of Ignite 
> running it sets *compatibilityMode* flag to handle **cluster state in a 
> special way (excluding BaselineTopology from discovery exchange process and 
> so on).
> But when all old nodes are turned off there is no way except full cluster 
> restart to enable setting very first **BaselineTopology.
> This should be addressed and some way to exit compatibilityMode without full 
> cluster restart should be provided.



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

[jira] [Comment Edited] (IGNITE-7506) GridClusterStateProcessor#compatibilityMode flag never gets reset to false

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov edited comment on IGNITE-7506 at 1/24/18 8:41 AM:
--

Patch is ready, [TC 
status|https://ci.ignite.apache.org/viewQueued.html?itemId=1057419=queuedBuildOverviewTab]
 looks acceptable (test failures count matches with the same in master branch).


was (Author: sergey-chugunov):
Patch is ready, TC status looks acceptable (test failures count matches with 
the same in master branch): 

 

https://ci.ignite.apache.org/viewQueued.html?itemId=1057419=queuedBuildOverviewTab

> GridClusterStateProcessor#compatibilityMode flag never gets reset to false
> --
>
> Key: IGNITE-7506
> URL: https://issues.apache.org/jira/browse/IGNITE-7506
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> When Ignite node of version 2.4+ joins cluster with older versions of Ignite 
> running it sets *compatibilityMode* flag to handle **cluster state in a 
> special way (excluding BaselineTopology from discovery exchange process and 
> so on).
> But when all old nodes are turned off there is no way except full cluster 
> restart to enable setting very first **BaselineTopology.
> This should be addressed and some way to exit compatibilityMode without full 
> cluster restart should be provided.



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

[jira] [Commented] (IGNITE-7506) GridClusterStateProcessor#compatibilityMode flag never gets reset to false

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-7506:
-

Patch is ready, TC status looks acceptable (test failures count matches with 
the same in master branch): 

 

https://ci.ignite.apache.org/viewQueued.html?itemId=1057419=queuedBuildOverviewTab

> GridClusterStateProcessor#compatibilityMode flag never gets reset to false
> --
>
> Key: IGNITE-7506
> URL: https://issues.apache.org/jira/browse/IGNITE-7506
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> When Ignite node of version 2.4+ joins cluster with older versions of Ignite 
> running it sets *compatibilityMode* flag to handle **cluster state in a 
> special way (excluding BaselineTopology from discovery exchange process and 
> so on).
> But when all old nodes are turned off there is no way except full cluster 
> restart to enable setting very first **BaselineTopology.
> This should be addressed and some way to exit compatibilityMode without full 
> cluster restart should be provided.



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

[jira] [Updated] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7031:
-
Fix Version/s: 2.5

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Commented] (IGNITE-7392) visorcmd: missed word 'factory' in the lables

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7392:


Tested

> visorcmd: missed word 'factory' in the lables
> -
>
> Key: IGNITE-7392
> URL: https://issues.apache.org/jira/browse/IGNITE-7392
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> We need to add 'factory' into label 'Eviction policy' and 'Near eviction 
> policy'
> !screenshot-1.png!



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

[jira] [Assigned] (IGNITE-7392) visorcmd: missed word 'factory' in the lables

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7392:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> visorcmd: missed word 'factory' in the lables
> -
>
> Key: IGNITE-7392
> URL: https://issues.apache.org/jira/browse/IGNITE-7392
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> We need to add 'factory' into label 'Eviction policy' and 'Near eviction 
> policy'
> !screenshot-1.png!



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