[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[
https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454017#comment-17454017
]
Ignite TC Bot commented on IGNITE-9386:
---
{panel:title=Branch: [pull/9362/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6159829]]
* IgniteCoreTest: BinaryIdentityResolverTestSuite: IdentityEquilityWithGuid -
New test duration 64s is more that 1 minute
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6307127]]
* IgnitePdsWithIndexingTestSuite:
IgniteClusterSnapshotRestoreWithIndexingTest.testClusterSnapshotRestoreOnBiggerTopology
- New test duration 63s is more that 1 minute
{panel}
{panel:title=Branch: [pull/9362/head] Base: [master] : New Tests
(4743)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Open Census{color} [[tests
83|https://ci.ignite.apache.org/viewLog.html?buildId=6159823]]
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationResetAllTest.testThatResetAllResetsAllTracingConfigurations
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTxTracingTest.testCloseTransaction - PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusMetricExporterSpiTest.testHistogram - PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetAllTest.testThatDefaultConfigurationReturnsIfScopeNotSpecifiedAndCustomConfigurationNotSet
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetAllTest.testThatDefaultScopeSpecificConfigurationReturnsIfScopeIsSpecifiedAndCustomConfigurationNotSet
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetAllTest.testThatCustomConfigurationReturnsIfScopeNotSpecifiedAndCustomConfigurationIsSet
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetTest.testThatScopeSpecificConfigurationGetReturnsScopeSpecificEventIfLabelSpecificIsSet
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetTest.testThatScopeSpecificConfigurationGetReturnsCustomScopeSpecific
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetTest.testThatLabelSpecificConfigurationGetReturnsCustomScopeSpecificIfLabelSpecificIsNotSet
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingConfigurationGetTest.testThatLabelSpecificConfigurationGetReturnsLabelSpecificOne
- PASSED{color}
* {color:#013220}IgniteOpenCensusSuite:
OpenCensusTracingSpiTest.testCustomEventContainsMessageClassTag - PASSED{color}
... and 72 new tests
{color:#8b}Platform .NET (NuGet)*{color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6159813]]
* {color:#013220}exe: StartupTest.TestSpringConfig - PASSED{color}
* {color:#013220}exe: AspNetTest.TestSetGet - PASSED{color}
* {color:#013220}exe: SchemaTest.TestSchemavalidation - PASSED{color}
* {color:#013220}exe: CacheTest.TestLinq - PASSED{color}
* {color:#013220}exe: EntityFrameworkCacheTest.TestStartupPutGet - PASSED{color}
* {color:#013220}exe: CacheTest.TestPutGet - PASSED{color}
* {color:#013220}exe: Log4NetTest.TestIgniteStartup - PASSED{color}
* {color:#013220}exe: CacheTest.TestSql - PASSED{color}
* {color:#013220}exe: ComputeTest.TestCompute - PASSED{color}
* {color:#013220}exe: StartupTest.TestApacheIgniteExe - PASSED{color}
* {color:#013220}exe: NLogTest.TestIgniteStartup - PASSED{color}
... and 1 new tests
{color:#8b}AWS{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=6159736]]
* {color:#013220}IgniteS3TestSuite: DummyS3ClientTest.testDoesBucketExist -
PASSED{color}
* {color:#013220}IgniteS3TestSuite: DummyS3ClientTest.testCreateBucket -
PASSED{color}
* {color:#013220}IgniteS3TestSuite:
S3CheckpointSpiStartStopSSEAlgorithmSelfTest.testStop - PASSED{color}
* {color:#013220}IgniteS3TestSuite: DummyS3ClientTest.testListObjects -
PASSED{color}
* {color:#013220}IgniteS3TestSuite:
TcpDiscoveryS3IpFinderKeyPrefixSelfTest.testIpFinder - PASSED{color}
* {color:#013220}IgniteS3TestSuite:
DummyS3ClientTest.testListObjectsWithAPrefix - PASSED{color}
* {color:#013220}IgniteS3TestSuite:
SymmetricKeyEncryptionServiceTest.testEncryptDecrypt - PASSED{color}
* {color:#013220}IgniteS3TestSuite:
DummyObjectListingTest.testDummyObjectListing - PASSED{color}
* {color:#013220}IgniteS3TestSuite:
AsymmetricKeyEncryptionServiceTest.testEncryptDecrypt - PASSED{color}
* {color:#013220}IgniteS3TestSuite:
MockEncryptionServiceTest.testEncryptDecrypt - PASSED{color}
* {color:#013220}IgniteS3TestSuite:
AwsKmsEncryptionServiceTest.testEncryptDecrypt - PASSED{color}
... and 5 new tests
{color:#8b}Hibernate 5.1{color} [[tests
[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451644#comment-17451644 ] Rodion Smolnikov commented on IGNITE-9386: -- [~ascherbakov] Please, make an additional review > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Assignee: Rodion Smolnikov >Priority: Major > Fix For: 2.13 > > Time Spent: 1.5h > Remaining Estimate: 0h > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17410596#comment-17410596 ] Vladimir Malinovskiy commented on IGNITE-9386: -- [~Smolnikov] I've reviewed the changes and left some comments in the PR. > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Assignee: Rodion Smolnikov >Priority: Major > Fix For: 2.11 > > Time Spent: 40m > Remaining Estimate: 0h > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408842#comment-17408842 ] Rodion Smolnikov commented on IGNITE-9386: -- [~vmalinovskiy] please, review the PR > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Assignee: Rodion Smolnikov >Priority: Major > Fix For: 2.11 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[
https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408723#comment-17408723
]
Ignite TC Bot commented on IGNITE-9386:
---
{panel:title=Branch: [pull/9362/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9362/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6159835buildTypeId=IgniteTests24Java8_RunAll]
> control.sh --tx can produce confusing results when limit is set to small value
> --
>
> Key: IGNITE-9386
> URL: https://issues.apache.org/jira/browse/IGNITE-9386
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Alexey Scherbakov
>Assignee: Rodion Smolnikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This is happening because currently the limit is applied to primary and
> backup transactions, which breaks output post-filtering (removal of primary
> and backup transactions from output if near is present).
> Possible solution: apply limit only to near valid transactions. If some txs
> have no near part (broken tx topology), they should be always visible in
> output, probably with special "broken" marking.
> Best way to achieve this - implement tx paging on client side (using
> continuous mapping)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17330074#comment-17330074 ] Alexand Polyakov commented on IGNITE-9386: -- relevant for master (2021.04.23) > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Alexey Scherbakov >Priority: Major > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.3.4#803005)
