[jira] [Commented] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876660#comment-16876660 ] Stanislav Lukyanov commented on IGNITE-11312: - [~surajsn], this issue is for a code change, not documentation fix. The end goal is, to put it simply, to allow enforceJoinOrder flag to be set in DBeaver UI via checkbox. To make this work one needs to fix the discrepancy between how the properties are reported in getPropertiesInfo and how they’re processed. E.g. preponderance each property in getPropertiesInfo by ignite.jdbc. > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Suraj Singh >Priority: Major > Labels: newbie > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11912) [IEP-35] Research possibility to optimize MetricRegistry
[ https://issues.apache.org/jira/browse/IGNITE-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-11912. -- Resolution: Duplicate > [IEP-35] Research possibility to optimize MetricRegistry > > > Key: IGNITE-11912 > URL: https://issues.apache.org/jira/browse/IGNITE-11912 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > We should research and benchmark different data structure for a > MetricRegistry implementation. > A basic assumption of `MetricRegistry` usage: > 1. Collection of metrics almost constant during Ignite lifetime. It will be > changed on cache creation(destroy) and other not frequent operations. > 2. Collection of metrics will be read very frequently(each several seconds or > frequently) by configured metric exporters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11920) [IEP-35] Improve Metric API
[
https://issues.apache.org/jira/browse/IGNITE-11920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-11920.
--
Resolution: Duplicate
> [IEP-35] Improve Metric API
> ---
>
> Key: IGNITE-11920
> URL: https://issues.apache.org/jira/browse/IGNITE-11920
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
>
> MetricRegistry may be made safer if we explicitly extract a group of metrics
> for some Ignite entity(cache, service, etc.).
> Internally, the registry will stay the same.
> API proposition is:
> {code:java}
> MetricRegistry {
> MetricSet default();
> MetricSet group(String name);
> }
> MetricSet {
> LongCounter counter();
> void registrer(Metric m);
> //other methods.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11951) Set ThreadLocal node name only once in JdkMarshaller
Ivan Pavlukhin created IGNITE-11951:
---
Summary: Set ThreadLocal node name only once in JdkMarshaller
Key: IGNITE-11951
URL: https://issues.apache.org/jira/browse/IGNITE-11951
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
Currently {{JdkMarshaller}} saves a node name twice in couple of
marshall/unmarshall methods. Code can be improved to do it only once.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876385#comment-16876385 ] Ivan Fedotov edited comment on IGNITE-10973 at 7/1/19 5:49 PM: --- [~Pavlukhin] , part of the name in parentheses means path. In the case, where names are different in the version before path consists from "path to suite: path to test" and in the version after just "path to test". I tried to find the place in the code where it is constructed. It seems that TC took this path from JUnit and it does not configure inside Ignite. But maybe I am wrong and we can configure it from TC. [~ein] could you please clarify is it possible to configure test name in parentheses in TC? was (Author: ivanan.fed): [~Pavlukhin] , part of the name in parentheses means path. In the case, where names are different in the version before path consists from "path to suite: path to test" and in the version after just "path to test". I tried to find the place in the code where it is constructed. It seems that TC took this path from JUnit and it does not configure inside Ignite. But maybe I am wrong and we can configure it from TC. [~ein] could you please clarify is it possible to configure test name in parentheses in TC? > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876385#comment-16876385 ] Ivan Fedotov commented on IGNITE-10973: --- [~Pavlukhin] , part of the name in parentheses means path. In the case, where names are different in the version before path consists from "path to suite: path to test" and in the version after just "path to test". I tried to find the place in the code where it is constructed. It seems that TC took this path from JUnit and it does not configure inside Ignite. But maybe I am wrong and we can configure it from TC. [~ein] could you please clarify is it possible to configure test name in parentheses in TC? > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11950) Typo in log message about automatic adjustment of WAL archive size
[
https://issues.apache.org/jira/browse/IGNITE-11950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876338#comment-16876338
]
Dmitriy Pavlov commented on IGNITE-11950:
-
I've also added you to the list of Contributors, so now you can assign and
resolve issues in IGNITE project in Jira.
> Typo in log message about automatic adjustment of WAL archive size
> --
>
> Key: IGNITE-11950
> URL: https://issues.apache.org/jira/browse/IGNITE-11950
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7.5
>Reporter: Jan Schäfer
>Assignee: Jan Schäfer
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If the WAL archive size is not set correctly the resulting log message
> contains a typo:
> {noformat}
> Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
> DataStorageConfiguration.setMaxWalArhiveSize){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11950) Typo in log message about automatic adjustment of WAL archive size
[
https://issues.apache.org/jira/browse/IGNITE-11950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-11950:
---
Assignee: Jan Schäfer
> Typo in log message about automatic adjustment of WAL archive size
> --
>
> Key: IGNITE-11950
> URL: https://issues.apache.org/jira/browse/IGNITE-11950
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7.5
>Reporter: Jan Schäfer
>Assignee: Jan Schäfer
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If the WAL archive size is not set correctly the resulting log message
> contains a typo:
> {noformat}
> Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
> DataStorageConfiguration.setMaxWalArhiveSize){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876325#comment-16876325 ] Ivan Fedotov commented on IGNITE-11849: --- [~Pavlukhin], I rerun _IgniteCacheReadThroughEvictionSelfTest_ locally multiple times from IDEA and it passes. Through suite, _IgniteCacheReadThroughEvictionsVariationsSuite_ situation is the same. Could you please try it on branch IGNITE-11849 one more time? > Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest > > > Key: IGNITE-11849 > URL: https://issues.apache.org/jira/browse/IGNITE-11849 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Time Spent: 10m > Remaining Estimate: 0h > > According to the test scenario after expiration entry must be present in > IgniteCache - it will be loaded from CacheStore. > It is necessary to specify CacheStore in node config [1]. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheReadThroughEvictionSelfTest.java#L233 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11950) Typo in log message about automatic adjustment of WAL archive size
[
https://issues.apache.org/jira/browse/IGNITE-11950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-11950:
-
Ignite Flags: (was: Docs Required)
> Typo in log message about automatic adjustment of WAL archive size
> --
>
> Key: IGNITE-11950
> URL: https://issues.apache.org/jira/browse/IGNITE-11950
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7.5
>Reporter: Jan Schäfer
>Priority: Minor
> Fix For: 2.8
>
>
> If the WAL archive size is not set correctly the resulting log message
> contains a typo:
> {noformat}
> Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
> DataStorageConfiguration.setMaxWalArhiveSize){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11950) Typo in log message about automatic adjustment of WAL archive size
[
https://issues.apache.org/jira/browse/IGNITE-11950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-11950:
-
Description:
If the WAL archive size is not set correctly the resulting log message contains
a typo:
{noformat}
Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
DataStorageConfiguration.setMaxWalArhiveSize){noformat}
was:
IF the WAL archive size is not set correctly the resulting log message contains
a typo:
{noformat}
Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
DataStorageConfiguration.setMaxWalArhiveSize){noformat}
> Typo in log message about automatic adjustment of WAL archive size
> --
>
> Key: IGNITE-11950
> URL: https://issues.apache.org/jira/browse/IGNITE-11950
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7.5
>Reporter: Jan Schäfer
>Priority: Minor
> Fix For: 2.8
>
>
> If the WAL archive size is not set correctly the resulting log message
> contains a typo:
> {noformat}
> Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
> DataStorageConfiguration.setMaxWalArhiveSize){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11950) Typo in log message about automatic adjustment of WAL archive size
Jan Schäfer created IGNITE-11950:
Summary: Typo in log message about automatic adjustment of WAL
archive size
Key: IGNITE-11950
URL: https://issues.apache.org/jira/browse/IGNITE-11950
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7.5
Reporter: Jan Schäfer
Fix For: 2.8
IF the WAL archive size is not set correctly the resulting log message contains
a typo:
{noformat}
Automatically adjusted max WAL archive size to 8.0 GiB (to override, use
DataStorageConfiguration.setMaxWalArhiveSize){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876287#comment-16876287
]
Aleksey Plekhanov commented on IGNITE-11685:
[~isapego], yes, sure, it's OK. Thank you.
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.
[ https://issues.apache.org/jira/browse/IGNITE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876274#comment-16876274 ] Denis Mekhanikov commented on IGNITE-3653: -- [~Pavlukhin], good catch, thanks. Fixed. > P2P doesn't work for remote filter and filter factory. > -- > > Key: IGNITE-3653 > URL: https://issues.apache.org/jira/browse/IGNITE-3653 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolai Tikhonov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Attachments: CCP2PTest.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Remote filter and filter factory classes were not deployed on nodes which > join to cluster after their initialization. Test attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.
[ https://issues.apache.org/jira/browse/IGNITE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876254#comment-16876254 ] Ivan Pavlukhin commented on IGNITE-3653: [~dmekhanikov], I left a small [comment|https://github.com/apache/ignite/pull/4566#pullrequestreview-256381353] on GitHub regarding enabling one test. > P2P doesn't work for remote filter and filter factory. > -- > > Key: IGNITE-3653 > URL: https://issues.apache.org/jira/browse/IGNITE-3653 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolai Tikhonov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Attachments: CCP2PTest.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Remote filter and filter factory classes were not deployed on nodes which > join to cluster after their initialization. Test attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876237#comment-16876237
]
Igor Sapego edited comment on IGNITE-11685 at 7/1/19 2:48 PM:
--
[~alex_pl] sure, let me take a look. I'll leave my comments in 1-2 days. Is
that OK?
was (Author: isapego):
[~alex_pl] sure, let me take a look.
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876237#comment-16876237
]
Igor Sapego commented on IGNITE-11685:
--
[~alex_pl] sure, let me take a look.
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876229#comment-16876229
]
Aleksey Plekhanov commented on IGNITE-11685:
[~isapego], can you please review the PR?
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
Aleksey Plekhanov created IGNITE-11949: -- Summary: Yardstick benchmarks for WAL page snapshot compression Key: IGNITE-11949 URL: https://issues.apache.org/jira/browse/IGNITE-11949 Project: Ignite Issue Type: Improvement Components: yardstick Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov WAL page snapshots compression (implemented by IGNITE-11336) can be enabled by modifying config.xml file. It will be better to configure benchmarks by command line options. Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876054#comment-16876054 ] Ivan Pavlukhin edited comment on IGNITE-11907 at 7/1/19 2:10 PM: - [~dmekhanikov] could you please take a look (it is not ready to be merged, code style and tests are not ready yet)? was (Author: pavlukhin): [~dmekhanikov] could you please take a look? > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11874) Fix mismatch between idle_verify results with and without -dump option.
[ https://issues.apache.org/jira/browse/IGNITE-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876191#comment-16876191 ] Vladimir Malinovskiy commented on IGNITE-11874: --- I've reviewed changes. Looks good to me. > Fix mismatch between idle_verify results with and without -dump option. > --- > > Key: IGNITE-11874 > URL: https://issues.apache.org/jira/browse/IGNITE-11874 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > In VerifyBackupPartitionsTaskV2 , when arg is not instance of > VisorIdleVerifyDumpTaskArg (i. e. idle_verify is launched without dump > option), the set of filtered caches contains all caches including system > ones, while by default system caches should be excluded. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11948) Row count statistics tests fail frequently
Ivan Pavlukhin created IGNITE-11948: --- Summary: Row count statistics tests fail frequently Key: IGNITE-11948 URL: https://issues.apache.org/jira/browse/IGNITE-11948 Project: Ignite Issue Type: Bug Components: sql Reporter: Ivan Pavlukhin RowCountTableStatisticsSurvivesNodeRestartTest and RowCountTableStatisticsUsageTest fail frequently on TC https://ci.ignite.apache.org/viewLog.html?buildId=4238573=IgniteTests24Java8_BinaryObjectsSimpleMapperQueries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11948) Row count statistics tests fail frequently
[ https://issues.apache.org/jira/browse/IGNITE-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-11948: Affects Version/s: 2.7.5 > Row count statistics tests fail frequently > -- > > Key: IGNITE-11948 > URL: https://issues.apache.org/jira/browse/IGNITE-11948 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7.5 >Reporter: Ivan Pavlukhin >Priority: Major > > RowCountTableStatisticsSurvivesNodeRestartTest and > RowCountTableStatisticsUsageTest fail frequently on TC > https://ci.ignite.apache.org/viewLog.html?buildId=4238573=IgniteTests24Java8_BinaryObjectsSimpleMapperQueries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11844: Fix Version/s: 2.8 > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876072#comment-16876072 ] Sergey Chugunov edited comment on IGNITE-11844 at 7/1/19 10:30 AM: --- [~6uest], I reviewed latest patch, it looks good to me now. Please proceed with merging and thank you for the contribution! [~DmitriyGovorukhin], could you please take a look and merge this change to master? was (Author: sergey-chugunov): [~6uest], I reviewed latest patch, it looks good to me now. Please proceed with merging and thank you for the contribution! > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11947) [TC Bot] New failures notification are absent for several new failures
Dmitriy Pavlov created IGNITE-11947: --- Summary: [TC Bot] New failures notification are absent for several new failures Key: IGNITE-11947 URL: https://issues.apache.org/jira/browse/IGNITE-11947 Project: Ignite Issue Type: Bug Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Notifications to email are missed sometimes. One possible reason is buildStartTs, which was not filled correctly in Issue, but after fix https://github.com/apache/ignite-teamcity-bot/commit/5573467d04eedbe9f79dd2b19e9675b76af78985 the situation is still the same, notifications not send -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876072#comment-16876072 ] Sergey Chugunov commented on IGNITE-11844: -- [~6uest], I reviewed latest patch, it looks good to me now. Please proceed with merging and thank you for the contribution! > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876054#comment-16876054 ] Ivan Pavlukhin commented on IGNITE-11907: - [~dmekhanikov] could you please take a look? > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876051#comment-16876051 ] Ivan Pavlukhin commented on IGNITE-11907: - I tried to get rid of old registration mechanism and keeping only one and use it for both discovery implementations but observed new test failures. It seems that old mechanism removal should be done more careful. As a result I prepared a PR with changes aiming to allow further processing in case of missing classes in a CQ registration message. > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
[
https://issues.apache.org/jira/browse/IGNITE-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876028#comment-16876028
]
Anton Kalashnikov commented on IGNITE-11914:
[~ibessonov], In generall your changes looks good for me. But I have one
proposal: maybe it better to avoid boolean flag(panic mark) on public api and
instead use two methods such as "umarshalData" and
"unmarshalDataIfPossible"(name of methods can be changed it just the example)
> Failures to deserialize discovery data should be handled by a failure handler
> -
>
> Key: IGNITE-11914
> URL: https://issues.apache.org/jira/browse/IGNITE-11914
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Denis Mekhanikov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Attachments: DiscoveryDataDeserializationFailureHanderTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a node during join receives a discovery data packet, that it cannot
> deserialize, then this error is printed to log and not handled in any way. It
> leads to swallowing potentially important failures.
> For example, a failure to deserialize a continuous query remote filter should
> be propagated to a failure handler, but it doesn't happen. Test is attached.
> Error message:
> {noformat}
> Failed to unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
> at
[jira] [Commented] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.
[ https://issues.apache.org/jira/browse/IGNITE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876009#comment-16876009 ] Dmitriy Govorukhin commented on IGNITE-3653: [~dmekhanikov] Looks good for me. > P2P doesn't work for remote filter and filter factory. > -- > > Key: IGNITE-3653 > URL: https://issues.apache.org/jira/browse/IGNITE-3653 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolai Tikhonov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Attachments: CCP2PTest.patch > > > Remote filter and filter factory classes were not deployed on nodes which > join to cluster after their initialization. Test attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4220768buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
> Time Spent: 17h 50m
> Remaining Estimate: 0h
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withReadRepair().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4214540buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
> Time Spent: 17h 50m
> Remaining Estimate: 0h
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withReadRepair().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
