[jira] [Resolved] (IGNITE-9595) Web console: invisible checkbox is visible inqueries
[ https://issues.apache.org/jira/browse/IGNITE-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9595. -- Resolution: Duplicate Duplicate of IGNITE-9596 > Web console: invisible checkbox is visible inqueries > > > Key: IGNITE-9595 > URL: https://issues.apache.org/jira/browse/IGNITE-9595 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > > How to reproduce: > 1. Connect to a cluster > 2. Go to queries > 3. Click on "+Add scan" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9595) Web console: invisible checkbox is visible inqueries
[ https://issues.apache.org/jira/browse/IGNITE-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9595: - Ignite Flags: (was: Docs Required) > Web console: invisible checkbox is visible inqueries > > > Key: IGNITE-9595 > URL: https://issues.apache.org/jira/browse/IGNITE-9595 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > > How to reproduce: > 1. Connect to a cluster > 2. Go to queries > 3. Click on "+Add scan" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9594) Regression in release build for ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-9594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16614350#comment-16614350 ] Alexey Kuznetsov commented on IGNITE-9594: -- Fixed release build. Diff: [https://github.com/apache/ignite/commit/e18d7d592e1339f9e2dd4664f168a5eac7639530] > Regression in release build for ignite-zookeeper module > --- > > Key: IGNITE-9594 > URL: https://issues.apache.org/jira/browse/IGNITE-9594 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryZookeeperIpFinder and started from binary build. > > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9511) Update styling for modal windows
[ https://issues.apache.org/jira/browse/IGNITE-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9511: - Ignite Flags: (was: Docs Required) Component/s: wizards > Update styling for modal windows > > > Key: IGNITE-9511 > URL: https://issues.apache.org/jira/browse/IGNITE-9511 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Currently we have two way of styles - modern (confirmation, etc) and old > styled (getting started, messages ect). > The modals have to be consistent. Let's update them with new style. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9511) Update styling for modal windows
[ https://issues.apache.org/jira/browse/IGNITE-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16614338#comment-16614338 ] Ilya Borisov commented on IGNITE-9511: -- [~alexdel] please do the following: 1. Put the _theme--ignite_ class back, lack of it causes regression for some modals. 2. Swap _.modal-body_ padding/margin back in _modal/index.scss_, it causes regressions too. > Update styling for modal windows > > > Key: IGNITE-9511 > URL: https://issues.apache.org/jira/browse/IGNITE-9511 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Currently we have two way of styles - modern (confirmation, etc) and old > styled (getting started, messages ect). > The modals have to be consistent. Let's update them with new style. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9509) Created one facade for existing ui-grid tables.
[ https://issues.apache.org/jira/browse/IGNITE-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9509. > Created one facade for existing ui-grid tables. > --- > > Key: IGNITE-9509 > URL: https://issues.apache.org/jira/browse/IGNITE-9509 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > We have various custom implementation where ui-grid is used with lots of > duplicated code for selection\update etc. > It would be better to encapsulate this cases under one component facade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9508) Refactor legacy pug configuration mixins in frontend
[ https://issues.apache.org/jira/browse/IGNITE-9508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9508: - Component/s: wizards > Refactor legacy pug configuration mixins in frontend > > > Key: IGNITE-9508 > URL: https://issues.apache.org/jira/browse/IGNITE-9508 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > We have lots of unstructured pug mixins in web console frontend. Some of them > are not used, some are just facades for new mixins. Moreover we have lots of > mixing that accept positional arguements, which is very unhandy - we should > use mixins with named arguments. Let's refactor those mixins. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9596) Web console: invisible checkbox is visible
[ https://issues.apache.org/jira/browse/IGNITE-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16614330#comment-16614330 ] Ilya Borisov commented on IGNITE-9596: -- I think "height: 0" on a checkbox was a bad idea and can/should be replaced with another approach. > Web console: invisible checkbox is visible > -- > > Key: IGNITE-9596 > URL: https://issues.apache.org/jira/browse/IGNITE-9596 > Project: Ignite > Issue Type: Bug > Components: wizards > Environment: Firefox, Chrome (macOS), Safari >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Attachments: image-2018-09-14-10-58-23-054.png > > > How it looks: > !image-2018-09-14-10-58-23-054.png! > How to reproduce: > 1. Connect to a cluster > 2. Open queries > 3. Click "+Add scan" > 4. Scroll down to filter input with "Cs" appendix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9509) Created one facade for existing ui-grid tables.
[ https://issues.apache.org/jira/browse/IGNITE-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9509: Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Created one facade for existing ui-grid tables. > --- > > Key: IGNITE-9509 > URL: https://issues.apache.org/jira/browse/IGNITE-9509 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > We have various custom implementation where ui-grid is used with lots of > duplicated code for selection\update etc. > It would be better to encapsulate this cases under one component facade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9596) Web console: invisible checkbox is visible
[ https://issues.apache.org/jira/browse/IGNITE-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9596: - Description: How it looks: !image-2018-09-14-10-58-23-054.png! How to reproduce: 1. Connect to a cluster 2. Open queries 3. Click "+Add scan" 4. Scroll down to filter input with "Cs" appendix. was: How it looks: !image-2018-09-14-10-58-23-054.png! How to reproduce: 1. Connect to a cluster 2. Open queries 3. Click "+Add scan" > Web console: invisible checkbox is visible > -- > > Key: IGNITE-9596 > URL: https://issues.apache.org/jira/browse/IGNITE-9596 > Project: Ignite > Issue Type: Bug > Components: wizards > Environment: Firefox, Chrome (macOS), Safari >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Attachments: image-2018-09-14-10-58-23-054.png > > > How it looks: > !image-2018-09-14-10-58-23-054.png! > How to reproduce: > 1. Connect to a cluster > 2. Open queries > 3. Click "+Add scan" > 4. Scroll down to filter input with "Cs" appendix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9509) Created one facade for existing ui-grid tables.
[ https://issues.apache.org/jira/browse/IGNITE-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9509: - Component/s: wizards > Created one facade for existing ui-grid tables. > --- > > Key: IGNITE-9509 > URL: https://issues.apache.org/jira/browse/IGNITE-9509 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > Fix For: 2.7 > > > We have various custom implementation where ui-grid is used with lots of > duplicated code for selection\update etc. > It would be better to encapsulate this cases under one component facade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9596) Web console: invisible checkbox is visible
Ilya Borisov created IGNITE-9596: Summary: Web console: invisible checkbox is visible Key: IGNITE-9596 URL: https://issues.apache.org/jira/browse/IGNITE-9596 Project: Ignite Issue Type: Bug Components: wizards Environment: Firefox, Chrome (macOS), Safari Reporter: Ilya Borisov Assignee: Alexander Kalinin Attachments: image-2018-09-14-10-58-23-054.png How it looks: !image-2018-09-14-10-58-23-054.png! How to reproduce: 1. Connect to a cluster 2. Open queries 3. Click "+Add scan" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9595) Web console: invisible checkbox is visible inqueries
Ilya Borisov created IGNITE-9595: Summary: Web console: invisible checkbox is visible inqueries Key: IGNITE-9595 URL: https://issues.apache.org/jira/browse/IGNITE-9595 Project: Ignite Issue Type: Bug Components: wizards Reporter: Ilya Borisov Assignee: Alexander Kalinin How to reproduce: 1. Connect to a cluster 2. Go to queries 3. Click on "+Add scan" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9594) Regression in release build for ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-9594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9594: - Ignite Flags: (was: Docs Required) > Regression in release build for ignite-zookeeper module > --- > > Key: IGNITE-9594 > URL: https://issues.apache.org/jira/browse/IGNITE-9594 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryZookeeperIpFinder and started from binary build. > > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9594) Regression in release build for ignite-zookeeper module
Alexey Kuznetsov created IGNITE-9594: Summary: Regression in release build for ignite-zookeeper module Key: IGNITE-9594 URL: https://issues.apache.org/jira/browse/IGNITE-9594 Project: Ignite Issue Type: Bug Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.7 In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & jackson-mapper-asl were removed and that leads to ClassNotFound errors at runtime if ignite node uses TcpDiscoveryZookeeperIpFinder and started from binary build. We need to return that dependencies back, because Ignite binary build logic ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9593) Spart Optimization fails to optimize statements
Nikolay Izhikov created IGNITE-9593:
---
Summary: Spart Optimization fails to optimize statements
Key: IGNITE-9593
URL: https://issues.apache.org/jira/browse/IGNITE-9593
Project: Ignite
Issue Type: Bug
Components: spark
Affects Versions: 2.6
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
Fix For: 2.7
Attachments: Spark_optimization_bugs_reproducer.patch
In some cases, {{IgniteOptimization}} fails to optimize spark query. Reproducer
attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9552) Web console: add TypeScript support
[ https://issues.apache.org/jira/browse/IGNITE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9552: - Remaining Estimate: 15h (was: 29.75h) > Web console: add TypeScript support > --- > > Key: IGNITE-9552 > URL: https://issues.apache.org/jira/browse/IGNITE-9552 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 48h > Time Spent: 2.25h > Remaining Estimate: 15h > > What to do: > 1. Add TypeScript preset to babel config. > 2. Update webpack configs to load .ts files with babel-loader. > 3. Make sure eslint lint .ts files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9552) Web console: add TypeScript support
[ https://issues.apache.org/jira/browse/IGNITE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9552: - Remaining Estimate: 29.75h (was: 45.75h) > Web console: add TypeScript support > --- > > Key: IGNITE-9552 > URL: https://issues.apache.org/jira/browse/IGNITE-9552 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 48h > Time Spent: 2.25h > Remaining Estimate: 29.75h > > What to do: > 1. Add TypeScript preset to babel config. > 2. Update webpack configs to load .ts files with babel-loader. > 3. Make sure eslint lint .ts files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9592) MVCC: Use linked lists to store multiple versions.
Roman Kondakov created IGNITE-9592:
--
Summary: MVCC: Use linked lists to store multiple versions.
Key: IGNITE-9592
URL: https://issues.apache.org/jira/browse/IGNITE-9592
Project: Ignite
Issue Type: Improvement
Components: mvcc
Reporter: Roman Kondakov
Currently we store all versions of each row in primary index. It is not very
efficient for several reasons:
* We have to insert and remove tree item each time a new version is created or
an old version deleted. This leads to a considerable tree operations number
increasing as well as tree splits and merges operations.
* Also this leads to a contention on leaf page write lock - each update
operation has to obtain exclusive access to insert a new version of row. During
this update no body on that leaf can not be able to update or even read data of
neighbour keys.
* Primary key tree consumes more space if it stores each version.
* Other vendors do not store each version in primary indexes (as far as I
know).
Possible solution - store only key and link to the newest version in the
primary index. Instead of this {{CacheDataTree}} item
{{| key part | | |}}
{{|-| lockVer | link |}}
{{| cache_id | hash | mvccVer | | |}}
we'll have:
{{| key part | | link to the |}}
{{|-| lockVer | newest |}}
{{| cache_id | hash | |version |}}
Note, we do not have mvccVer in tree item. Link to the newer version leads to
the most recent inserted data item. To find older versions, each DatRow is
provided with "prevLink" - the link to previous version of row. DataRow layout
can be changed from
| header | xid_max | xid_min | KV bytes |
to the next one:
| header | xid_max | xid_min | *PREV_LINK* | KV bytes |
Where *PREV_LINK* field points to the previous version of the row. Traversing
this prevRow links we can iterate over all available versions without affecting
primary key tree.
When the new version is created we just insert the new row in datastore, then
do CAS on the link to the newest version in primary key tree in order it points
to the new row. PrevLink in the new row should point on the previous one. That
is all. We've just inserted a new version just with a long field CAS in the
CacheDataTree. Without obtaining write lock and other headache.
Secondary indexes are handled in the same manner as before.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9591) MVCC: Do small write operations under the read lock.
Roman Kondakov created IGNITE-9591:
--
Summary: MVCC: Do small write operations under the read lock.
Key: IGNITE-9591
URL: https://issues.apache.org/jira/browse/IGNITE-9591
Project: Ignite
Issue Type: Improvement
Components: mvcc
Reporter: Roman Kondakov
There are several operations in MVCC flow which can be done under the page read
lock instead of write lock. For example, setting xid_max on a datarow. It is
safe, because races are possible only between concurrent transactions, which
are not visible to each other.
See {{MvccMarkUpdatedHandler}} and other similar handlers in this class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9543) MVCC TX: Add Mvcc atomicity mode to ConfigVariations tests when full cache API support is implemented.
[
https://issues.apache.org/jira/browse/IGNITE-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-9543:
---
Ignite Flags: (was: Docs Required)
> MVCC TX: Add Mvcc atomicity mode to ConfigVariations tests when full cache
> API support is implemented.
> --
>
> Key: IGNITE-9543
> URL: https://issues.apache.org/jira/browse/IGNITE-9543
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
>
> We need to add {{TRANSACTIONAL_SNAPSHOT}} atomicity mode to
> {{ConfigVariations#BASIC_CACHE_SET}} when full Cache API support is
> implemented for MVCC caches (i.e. near/local caches, read/write through,
> etc.).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9590) MVCC: Cleanup old rows in the vacuum thread.
[ https://issues.apache.org/jira/browse/IGNITE-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov updated IGNITE-9590: --- Ignite Flags: (was: Docs Required) > MVCC: Cleanup old rows in the vacuum thread. > > > Key: IGNITE-9590 > URL: https://issues.apache.org/jira/browse/IGNITE-9590 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Roman Kondakov >Priority: Major > Labels: performance > > When updating writer thread should iterate over the set of the last versions > in order to find an appropriate version for its MVCC snapshot. During this > iteration it collects invisible to anybody versions (their xid_max version is > less than cleanup). When all outdated versions found, writer thread cleanups > these rows - removes it from indexes and from pagestore. > It would be more efficient if writer thread does not cleanup old rows by > itself, but rather delegate it to vacuum workers: instead of cleaning just > put it to cleanup queue. > in case of significant backpressure during active updates, when cleanup > workers can't keep up with removing outdated rows and cleanup queue is too > big, writer threads can cleanup this rows by itself to prevent memory and > performance problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9590) MVCC: Cleanup old rows in the vacuum thread.
Roman Kondakov created IGNITE-9590: -- Summary: MVCC: Cleanup old rows in the vacuum thread. Key: IGNITE-9590 URL: https://issues.apache.org/jira/browse/IGNITE-9590 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Roman Kondakov When updating writer thread should iterate over the set of the last versions in order to find an appropriate version for its MVCC snapshot. During this iteration it collects invisible to anybody versions (their xid_max version is less than cleanup). When all outdated versions found, writer thread cleanups these rows - removes it from indexes and from pagestore. It would be more efficient if writer thread does not cleanup old rows by itself, but rather delegate it to vacuum workers: instead of cleaning just put it to cleanup queue. in case of significant backpressure during active updates, when cleanup workers can't keep up with removing outdated rows and cleanup queue is too big, writer threads can cleanup this rows by itself to prevent memory and performance problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9212) Uncomment 18 test classes in various modules' sutes (see inside)
[
https://issues.apache.org/jira/browse/IGNITE-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9212:
---
Fix Version/s: 2.7
> Uncomment 18 test classes in various modules' sutes (see inside)
>
>
> Key: IGNITE-9212
> URL: https://issues.apache.org/jira/browse/IGNITE-9212
> Project: Ignite
> Issue Type: Sub-task
> Components: clients, hadoop, hibernate, jdbc, spring, zookeeper
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.7
>
>
> As per the following test suites:
> {code}
> 4
> modules/clients/src/test/java/org/apache/ignite/internal/client/suite/IgniteClientTestSuite.java
> 1
> modules/clients/src/test/java/org/apache/ignite/jdbc/suite/IgniteJdbcDriverTestSuite.java
> 4
> modules/hadoop/src/test/java/org/apache/ignite/testsuites/IgniteHadoopTestSuite.java
> 1
> modules/hadoop/src/test/java/org/apache/ignite/testsuites/IgniteIgfsLinuxAndMacOSTestSuite.java
> 1
> modules/hibernate-4.2/src/test/java/org/apache/ignite/testsuites/IgniteHibernateTestSuite.java
> 1
> modules/hibernate-5.1/src/test/java/org/apache/ignite/testsuites/IgniteHibernate5TestSuite.java
> 2
> modules/spring/src/test/java/org/apache/ignite/testsuites/IgniteSpringTestSuite.java
> 3
> modules/urideploy/src/test/java/org/apache/ignite/testsuites/IgniteUriDeploymentTestSuite.java
> 1
> modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/ZookeeperDiscoverySpiTestSuite1.java
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9212) Uncomment 18 test classes in various modules' sutes (see inside)
[
https://issues.apache.org/jira/browse/IGNITE-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613831#comment-16613831
]
ASF GitHub Bot commented on IGNITE-9212:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4700
> Uncomment 18 test classes in various modules' sutes (see inside)
>
>
> Key: IGNITE-9212
> URL: https://issues.apache.org/jira/browse/IGNITE-9212
> Project: Ignite
> Issue Type: Sub-task
> Components: clients, hadoop, hibernate, jdbc, spring, zookeeper
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> As per the following test suites:
> {code}
> 4
> modules/clients/src/test/java/org/apache/ignite/internal/client/suite/IgniteClientTestSuite.java
> 1
> modules/clients/src/test/java/org/apache/ignite/jdbc/suite/IgniteJdbcDriverTestSuite.java
> 4
> modules/hadoop/src/test/java/org/apache/ignite/testsuites/IgniteHadoopTestSuite.java
> 1
> modules/hadoop/src/test/java/org/apache/ignite/testsuites/IgniteIgfsLinuxAndMacOSTestSuite.java
> 1
> modules/hibernate-4.2/src/test/java/org/apache/ignite/testsuites/IgniteHibernateTestSuite.java
> 1
> modules/hibernate-5.1/src/test/java/org/apache/ignite/testsuites/IgniteHibernate5TestSuite.java
> 2
> modules/spring/src/test/java/org/apache/ignite/testsuites/IgniteSpringTestSuite.java
> 3
> modules/urideploy/src/test/java/org/apache/ignite/testsuites/IgniteUriDeploymentTestSuite.java
> 1
> modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/ZookeeperDiscoverySpiTestSuite1.java
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9585:
---
Description:
Teamcity build logs sometimes refer to remote node log files that aren't
present in build artifacts
([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
I managed to reproduce this on my machine (details below) and it looks like
typically the root cause of this is error message from
[StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
referring readers to file that doesn't exist (and it wasn't even created to
start with).
{code:java}
return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
node could not start. " +
"See log for details: " + scriptOutputPath);
{code}
This is quite painful when one tries to investigate node launching failures
because the misleading message causes one to waste time investigating the
problem that doesn't exist (it appears as if log file was there but somehow
disappeared for some mysterious reason).
To reproduce the issue locally (on Ubuntu 16.04) one can do as follows: first,
modify file
[start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
{{noignite.sh}}. After that, execute unit test
[IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
and study its results and logs.
You will find that {{testCustomScript}} fails - which is expected because name
of the script intended to be executed has changed to one that doesn't exist.
Also you will find that log file for respective node hasn't been created -
which is also expected because shell command fails before creating it. But in
the same time test log will refer to mentioned file as if it exists.
was:
Teamcity build logs sometimes refer to remote node log files that aren't
present in build artifacts
([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
I managed to reproduce this on my machine (details below) and it looks like
typically the root cause of this is error message from
[StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
referring readers to file that doesn't exist (and it wasn't even created to
start with).
{code:java}
return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
node could not start. " +
"See log for details: " + scriptOutputPath);
{code}
This is quite painful when one tries to investigate node launching failures
because the misleading message causes one to waste time investigating the
problem that doesn't exist (it appears as if log file was there but somehow
disappeared for some mysterious reason).
To reproduce the issue locally one can do as follows: first, modify file
[start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
{{noignite.sh}}. After that, execute unit test
[IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
and study its results and logs.
You will find that {{testCustomScript}} fails - which is expected because name
of the script intended to be executed has changed to one that doesn't exist.
Also you will find that log file for respective node hasn't been created -
which is also expected because shell command fails before creating it. But in
the same time test log will refer to mentioned file as if it exists.
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
>
[jira] [Commented] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[ https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613790#comment-16613790 ] ASF GitHub Bot commented on IGNITE-9585: GitHub user oignatenko opened a pull request: https://github.com/apache/ignite/pull/4753 IGNITE-9585 Error message sometimes refers nonexisting log file when remote node fails to start You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9585 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4753.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 #4753 commit 1eeca908a8076a8317947dac8a46845964d1d7ea Author: Oleg Ignatenko Date: 2018-08-23T13:13:28Z IGNITE-9348 ML examples improvements - wip (logging improved) -- verified with diffs overview, executing the examples and studying execution logs commit e50b89c392568ba9b93935c4fa6c7f7f93f5ec6f Author: Oleg Ignatenko Date: 2018-08-23T14:45:57Z Revert "IGNITE-9348 ML examples improvements" This reverts commit 1eeca908a8076a8317947dac8a46845964d1d7ea. commit 474024b4c5bbdb3c0a4ed2f0a66238c8054c6674 Author: Oleg Ignatenko Date: 2018-08-23T14:57:34Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 9642b233b5701bdad47ebea163079160227c582a Author: Oleg Ignatenko Date: 2018-08-28T14:01:11Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 7fc16d013ab725d2ff2e1a1b042c983f11d0c4d4 Author: Oleg Ignatenko Date: 2018-08-28T15:13:02Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit d2caba67b156674f051f50faebeafe0871bf0914 Author: Oleg Ignatenko Date: 2018-08-29T13:14:07Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 16775dff51d71ea68b4a3dea98be552130c493ed Author: Oleg Ignatenko Date: 2018-08-30T09:00:56Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit aedb59929974fe205b949225c1a338c68c60cfc8 Author: Oleg Ignatenko Date: 2018-08-30T09:42:38Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 39c6482fcdca506aa33011ed21c98060b4a8c68b Author: Oleg Ignatenko Date: 2018-08-30T11:28:05Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 33b32a2760a6559c78283b927e3191180d8ed9e1 Author: Oleg Ignatenko Date: 2018-08-30T12:31:16Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 9531028ddd1aef9e95f7e8c8b528086739bbb1b0 Author: Oleg Ignatenko Date: 2018-08-30T14:06:34Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 28f22c6e2fffcb82717ba5da7be2cfd39715c4e3 Author: Oleg Ignatenko Date: 2018-08-30T16:41:51Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit aacac88db519187413b0fc5ff9d0e55b8f8cff22 Author: Oleg Ignatenko Date: 2018-08-31T10:12:32Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 897f920dde46022849b13f9fb86dba8e54119a56 Author: Oleg Ignatenko Date: 2018-08-31T13:57:14Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 114c79e54c1b316006ccc3ff22d20d902f9313df Author: Oleg Ignatenko Date: 2018-08-31T17:39:16Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit fd6b659bb8be1992618ce4ce91f568a0988b3afa Author: Oleg Ignatenko Date: 2018-09-02T06:11:42Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 6ae6d1d3cf9743d8d466be0330511ddc8589e944 Author: Oleg Ignatenko Date: 2018-09-03T10:27:35Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit e8b27dbd3d0c1cbdb7a7659175f5c7bb447482bf Author: Oleg Ignatenko Date: 2018-09-04T09:49:44Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 622c82efdd0aa182fadea6b7ffa5d4615521a3f5 Author: Oleg Ignatenko Date: 2018-09-05T10:50:28Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit fb844fe3751e2e8ae87e6b8030b0e4bd659df9c2 Author: Oleg Ignatenko Date: 2018-09-05T11:45:58Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 480ed78869277d7e32f725ab71bec9621f1ac03a Author: Oleg Ignatenko Date: 2018-09-06T07:52:55Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit c99762498f617c0e98ea3062a43c0b30092166ef Author: Oleg Ignatenko Date: 2018-09-06T14:45:04Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 2e17175225c72f747d370b5fee96f8be69d6d2cb
[jira] [Commented] (IGNITE-9541) Add the comparison for two general statistics "RunAll" for master in the date interval
[ https://issues.apache.org/jira/browse/IGNITE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613788#comment-16613788 ] ASF GitHub Bot commented on IGNITE-9541: zzzadruga opened a new pull request #9: IGNITE-9541 Add the comparison for two general statistics "RunAll" for master in the date interval URL: https://github.com/apache/ignite-teamcity-bot/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add the comparison for two general statistics "RunAll" for master in the date > interval > -- > > Key: IGNITE-9541 > URL: https://issues.apache.org/jira/browse/IGNITE-9541 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Major > > Based on IGNITE-9333 add the comparison for two general statistics "RunAll" > for master in the date interval -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8538) Web Console: Refactor redirecting to default state.
[ https://issues.apache.org/jira/browse/IGNITE-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8538. > Web Console: Refactor redirecting to default state. > --- > > Key: IGNITE-8538 > URL: https://issues.apache.org/jira/browse/IGNITE-8538 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Time Spent: 0.2h > Remaining Estimate: 0h > > We need to refactor and fix redirection to default state from Queries screen, > 40x screens and other similar places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8006) Starting multiple caches slows down exchange process on joining node
[
https://issues.apache.org/jira/browse/IGNITE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov reassigned IGNITE-8006:
-
Assignee: Anton Kalashnikov (was: Alexey Stelmak)
> Starting multiple caches slows down exchange process on joining node
>
>
> Key: IGNITE-8006
> URL: https://issues.apache.org/jira/browse/IGNITE-8006
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> In some cases when we starts multiple caches (over 2K caches), we can get a
> stop on exchange when new node joining to the cluster.
> Coordinator-node wait to receive a single message from all other nodes, but
> last node (which want to joining to the cluster) stopped on starting caches:
>
> {noformat}
> Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1329)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1159)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1900)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:740)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It blocks cluster exchange process until all caches started on the last node.
> We should start caches in parallel threads or exclude the action from
> exchange init process.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8006) Starting multiple caches slows down exchange process on joining node
[
https://issues.apache.org/jira/browse/IGNITE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613763#comment-16613763
]
ASF GitHub Bot commented on IGNITE-8006:
GitHub user akalash opened a pull request:
https://github.com/apache/ignite/pull/4752
IGNITE-8006 added parallel start of caches.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8006
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4752.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 #4752
commit a457c8b4c23be57cea11f7f7a49c5bc695adde9d
Author: Anton Kalashnikov
Date: 2018-09-13T16:44:40Z
IGNITE-8006 added parallel start of caches.
> Starting multiple caches slows down exchange process on joining node
>
>
> Key: IGNITE-8006
> URL: https://issues.apache.org/jira/browse/IGNITE-8006
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Stelmak
>Priority: Major
>
> In some cases when we starts multiple caches (over 2K caches), we can get a
> stop on exchange when new node joining to the cluster.
> Coordinator-node wait to receive a single message from all other nodes, but
> last node (which want to joining to the cluster) stopped on starting caches:
>
> {noformat}
> Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1329)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1159)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1900)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:740)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It blocks cluster exchange process until all caches started on the last node.
> We should start caches in parallel threads or exclude the action from
> exchange init process.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613614#comment-16613614
]
Oleg Ignatenko edited comment on IGNITE-9585 at 9/13/18 4:47 PM:
-
(i) I considered different options to address this issue and it looks like most
convenient approach would be that prior to calling ignite script we would
simply create log file and fill it with a simple diagnostic message, like
{{echo "Preparing to start remote node..." > logfile}} (successful launch of
the node would rewrite it but that's okay). This would guarantee that log file
will be there even in case if node launch script breaks and make it easier to
investigate failures.
-
(update) Just tested above approach on my machine and it appears to work even
better than I expected: not only log file is created, it is also filled with
details about what went wrong: {noformat}nohup: ignoring input
/home/gridgain/Desktop/test/ignite-master/modules/core/src/test/bin/start-nodes-custom.sh:
23:
/home/gridgain/Desktop/test/ignite-master/modules/core/src/test/bin/start-nodes-custom.sh:
/home/gridgain/Desktop/test/ignite-master/modules/core/src/test/bin/../../../../../bin/noignite.sh:
not found{noformat}
was (Author: oignatenko):
(i) I considered different options to address this issue and it looks like most
convenient approach would be that prior to calling ignite script we would
simply create log file and fill it with a simple diagnostic message, like
{{echo "Preparing to start remote node..." > logfile}} (successful launch of
the node would rewrite it but that's okay). This would guarantee that log file
will be there even in case if node launch script breaks and make it easier to
investigate failures.
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally one can do as follows: first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613748#comment-16613748
]
ASF GitHub Bot commented on IGNITE-9589:
GitHub user NSAmelchev opened a pull request:
https://github.com/apache/ignite/pull/4751
IGNITE-9589
For IGNITE-9589 GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/NSAmelchev/ignite ignite-9589
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4751.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 #4751
commit f6f75ae26f744cd9ac2a376c1f5735b1016f
Author: NSAmelchev
Date: 2018-09-13T16:40:12Z
Check that test fails on mass runs
> GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
> ---
>
> Key: IGNITE-9589
> URL: https://issues.apache.org/jira/browse/IGNITE-9589
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
> periodicaly.
> From the logs, I see that the failure is caused by BindException. It causes
> node start fails because the test port range is 0.
> {noformat}
> [2018-09-13
> 04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
> Failed to start manager: GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
> at org.apache.ignite.Ignition.start(Ignition.java:323)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
> at
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
> ... 20 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
> at
> org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
> at
>
[jira] [Assigned] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9503:
Resolution: Fixed
Assignee: Pavel Konstantinov (was: Alexey Kuznetsov)
Looks good to me. Merged to master.
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Pavel Konstantinov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
Amelchev Nikita created IGNITE-9589:
---
Summary: GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange
is flaky in master
Key: IGNITE-9589
URL: https://issues.apache.org/jira/browse/IGNITE-9589
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
periodicaly.
>From the logs, I see that the failure is caused by BindException. It causes
>node start fails because the test port range is 0.
{noformat}
[2018-09-13
04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
Failed to start manager: GridManagerAdapter [enabled=true,
name=o.a.i.i.managers.communication.GridIoManager]
class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
at
org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
at org.apache.ignite.Ignition.start(Ignition.java:323)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
at
org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to initialize
TCP server: 0.0.0.0/0.0.0.0
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
... 20 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
... 21 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to initialize
NIO selector.
at
org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
at
org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
at
org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:97)
at
org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:3669)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2415)
... 22 more
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at
org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:972)
... 26 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-4111: Fix Version/s: 2.8 > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.8 > > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9330) Multiple CacheMetricsManageTest tests are failing
[ https://issues.apache.org/jira/browse/IGNITE-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-9330: Fix Version/s: 2.7 > Multiple CacheMetricsManageTest tests are failing > - > > Key: IGNITE-9330 > URL: https://issues.apache.org/jira/browse/IGNITE-9330 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Amelchev Nikita >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > testCacheManagerStatisticsEnable and testClusterApiClearStatistics fail every > so often, such as in > https://ci.ignite.apache.org/viewLog.html?buildId=1676464 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9588) Separate page for JIRA, GitHub actions
Ryabov Dmitrii created IGNITE-9588: -- Summary: Separate page for JIRA, GitHub actions Key: IGNITE-9588 URL: https://issues.apache.org/jira/browse/IGNITE-9588 Project: Ignite Issue Type: Sub-task Reporter: Ryabov Dmitrii Assignee: Ryabov Dmitrii To separate JIRA and GitHub actions from other action on index page we need to create an additional page, opened by tab on the panel with Home and Compare Builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8770) OutOfMemory in Queries1 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613707#comment-16613707 ] ASF GitHub Bot commented on IGNITE-8770: GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4750 IGNITE-8770: OutOfMemory in Queries1 suite in master branch on TC You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8770 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4750.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 #4750 commit 72994e61f554b67c01ad3439af95e263e8b75cab Author: Alexey Platonov Date: 2018-09-13T16:08:12Z limit partitions count > OutOfMemory in Queries1 suite in master branch on TC > > > Key: IGNITE-8770 > URL: https://issues.apache.org/jira/browse/IGNITE-8770 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Alexey Platonov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > OutOfMemory happened for the first time in a while for this suite: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1372426=buildResultsDiv=IgniteTests24Java8_Queries1] > No execution timeouts or OOM errors in recent history: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Queries1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8770) OutOfMemory in Queries1 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613706#comment-16613706 ] Alexey Platonov commented on IGNITE-8770: - potentially OOM may appear due to large number of partitions too many GridFutureAdapters in heap in straces like: java.lang.Thread.getStackTrace(Thread.java:1559) org.apache.ignite.internal.util.future.GridFutureAdapter.(GridFutureAdapter.java:66) org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$2.(GridDhtLocalPartition.java:202) org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:202) org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:835) org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:391) org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:566) org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1265) org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766) org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577) org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457) org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) java.lang.Thread.run(Thread.java:748) for this reason I limit partitions count in test as first approximation of fix > OutOfMemory in Queries1 suite in master branch on TC > > > Key: IGNITE-8770 > URL: https://issues.apache.org/jira/browse/IGNITE-8770 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Alexey Platonov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > OutOfMemory happened for the first time in a while for this suite: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1372426=buildResultsDiv=IgniteTests24Java8_Queries1] > No execution timeouts or OOM errors in recent history: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Queries1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613692#comment-16613692 ] Anton Vinogradov commented on IGNITE-5553: -- [~Mmuzaf] , [~xtern] , I've checked the changes. Initially, looks good to me. Let's check TC and I will recheck the fix. > Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error > - > > Key: IGNITE-5553 > URL: https://issues.apache.org/jira/browse/IGNITE-5553 > Project: Ignite > Issue Type: Bug > Components: data structures, persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.7 > > > h2. Notes-4435 > When IgniteSet is restored from persistence, size of set is always 0, [link > to test > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails]. > h2. Detailed description > Unlike *IgniteQueue* which uses separate cache key to store its size > *IgniteSet* stores it in a field of some class. > Test from the link above shows very clearly that after restoring memory state > from PDS all set values are restored correctly but size is lost. > h2. Proposed solution > One possible solution might be to do the same thing as *IgniteQueue* does: > size of *IgniteSet* must be stored is cache instead of volatile in-memory > fields of random classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8999) WebConsole should correct parsing trace error messages introduced by #8971
[ https://issues.apache.org/jira/browse/IGNITE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8999. Merged to master. > WebConsole should correct parsing trace error messages introduced by #8971 > -- > > Key: IGNITE-8999 > URL: https://issues.apache.org/jira/browse/IGNITE-8999 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > https://issues.apache.org/jira/browse/IGNITE-8971 added trace to error > messages, change to WC parsing is needed, see comments there -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8199) Web console: Make the Confirmation dialog a more clear
[ https://issues.apache.org/jira/browse/IGNITE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8199: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web console: Make the Confirmation dialog a more clear > -- > > Key: IGNITE-8199 > URL: https://issues.apache.org/jira/browse/IGNITE-8199 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.7 > > Attachments: image-2018-04-11-13-54-07-997.png, > image-2018-04-11-13-54-23-306.png, screenshot-1.png > > > In case of unsaved changes, we show the following confirmation > !screenshot-1.png! > It is unclear what I have to do to see the changes. > I suggest to change the text 'Click here to see changes' somehow to make it > more obvious. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9587) [ML] Umbrella ticket: Handle different labels in training data and handle unknown labels in test or updated training data correctly
Aleksey Zinoviev created IGNITE-9587: Summary: [ML] Umbrella ticket: Handle different labels in training data and handle unknown labels in test or updated training data correctly Key: IGNITE-9587 URL: https://issues.apache.org/jira/browse/IGNITE-9587 Project: Ignite Issue Type: New Feature Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev The problem is that all algorithms of binary classification are ready to handle the datasets marked with 0/1 labels and predict 0/1 labels without especial mapping. Also the algorithms don't handle situation with unknown labels during the updating and testing phases Possible solution: it could be stored in context of ML training -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9585:
---
Labels: MakeTeamcityGreenAgain (was: )
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally one can do as follows: first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9545) IgniteProjectionStartStopRestartSelfTest: misleading javadocs, required conditions are not described, inconvenient to configure locally
[
https://issues.apache.org/jira/browse/IGNITE-9545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9545:
---
Labels: MakeTeamcityGreenAgain (was: )
> IgniteProjectionStartStopRestartSelfTest: misleading javadocs, required
> conditions are not described, inconvenient to configure locally
> ---
>
> Key: IGNITE-9545
> URL: https://issues.apache.org/jira/browse/IGNITE-9545
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> This test has been [reported as
> flaky|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=testDetails=2278553016619338221#analysis]
> at Teamcity. Looking closer shows that there are some issues with the test.
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> class javadocs provide instructions on how to configure test which have
> nothing to do with the way how it is actually configured. Not only the way is
> different but even respective property names are incorrect, which is easy to
> see from very first 3 statements in test code that initialize configuration.
> Checking git history of this file shows that root cause for this issue is a
> change made about 4 years ago when obtaining test properties has changed from
> {{GridTestProperties.getProperty}} to {{System.getenv}} (back then, also
> property names have changed) but test javadoc was not updated to reflect that.
> Another issue with javadoc which makes it unnecessarily difficult to
> investigate failures is that it doesn't explain that test expects configured
> target host to run ssh server and accept connections at configured port from
> user with specified credentials.
> Javadocs need to be corrected.
> Another issue with the test is the way it obtains the config (username and
> password): when I tried to do some quick experiments on my machine it turned
> out fairly difficult to set to what I wanted. When I tried to change test
> code to obtain config in the way how it was in the past (via
> {{GridTestProperties}}) it went much easier.
> One good thing of the current way is it has proven to work well on Teamcity
> and because of that it makes sense to keep it. But on the other hand it looks
> desirable to augment it with fallback to the way that is more convenient for
> local experimenting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9585:
---
Fix Version/s: 2.7
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
> Fix For: 2.7
>
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally one can do as follows: first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9585:
---
Ignite Flags: (was: Docs Required)
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally one can do as follows: first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9022) [ML] Implement class labels mapping for SVM binary classifier
[
https://issues.apache.org/jira/browse/IGNITE-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613627#comment-16613627
]
ASF GitHub Bot commented on IGNITE-9022:
GitHub user zaleslaw opened a pull request:
https://github.com/apache/ignite/pull/4749
IGNITE-9022: Changed class label output in SVM
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9022
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4749.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 #4749
commit e1dd11ec45d088c42c1a4d3025f0b3e7f9b3ce73
Author: zaleslaw
Date: 2018-09-13T15:14:27Z
IGNITE-9022: Changed class label output in SVM
> [ML] Implement class labels mapping for SVM binary classifier
> -
>
> Key: IGNITE-9022
> URL: https://issues.apache.org/jira/browse/IGNITE-9022
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Alexey Platonov
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.7
>
>
> We need to automatically compute mapping from user's labels to \{-1;1} for
> SVM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9586) Treat 172.17.0.1 as localhost address and only use it as last resort
Ilya Kasnacheev created IGNITE-9586: --- Summary: Treat 172.17.0.1 as localhost address and only use it as last resort Key: IGNITE-9586 URL: https://issues.apache.org/jira/browse/IGNITE-9586 Project: Ignite Issue Type: Improvement Reporter: Ilya Kasnacheev As far as my understanding goes, it is a Docker gateway address. Nodes see that they have this address in common, and try to use it for Communication, which leads to confusing results since 172.17.0.1 is not actually shared between them. I think we should regard it as localhost or outright ignore it when picking address to connect to in Communication. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613614#comment-16613614
]
Oleg Ignatenko commented on IGNITE-9585:
(i) I considered different options to address this issue and it looks like most
convenient approach would be that prior to calling ignite script we would
simply create log file and fill it with a simple diagnostic message, like
{{echo "Preparing to start remote node..." > logfile}} (successful launch of
the node would rewrite it but that's okay). This would guarantee that log file
will be there even in case if node launch script breaks and make it easier to
investigate failures.
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally one can do as follows: first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko reassigned IGNITE-9585:
--
Assignee: Oleg Ignatenko
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally one can do as follows: first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
Oleg Ignatenko created IGNITE-9585:
--
Summary: Error message sometimes refers nonexisting log file when
remote node fails to start
Key: IGNITE-9585
URL: https://issues.apache.org/jira/browse/IGNITE-9585
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
Teamcity build logs sometimes refer to remote node log files that aren't
present in build artifacts
([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
I managed to reproduce this on my machine (details below) and it looks like
typically the root cause of this is error message from
[StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
referring readers to file that doesn't exist (and it wasn't even created to
start with).
{code:java}
return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
node could not start. " +
"See log for details: " + scriptOutputPath);
{code}
This is quite painful when one tries to investigate node launching failures
because the misleading message causes one to waste time investigating the
problem that doesn't exist (it appears as if log file was there but somehow
disappeared for some mysterious reason).
To reproduce the issue locally one can do as follows: first, modify file
[start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
{{noignite.sh}}. After that, execute unit test
[IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
and study its results and logs.
You will find that {{testCustomScript}} fails - which is expected because name
of the script intended to be executed has changed to one that doesn't exist.
Also you will find that log file for respective node hasn't been created -
which is also expected because shell command fails before creating it. But in
the same time test log will refer to mentioned file as if it exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9465) Node.js client: improve complex object flags processing
[ https://issues.apache.org/jira/browse/IGNITE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613613#comment-16613613 ] Igor Sapego commented on IGNITE-9465: - [~alexey.kosenchuk] can you at least add tests for 3rd case, with small, medium and large objects, to test that all offsets work as expected? > Node.js client: improve complex object flags processing > --- > > Key: IGNITE-9465 > URL: https://issues.apache.org/jira/browse/IGNITE-9465 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > 1) fix the issue in the full schema support > 2) do not throw exception when object with HAS_RAW_DATA flag is received > 3) support OFFSET_*_BYTE flags/optimizations when writing data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9572) Web console: broken in Edge 17
[
https://issues.apache.org/jira/browse/IGNITE-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9572:
Assignee: Pavel Konstantinov (was: Alexey Kuznetsov)
Please do smoke test under ALL major browsers.
> Web console: broken in Edge 17
> --
>
> Key: IGNITE-9572
> URL: https://issues.apache.org/jira/browse/IGNITE-9572
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.7
>
>
> What happens:
> Edge 17 throws "{{Error: Expected ':'" and the web console does not work at
> all.}}
> {{What to do:}}
> {{1. Investigate why this happens.}}
> {{2. Fix the issue.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Vinokurov updated IGNITE-9550: Comment: was deleted (was: [~agoncharuk] How to properly wait new topology version in GridCacheIoManager#onMessage?Future obtained by cctx.exchange().affinityReadyFuture(rmtAffVer) does not guarantee that ctx.shared().exchange().lastFinishedFuture() returns the exchange future for required affinity version. ) > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Attachments: PartitionLostReproducer.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9572) Web console: broken in Edge 17
[
https://issues.apache.org/jira/browse/IGNITE-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-9572:
-
Fix Version/s: 2.7
> Web console: broken in Edge 17
> --
>
> Key: IGNITE-9572
> URL: https://issues.apache.org/jira/browse/IGNITE-9572
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> What happens:
> Edge 17 throws "{{Error: Expected ':'" and the web console does not work at
> all.}}
> {{What to do:}}
> {{1. Investigate why this happens.}}
> {{2. Fix the issue.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8552) Unable to use date as primary key
[ https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613599#comment-16613599 ] Taras Ledkov commented on IGNITE-8552: -- [~SGrimstad], please review my minor changes and re-run TC tests > Unable to use date as primary key > - > > Key: IGNITE-8552 > URL: https://issues.apache.org/jira/browse/IGNITE-8552 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Sergey Grimstad >Priority: Blocker > Fix For: 2.7 > > Attachments: IGNITE-8552_implemented.patch > > > It' is unable to create cache via ddl: > create table tab(id date primary key, date_field date); > Result: > ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to > rollback cache start routine. [cacheName=SQL_PUBLIC_T3] > class org.apache.ignite.IgniteCheckedException: Failed to find value class in > the node classpath (use default marshaller to enable binary objects) : > SQL_PUBLIC_T3_e90848b2_fe30_4adb_a934_6e13ca0eb409 > at > org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:426) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9584) .NET DataStorageMetricsTest is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-9584: Assignee: Alexey Goncharuk > .NET DataStorageMetricsTest is flaky in master > -- > > Key: IGNITE-9584 > URL: https://issues.apache.org/jira/browse/IGNITE-9584 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > > Most often it fails because the latest metric does not show a non-zero number > of pages. Looks like it happens because the checkpoint frequency is set to a > too small value. > Also, sometimes checkpoint lock wait time is non-zero because a checkpoint > may start when the test runs cache puts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9566) Web console: Make possible execute Explain by selected part of the query
[ https://issues.apache.org/jira/browse/IGNITE-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9566: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good to me. Merged to master. > Web console: Make possible execute Explain by selected part of the query > - > > Key: IGNITE-9566 > URL: https://issues.apache.org/jira/browse/IGNITE-9566 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > Currently, it is possible to execute a query by a selected part, but not > possible make explain. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9584) .NET DataStorageMetricsTest is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9584: - Description: Most often it fails because the latest metric does not show a non-zero number of pages. Looks like it happens because the checkpoint frequency is set to a too small value. Also, sometimes checkpoint lock wait time is non-zero because a checkpoint may start when the test runs cache puts. > .NET DataStorageMetricsTest is flaky in master > -- > > Key: IGNITE-9584 > URL: https://issues.apache.org/jira/browse/IGNITE-9584 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > > Most often it fails because the latest metric does not show a non-zero number > of pages. Looks like it happens because the checkpoint frequency is set to a > too small value. > Also, sometimes checkpoint lock wait time is non-zero because a checkpoint > may start when the test runs cache puts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9584) .NET DataStorageMetricsTest is flaky in master
Alexey Goncharuk created IGNITE-9584: Summary: .NET DataStorageMetricsTest is flaky in master Key: IGNITE-9584 URL: https://issues.apache.org/jira/browse/IGNITE-9584 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9487) REST: getall can only output keys as scalars
[
https://issues.apache.org/jira/browse/IGNITE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613567#comment-16613567
]
Ilya Kasnacheev commented on IGNITE-9487:
-
[~anovikov] Indeed, CACHE_GET_ALL was also used in binary REST and in Redis,
which would suffer from this change. I have changed approach by adding new
clandestine CACHE_GET_ALL_KEY_VALUE command, and adding another Redis test.
Please review.
> REST: getall can only output keys as scalars
>
>
> Key: IGNITE-9487
> URL: https://issues.apache.org/jira/browse/IGNITE-9487
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Regardless of what ConnectorMessageInterceptor does, `getall' command can
> only output key as string or number, and not as JSON object as values can.
> This is because output format is as follows:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":{"CustomType
> [idHash=1588995554, hash=34706515, key=111]":{"val":"111"},"CustomType
> [idHash=978025370, hash=30386820, key=222]":{"val":"222"}},"error":null}
> {code}
> The desired output format may look like:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":[{"key":{"key":111},"value":{"val":"111"}},{"key":{"key":222},"value":{"val":"222"}}],"error":null}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9566) Web console: Make possible execute Explain by selected part of the query
[ https://issues.apache.org/jira/browse/IGNITE-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9566: - Fix Version/s: 2.7 > Web console: Make possible execute Explain by selected part of the query > - > > Key: IGNITE-9566 > URL: https://issues.apache.org/jira/browse/IGNITE-9566 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Currently, it is possible to execute a query by a selected part, but not > possible make explain. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7783) Thin Client lib: PHP
[ https://issues.apache.org/jira/browse/IGNITE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613558#comment-16613558 ] Igor Sapego commented on IGNITE-7783: - Added link to additional task: IGNITE-9583 > Thin Client lib: PHP > > > Key: IGNITE-7783 > URL: https://issues.apache.org/jira/browse/IGNITE-7783 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > Implement Thin (lightweight) Client lib in PHP programming language for > Ignite Binary Client Protocol. > Functionality: > -- > Support all operations of the Ignite Binary Client Protocol 2.6: > [https://apacheignite.readme.io/v2.6/docs/binary-client-protocol] > Except the following features which are not applicable to PHP client: > - Filter object for OP_QUERY_SCAN operation (OP_QUERY_SCAN operation itself > will be supported). > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME operations. > - Registration of a new Ignite Enum type (reading and writing items of the > existing Ignite Enum types will be supported). > Additionally support: > - SSL/TLS connection. > - "Failover re-connection algorithm": > https://issues.apache.org/jira/browse/IGNITE-7282 > Ignite Binary Client Protocol handshake versions: 1.2.0 only. > Minimal required PHP version: 7.2 > [http://php.net/supported-versions.php] > PHP code-style standards: [https://www.php-fig.org/psr/] > Synchronous API will be supported (asynchronous operations are not supported > by the standard PHP). > The API will not be thread-safe (threads are not available in the standard > PHP; pthreads extension is not available for the latest PHP version; > thread-safety is possible to support by an application). > Examples: > - > The set of examples will cover: > - cache get/create/destroy operations > - cache put/get operations > - SQL operations (create table/index, insert/select/drop) > - SQL Fields query and Scan query > - Authentication and TLS connection > - working with primitive and complex data types > Tests: > -- > PHPUnit tests [https://phpunit.de|https://phpunit.de/] for all API methods > and all basic features. Including simple tests to start examples. > Tests will be integrated into the TeamCity with the help from the community. > Docs: > -- > The provided docs will include: > - Auto-generated API spec using Doxygen: > [http://www.doxygen.org|http://www.doxygen.org/] > - Instruction how to generate the API spec. > - Instruction how to release PHP library on Packagist: > [https://packagist.org/] > - Readme for user with info how to install and use the client. > - Simple instruction how to setup/run examples. > - Simple instruction how to setup/run tests. > All docs will be provided separately from the source code and will not be > merged to the target repository. Before the release all instructions and > readme will be moved to the readme.io with the help from the community. > Release: > > Location of the client: > /modules/platforms/php > Will be released as PHP library on Packagist: [https://packagist.org/] by the > community. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9583) PHP thin: php directory should be included in binary release
Igor Sapego created IGNITE-9583:
---
Summary: PHP thin: php directory should be included in binary
release
Key: IGNITE-9583
URL: https://issues.apache.org/jira/browse/IGNITE-9583
Project: Ignite
Issue Type: Improvement
Components: build, thin client
Reporter: Igor Sapego
Fix For: 2.7
Currently, php directory is not generated by the {{maven install}} command.
Need to add appropriate copy steps to {{assembly/release-fabric-base.xml}} file.
The following components should be copied:
{noformat}
ignite/modules/platforms/php/composer.json
ignite/modules/platforms/php/src
ignite/modules/platforms/php/examples
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9583) PHP thin: php directory should be included in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9583:
Ignite Flags: (was: Docs Required)
> PHP thin: php directory should be included in binary release
>
>
> Key: IGNITE-9583
> URL: https://issues.apache.org/jira/browse/IGNITE-9583
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Priority: Major
> Labels: php
> Fix For: 2.7
>
>
> Currently, php directory is not generated by the {{maven install}} command.
> Need to add appropriate copy steps to {{assembly/release-fabric-base.xml}}
> file.
> The following components should be copied:
> {noformat}
> ignite/modules/platforms/php/composer.json
> ignite/modules/platforms/php/src
> ignite/modules/platforms/php/examples
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9559) Node.js thin: nodejs directory should be included binary release
[
https://issues.apache.org/jira/browse/IGNITE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9559:
Summary: Node.js thin: nodejs directory should be included binary release
(was: Node.js thin: nodejs directory does appear in platforms directory after
maven install command)
> Node.js thin: nodejs directory should be included binary release
>
>
> Key: IGNITE-9559
> URL: https://issues.apache.org/jira/browse/IGNITE-9559
> Project: Ignite
> Issue Type: Task
> Components: build, thin client
>Reporter: Igor Sapego
>Priority: Major
> Labels: nodejs
> Fix For: 2.7
>
>
> Currently, nodejs directory is not generated by the {{maven install}}
> command. Need to add appropriate copy steps to
> {{assembly/release-fabric-base.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9559) Node.js thin: nodejs directory should be included binary release
[
https://issues.apache.org/jira/browse/IGNITE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9559:
Issue Type: Improvement (was: Task)
> Node.js thin: nodejs directory should be included binary release
>
>
> Key: IGNITE-9559
> URL: https://issues.apache.org/jira/browse/IGNITE-9559
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Priority: Major
> Labels: nodejs
> Fix For: 2.7
>
>
> Currently, nodejs directory is not generated by the {{maven install}}
> command. Need to add appropriate copy steps to
> {{assembly/release-fabric-base.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9559) Node.js thin: nodejs directory does appear in platforms directory after maven install command
[
https://issues.apache.org/jira/browse/IGNITE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9559:
Issue Type: Task (was: Bug)
> Node.js thin: nodejs directory does appear in platforms directory after maven
> install command
> -
>
> Key: IGNITE-9559
> URL: https://issues.apache.org/jira/browse/IGNITE-9559
> Project: Ignite
> Issue Type: Task
> Components: build, thin client
>Reporter: Igor Sapego
>Priority: Major
> Labels: nodejs
> Fix For: 2.7
>
>
> Currently, nodejs directory is not generated by the {{maven install}}
> command. Need to add appropriate copy steps to
> {{assembly/release-fabric-base.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8552) Unable to use date as primary key
[ https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613514#comment-16613514 ] Sergey Grimstad commented on IGNITE-8552: - Extended tests added Apache header > Unable to use date as primary key > - > > Key: IGNITE-8552 > URL: https://issues.apache.org/jira/browse/IGNITE-8552 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Sergey Grimstad >Priority: Blocker > Fix For: 2.7 > > Attachments: IGNITE-8552_implemented.patch > > > It' is unable to create cache via ddl: > create table tab(id date primary key, date_field date); > Result: > ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to > rollback cache start routine. [cacheName=SQL_PUBLIC_T3] > class org.apache.ignite.IgniteCheckedException: Failed to find value class in > the node classpath (use default marshaller to enable binary objects) : > SQL_PUBLIC_T3_e90848b2_fe30_4adb_a934_6e13ca0eb409 > at > org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:426) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9487) REST: getall can only output keys as scalars
[
https://issues.apache.org/jira/browse/IGNITE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613483#comment-16613483
]
Andrey Novikov commented on IGNITE-9487:
[~ilyak], reviewed. Added notes in pull request.
> REST: getall can only output keys as scalars
>
>
> Key: IGNITE-9487
> URL: https://issues.apache.org/jira/browse/IGNITE-9487
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Regardless of what ConnectorMessageInterceptor does, `getall' command can
> only output key as string or number, and not as JSON object as values can.
> This is because output format is as follows:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":{"CustomType
> [idHash=1588995554, hash=34706515, key=111]":{"val":"111"},"CustomType
> [idHash=978025370, hash=30386820, key=222]":{"val":"222"}},"error":null}
> {code}
> The desired output format may look like:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":[{"key":{"key":111},"value":{"val":"111"}},{"key":{"key":222},"value":{"val":"222"}}],"error":null}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9249) Tests hang when different threads try to start and stop nodes at the same time.
[
https://issues.apache.org/jira/browse/IGNITE-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613471#comment-16613471
]
Ilya Lantukh commented on IGNITE-9249:
--
[~agoncharuk], I've pushed fix for join timeout handling into this PR, please
merge it into master.
> Tests hang when different threads try to start and stop nodes at the same
> time.
> ---
>
> Key: IGNITE-9249
> URL: https://issues.apache.org/jira/browse/IGNITE-9249
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> An example of such test is
> GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithPutFourNodesOneBackupsOffheapEvict().
> Hanged threads:
> {code}
> "restart-worker-1@63424" prio=5 tid=0x7f5e nid=NA waiting
> java.lang.Thread.State: WAITING
> at java.lang.Object.wait(Object.java:-1)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:949)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xfc36> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
> at java.lang.Thread.run(Thread.java:748)
> "restart-worker-0@63423" prio=5 tid=0x7f5d nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7584)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:502)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2258)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1158)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1433)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$800(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
>
[jira] [Commented] (IGNITE-9579) Document Random Forest
[ https://issues.apache.org/jira/browse/IGNITE-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613454#comment-16613454 ] Dmitriy Pavlov commented on IGNITE-9579: [~zaleslaw] could you please always fill ticket description? You can find all Ignite processes and best practices https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > Document Random Forest > -- > > Key: IGNITE-9579 > URL: https://issues.apache.org/jira/browse/IGNITE-9579 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9578) Document K-fold cross validation of models
[ https://issues.apache.org/jira/browse/IGNITE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613453#comment-16613453 ] Dmitriy Pavlov commented on IGNITE-9578: [~zaleslaw] could you please always fill ticket description. You can find all Ignite processes and best practices https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > Document K-fold cross validation of models > -- > > Key: IGNITE-9578 > URL: https://issues.apache.org/jira/browse/IGNITE-9578 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Anton Dmitriev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9578) Document K-fold cross validation of models
[ https://issues.apache.org/jira/browse/IGNITE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613453#comment-16613453 ] Dmitriy Pavlov edited comment on IGNITE-9578 at 9/13/18 1:06 PM: - [~zaleslaw] could you please always fill ticket description? You can find all Ignite processes and best practices https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute was (Author: dpavlov): [~zaleslaw] could you please always fill ticket description. You can find all Ignite processes and best practices https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > Document K-fold cross validation of models > -- > > Key: IGNITE-9578 > URL: https://issues.apache.org/jira/browse/IGNITE-9578 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Anton Dmitriev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9320) MVCC: finalize configuration
[
https://issues.apache.org/jira/browse/IGNITE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613452#comment-16613452
]
Roman Kondakov commented on IGNITE-9320:
[~vozerov], agree with your comments. I've made a fix.
> MVCC: finalize configuration
>
>
> Key: IGNITE-9320
> URL: https://issues.apache.org/jira/browse/IGNITE-9320
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to find a way to configure MVCC caches. Currently this is a global
> setting, which is not very convenient. Proposed solution:
> # Introduce new {{CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT}}
> # Do not allow to change cache this mode during restart (when persistence is
> enabled)
> # Do not allow transactions between {{TRANSACTIONAL}} and
> {{TRANSACTIONAL_SNAPSHOT}} caches
> # Add limitation to cache group - all caches within a group should have the
> same mode
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613450#comment-16613450 ] Dmitriy Pavlov commented on IGNITE-9580: [~aplatonov] could you please fill ticket description? For test you could provide links to failure, stack traces, etc > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Example of failure > https://ci.ignite.apache.org/viewLog.html?buildId=1797966=buildResultsDiv=IgniteTests24Java8_Queries1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-9580: --- Description: Example of failure https://ci.ignite.apache.org/viewLog.html?buildId=1797966=buildResultsDiv=IgniteTests24Java8_Queries1 > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Example of failure > https://ci.ignite.apache.org/viewLog.html?buildId=1797966=buildResultsDiv=IgniteTests24Java8_Queries1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9582) Document Model Updating
Aleksey Zinoviev created IGNITE-9582: Summary: Document Model Updating Key: IGNITE-9582 URL: https://issues.apache.org/jira/browse/IGNITE-9582 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Alexey Platonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613447#comment-16613447 ] ASF GitHub Bot commented on IGNITE-9580: GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4747 IGNITE-9580: Added setMaxSize for ignite configuration in test You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9580 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4747.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 #4747 commit d0a14f0de913a977363ed21bb3c8bf54b35b388a Author: Alexey Platonov Date: 2018-09-13T13:01:02Z added setMaxSize for ignite configuration in test > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9581) Document ANN algorithm based on ACD concept
Aleksey Zinoviev created IGNITE-9581: Summary: Document ANN algorithm based on ACD concept Key: IGNITE-9581 URL: https://issues.apache.org/jira/browse/IGNITE-9581 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613446#comment-16613446 ] Alexey Platonov commented on IGNITE-9580: - [https://ci.ignite.apache.org/viewLog.html?buildId=1797966=buildResultsDiv=IgniteTests24Java8_Queries1] > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9579) Document Random Forest
Aleksey Zinoviev created IGNITE-9579: Summary: Document Random Forest Key: IGNITE-9579 URL: https://issues.apache.org/jira/browse/IGNITE-9579 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Alexey Platonov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
Alexey Platonov created IGNITE-9580: --- Summary: Fix exit code 137 in Query 1 Suite Key: IGNITE-9580 URL: https://issues.apache.org/jira/browse/IGNITE-9580 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov Assignee: Alexey Platonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9578) Document K-fold cross validation of models
Aleksey Zinoviev created IGNITE-9578: Summary: Document K-fold cross validation of models Key: IGNITE-9578 URL: https://issues.apache.org/jira/browse/IGNITE-9578 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Anton Dmitriev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9577) Document Preprocessing
Aleksey Zinoviev created IGNITE-9577: Summary: Document Preprocessing Key: IGNITE-9577 URL: https://issues.apache.org/jira/browse/IGNITE-9577 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9576) Document Multi-Class Logistic Regression
Aleksey Zinoviev created IGNITE-9576: Summary: Document Multi-Class Logistic Regression Key: IGNITE-9576 URL: https://issues.apache.org/jira/browse/IGNITE-9576 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9575) Document Binary Logistic Regression
Aleksey Zinoviev created IGNITE-9575: Summary: Document Binary Logistic Regression Key: IGNITE-9575 URL: https://issues.apache.org/jira/browse/IGNITE-9575 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613439#comment-16613439 ] Amelchev Nikita commented on IGNITE-4111: - I partially fixed PR provided by [~ein]: - Fix for SSL. (It was also incorrect behavior) - Moved out message class to others messages. - Used internal utilities. - I have rewritten test. The provided test doesn't reproduce a problem correctly. Also, I have added the test for the case when SSL enabled. - Fixed code style problems. [TC tests|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4685%2Fhead] - OK > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Amelchev Nikita >Priority: Minor > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9574) Document Gradient boosting
Aleksey Zinoviev created IGNITE-9574: Summary: Document Gradient boosting Key: IGNITE-9574 URL: https://issues.apache.org/jira/browse/IGNITE-9574 Project: Ignite Issue Type: Task Components: documentation, ml Reporter: Aleksey Zinoviev Assignee: Alexey Platonov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9465) Node.js client: improve complex object flags processing
[ https://issues.apache.org/jira/browse/IGNITE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613419#comment-16613419 ] Alexey Kosenchuk commented on IGNITE-9465: -- [~isapego] 1) is an issue of interoperability between different clients (eg. java and nodejs). No issues if nodejs works with nodejs. 2) and 3) are improvements/optimizations. > Node.js client: improve complex object flags processing > --- > > Key: IGNITE-9465 > URL: https://issues.apache.org/jira/browse/IGNITE-9465 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > 1) fix the issue in the full schema support > 2) do not throw exception when object with HAS_RAW_DATA flag is received > 3) support OFFSET_*_BYTE flags/optimizations when writing data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9313) ML TF integration: killed user script or chief processes didn't restart workers
[
https://issues.apache.org/jira/browse/IGNITE-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Zinoviev updated IGNITE-9313:
-
Ignite Flags: (was: Docs Required)
> ML TF integration: killed user script or chief processes didn't restart
> workers
>
>
> Key: IGNITE-9313
> URL: https://issues.apache.org/jira/browse/IGNITE-9313
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Anton Dmitriev
>Priority: Major
> Labels: tf-integration
> Fix For: 2.7
>
>
> Case:
> * Run cluster
> * Filling caches with data
> * Running python script
> * Killing user script or chief
> Expected:
> - chief and user script processes shutdown and run again on same node (-)
> - rerun user script (-) (+)
> - directory with metadata was deleted and created new one in /tmp (-)
> Actual:
> - chief or user script shutting down and run again
> - all workers still running and didn't restart
> - directory with metadata (/tmp/tf_us_*) not deleted
> - new directory with metadata is not created after restart
> - user script did not rerun after 'chief process' killing ('user_script'
> process killing restarting script execution)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9338) ML TF integration: tf cluster can't connect after killing first node with default port 10800
[ https://issues.apache.org/jira/browse/IGNITE-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-9338: - Ignite Flags: (was: Docs Required) > ML TF integration: tf cluster can't connect after killing first node with > default port 10800 > > > Key: IGNITE-9338 > URL: https://issues.apache.org/jira/browse/IGNITE-9338 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Stepan Pilschikov >Assignee: Anton Dmitriev >Priority: Major > Labels: tf-integration > Fix For: 2.7 > > > Case: > - Run cluster with 3 node on 1 host > - Filling caches with data > - Running python script > - Killing lead node with port 10800 with chief + user_script processes > Expect: > - chief and user_script restarted on other node > - script rerun > Actual: > - chief and user_secript restarted on other node but started to crash and run > again because can't connect to default 10800 port -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9278) ML TF integration: Can't find free ports in range
[
https://issues.apache.org/jira/browse/IGNITE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Zinoviev updated IGNITE-9278:
-
Ignite Flags: (was: Docs Required)
> ML TF integration: Can't find free ports in range
> -
>
> Key: IGNITE-9278
> URL: https://issues.apache.org/jira/browse/IGNITE-9278
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
> Environment: CentOS 7
> Java 8
> Python 3.6.3
> Ports in range 1-11000 are free
>Reporter: Stepan Pilschikov
>Assignee: Anton Dmitriev
>Priority: Major
> Labels: tf-integration
> Fix For: 2.7
>
>
> - Running cluster
> - Fill caches
> - Start script
> Exception in nodes log
> {code:java}
> >>> >>> >>> >>> >>> ... ... ... ... ... ... ... >>> ... ... ... ... >>> >>>
> >>> >>> >>> >>> >>> >>>
> [15:27:50,295][SEVERE][service-#105][GridServiceProcessor] Service execution
> stopped with error [name=TF_SERVICE_2e3875d0-1471-4f58-b51a-28d6e2dc8497,
> execId=d40f3ffd-547c-4f26-867e-07c48b867bd5]
> java.lang.IllegalStateException: No free ports in range [from=1, cnt=1000]
> at
> org.apache.ignite.tensorflow.cluster.util.ClusterPortManager.acquirePort(ClusterPortManager.java:107)
> at
> org.apache.ignite.tensorflow.cluster.util.TensorFlowClusterResolver.resolveAndAcquirePortsForWorkers(TensorFlowClusterResolver.java:103)
> at
> org.apache.ignite.tensorflow.cluster.util.TensorFlowClusterResolver.resolveAndAcquirePorts(TensorFlowClusterResolver.java:67)
> at
> org.apache.ignite.tensorflow.cluster.TensorFlowClusterManager.createCluster(TensorFlowClusterManager.java:116)
> at
> org.apache.ignite.tensorflow.cluster.TensorFlowClusterMaintainer.execute(TensorFlowClusterMaintainer.java:138)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$3.run(GridServiceProcessor.java:1396)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9336) [ML] ANN/SVM Trainer tests produce unpredictable results due to random data generation
[ https://issues.apache.org/jira/browse/IGNITE-9336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-9336: - Ignite Flags: (was: Docs Required) > [ML] ANN/SVM Trainer tests produce unpredictable results due to random data > generation > -- > > Key: IGNITE-9336 > URL: https://issues.apache.org/jira/browse/IGNITE-9336 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > Remove random data generation and add static dataset into tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9482) [ML] Refactor all trainers' settters to withFieldName format for meta-algorithms
[ https://issues.apache.org/jira/browse/IGNITE-9482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-9482: - Ignite Flags: (was: Docs Required) > [ML] Refactor all trainers' settters to withFieldName format for > meta-algorithms > > > Key: IGNITE-9482 > URL: https://issues.apache.org/jira/browse/IGNITE-9482 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.7 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9393) [ML] KMeans fails on complex data in cache
[ https://issues.apache.org/jira/browse/IGNITE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-9393: - Ignite Flags: (was: Docs Required) > [ML] KMeans fails on complex data in cache > -- > > Key: IGNITE-9393 > URL: https://issues.apache.org/jira/browse/IGNITE-9393 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > Described here > http://apache-ignite-users.70518.x6.nabble.com/NPE-exception-in-KMeansTrainer-td23504.html#a23512 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9411) Lock: make sure lock timeouts works fine
[ https://issues.apache.org/jira/browse/IGNITE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613412#comment-16613412 ] ASF GitHub Bot commented on IGNITE-9411: GitHub user pavlukhin opened a pull request: https://github.com/apache/ignite/pull/4745 IGNITE-9411: mvcc timeouts You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9411 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4745.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 #4745 commit db172dfc174614af7cbac8b5cecb2707b49e1bdc Author: ipavlukhin Date: 2018-09-04T10:53:41Z minors in CacheMvccSelectForUpdateQueryAbstractTest commit c288988dd4f3622c8539ab7f6f3f84b5c08b7a0c Author: ipavlukhin Date: 2018-09-04T11:13:01Z use timeout modes in deadlock tests commit e4bf4ae3bdcd8b049e66a90f30fb5720b34fd36c Author: ipavlukhin Date: 2018-09-12T10:10:50Z CacheMvccSqlLockTimeoutTest checking that waiting locks are timed out commit 3ad0289ade9964e8a9ec74e10f3f05ed96d72bfc Author: ipavlukhin Date: 2018-09-12T12:27:55Z translate to timeout exception in reducer commit 9d70e0ff36546ae05230481688b9a5f3b7bd7311 Author: ipavlukhin Date: 2018-09-12T12:29:53Z translate to timeout exception in DmlStatementsProcessor commit d34b1b88a498dd090efad058292f0ea19bbd5bef Author: ipavlukhin Date: 2018-09-12T13:31:58Z Merge branch 'master' into mvcc-lock-timeouts commit 0bb7981f9459a797cde4aa97fa200b3502b6b923 Author: ipavlukhin Date: 2018-09-12T14:28:06Z dirty conversion of remote timeout to TransactionTimeoutException, check new exception structure in test commit 9539ef913a8bdd364d8a449c3b4e8aecaace57ef Author: ipavlukhin Date: 2018-09-13T08:57:21Z establish first design for timeout exceptions propagation, put missing timeouts in place commit c7eea3664dec1aa09facee14ce24941dfa39b180 Author: ipavlukhin Date: 2018-09-13T09:59:34Z remove extra stack trace garbage from test commit 197f3e37c0cb2fa0337c880f2e66d55a878ce809 Author: ipavlukhin Date: 2018-09-13T10:31:22Z use common method for timeout calculation in DmlStatementsProcessor commit 980d43dcee8e8a540788c7305ad53280c88269c9 Author: ipavlukhin Date: 2018-09-13T12:06:58Z fix forgotten tx variable initialization in IgniteH2Indexing commit 75ba8821d844c8e7d250154b3fb68adaae842902 Author: ipavlukhin Date: 2018-09-13T12:15:51Z remove duplicated tests from suite > Lock: make sure lock timeouts works fine > > > Key: IGNITE-9411 > URL: https://issues.apache.org/jira/browse/IGNITE-9411 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > In SQL it is not uncommon that locks are taken in arbitrary order, what may > lead to deadlocks. Fair deadlock detector is good solution in monolithic > databases - just analyze dependency graph and kill one of conflicting > transactions. > We have a ticket to implement distributed deadlock detector in Ignite [1]. > However, this solution is rather complex and may bring some overhead. > For now it is better to rely on some timeout (global or per-transaction), and > rollback TX when it fails to lock certain entry for a long time. Probably we > already have this feature in some form. Need to add verify that it works and > add more tests if needed. > [1] https://issues.apache.org/jira/browse/IGNITE-9322 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613411#comment-16613411 ] ASF GitHub Bot commented on IGNITE-8149: Github user pavlukhin closed the pull request at: https://github.com/apache/ignite/pull/4743 > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
