[jira] [Created] (IGNITE-17469) cli profile commands unification
Yury Yudin created IGNITE-17469: --- Summary: cli profile commands unification Key: IGNITE-17469 URL: https://issues.apache.org/jira/browse/IGNITE-17469 Project: Ignite Issue Type: Improvement Components: cli, ignite-3 Reporter: Yury Yudin cli config profile now has two commands show and create, while setting a profile is done through a parameter, which is confusing. There should be a separate command to set the profile. In general I would suggest the commands there to look like: cli config show cli config set cli config get All cli commands should not accept --profile or -p parameters, all setting and getting of the params in a profile should go through its activation instead. I.e. cli config profile create newprofile ; cli config profile activate newprofile; cli config set ignite.cluster-url=[http://localhost:10300|http://localhost:10300/] Profile manipulation should go like below: cli config profile show [] cli config profile list cli config profile create --copy-from cli config profile activate -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15759) [IEP-80] Removal of LOCAL caches support
[
https://issues.apache.org/jira/browse/IGNITE-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575386#comment-17575386
]
Ignite TC Bot commented on IGNITE-15759:
{panel:title=Branch: [pull/10157/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10157/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 8{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6712991]]
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsFifo - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsSorted - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsLru - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6713084buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-80] Removal of LOCAL caches support
>
>
> Key: IGNITE-15759
> URL: https://issues.apache.org/jira/browse/IGNITE-15759
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: IEP-80
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> LOCAL cachens has huge amount of known limitation and not intended to be used
> in production environment.
> Should be removed in 2.13
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17468) Remove current SortedIndex implementation
Aleksandr Polovtcev created IGNITE-17468: Summary: Remove current SortedIndex implementation Key: IGNITE-17468 URL: https://issues.apache.org/jira/browse/IGNITE-17468 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev Since the sorted index interface is going to be refactored in https://issues.apache.org/jira/browse/IGNITE-17308, it is necessary to remove the current implementation as it occupies some useful class names and is not used anywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15455) Support statistics SQL commands on Calcite
[ https://issues.apache.org/jira/browse/IGNITE-15455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575280#comment-17575280 ] Ivan Daschinsky commented on IGNITE-15455: -- After merging IGNITE-15436 ANALYZE, REFRESH and DROP were broken even for H2. IGNITE-17190 fixes this issue, it is required only to add support in CALCITE for these commands here. > Support statistics SQL commands on Calcite > -- > > Key: IGNITE-15455 > URL: https://issues.apache.org/jira/browse/IGNITE-15455 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.13 >Reporter: Alexander Belyak >Assignee: Ivan Daschinsky >Priority: Major > Labels: calcite2-required, calcite3-required > > Need to support ANALYZE, REFRESH and DROP commands similar (or exact) the > same, as they works in 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15455) Support statistics SQL commands on Calcite
[ https://issues.apache.org/jira/browse/IGNITE-15455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-15455: Assignee: Ivan Daschinsky > Support statistics SQL commands on Calcite > -- > > Key: IGNITE-15455 > URL: https://issues.apache.org/jira/browse/IGNITE-15455 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.13 >Reporter: Alexander Belyak >Assignee: Ivan Daschinsky >Priority: Major > Labels: calcite2-required, calcite3-required > > Need to support ANALYZE, REFRESH and DROP commands similar (or exact) the > same, as they works in 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17450) Documentation: thin client CDC streamer
[ https://issues.apache.org/jira/browse/IGNITE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17450: - Component/s: documentation > Documentation: thin client CDC streamer > --- > > Key: IGNITE-17450 > URL: https://issues.apache.org/jira/browse/IGNITE-17450 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Labels: IEP-59 > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Add thin client CDC streamer documentation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17450) Documentation: thin client CDC streamer
[ https://issues.apache.org/jira/browse/IGNITE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17450: - Labels: IEP-59 ise (was: IEP-59) > Documentation: thin client CDC streamer > --- > > Key: IGNITE-17450 > URL: https://issues.apache.org/jira/browse/IGNITE-17450 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Labels: IEP-59, ise > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Add thin client CDC streamer documentation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17450) Documentation: thin client CDC streamer
[ https://issues.apache.org/jira/browse/IGNITE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17450: - Fix Version/s: 2.14 > Documentation: thin client CDC streamer > --- > > Key: IGNITE-17450 > URL: https://issues.apache.org/jira/browse/IGNITE-17450 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Labels: IEP-59 > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Add thin client CDC streamer documentation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17225) Page replacement for persistent data region is not fully ported
[ https://issues.apache.org/jira/browse/IGNITE-17225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-17225: Assignee: Kirill Tkalenko > Page replacement for persistent data region is not fully ported > --- > > Key: IGNITE-17225 > URL: https://issues.apache.org/jira/browse/IGNITE-17225 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Replacing pages for the persistent data region was not fully ported from 2.0, > at the moment we only add pages to the temporary buffer and remove from the > checkpoint (i.e. it will not be written at the checkpoint), but then we do > not write the page from this temporary buffer, this needs to be fixed and > covered with tests. > See in 3.0: > * Usage of > *org.apache.ignite.internal.pagememory.persistence.PersistentPageMemory#delayedPageReplacementTracker* > See in 2.0: > * Usage of > *org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl#delayedPageReplacementTracker* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17146) Add support for alpha, beta, etc. releases in IgniteProductVersion
[
https://issues.apache.org/jira/browse/IGNITE-17146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-17146:
Assignee: Kirill Tkalenko
> Add support for alpha, beta, etc. releases in IgniteProductVersion
> --
>
> Key: IGNITE-17146
> URL: https://issues.apache.org/jira/browse/IGNITE-17146
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-alpha6
>
>
> {code:java}
> org.apache.ignite.internal.properties.IgniteProductVersion#alphaVersion{code}
> has been added for the upcoming 3.0.0-alpha5 release, we need to fix it so
> that we can work with alpha, beta and other releases.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17467) Find out Row id is not possible for MvPartitionStorage
[
https://issues.apache.org/jira/browse/IGNITE-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17467:
---
Component/s: data structures
> Find out Row id is not possible for MvPartitionStorage
> --
>
> Key: IGNITE-17467
> URL: https://issues.apache.org/jira/browse/IGNITE-17467
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Row id is returned only for insert operation, but if you want to find a row
> id by Binary row is not possible.
> I sure, it has to be possible through scan operation. In that case, the scan
> operation can be used as a scan index.
> I would like to see API like:
> {code:java}
> Cursor> scan(Predicate keyFilter, UUID
> txId) throws TxIdMismatchException, StorageException;
> Cursor> scan(Predicate keyFilter,
> Timestamp timestamp) throws StorageException;
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17467) Find out Row id is not possible for MvPartitionStorage
[
https://issues.apache.org/jira/browse/IGNITE-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17467:
---
Labels: ignite-3 (was: )
> Find out Row id is not possible for MvPartitionStorage
> --
>
> Key: IGNITE-17467
> URL: https://issues.apache.org/jira/browse/IGNITE-17467
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Row id is returned only for insert operation, but if you want to find a row
> id by Binary row is not possible.
> I sure, it has to be possible through scan operation. In that case, the scan
> operation can be used as a scan index.
> I would like to see API like:
> {code:java}
> Cursor> scan(Predicate keyFilter, UUID
> txId) throws TxIdMismatchException, StorageException;
> Cursor> scan(Predicate keyFilter,
> Timestamp timestamp) throws StorageException;
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17467) Find out Row id is not possible for MvPartitionStorage
Vladislav Pyatkov created IGNITE-17467:
--
Summary: Find out Row id is not possible for MvPartitionStorage
Key: IGNITE-17467
URL: https://issues.apache.org/jira/browse/IGNITE-17467
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Row id is returned only for insert operation, but if you want to find a row id
by Binary row is not possible.
I sure, it has to be possible through scan operation. In that case, the scan
operation can be used as a scan index.
I would like to see API like:
{code:java}
Cursor> scan(Predicate keyFilter, UUID txId)
throws TxIdMismatchException, StorageException;
Cursor> scan(Predicate keyFilter, Timestamp
timestamp) throws StorageException;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17354) Metrics framework
[ https://issues.apache.org/jira/browse/IGNITE-17354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575192#comment-17575192 ] Andrey N. Gura commented on IGNITE-17354: - [~Denis Chudov]I've took a look at the PR and left some comments. Could you please fix them? > Metrics framework > -- > > Key: IGNITE-17354 > URL: https://issues.apache.org/jira/browse/IGNITE-17354 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Metrics types* > Metrics framework should provide the following metrics types: > - Gauge - is an instantaneous measurement of a value provided by some > existing component. Gauge should support primitive types: int, long, double > - Metric - is just a wrapper on a numeric value which could be increased or > decreased to some value. Metric should support primitive types: int, long, > double. > - Hit Rate - accumulates approximate hit rate statistics based on hits in the > last time interval. > - Distribution - distributes values by buckets where each bucket represent > some numeric interval (Histogram in AI 2). Internal type - primitive long > (should be enough). > *Concurrency characteristics* > For scalar numeric metrics it is enough to have atomic number (e.g. > AtomicInteger) and striped number (e.g. LongAdder). Such approaches affects > memory footprint and performance differently. > *Design* > Metrics should have the same life cycle as well as component that produces > these metrics. So metrics related to some particular component should be tied > together in MetricsSet. the only purpose of metrics set is provide access to > metrics values from exporters. Metrics instances itself placed in > MetricsSource - an entity which keeps instances of metrics and provides > access to the metrics through an interface that is specific for each metrics > source. A component that produces metrics must control metrics source life > cycle (create it and register in metrics registry, see below). > All metrics sources (it is not important, enabled or disabled metrics for > particular metrics source) must be registered in metrics registry on > component start and removed on component stop. > MetricsSource itself produces an instance of MetricsSet which should be > registered in metrics registry on event "metrics enabled" and unregistered on > event "metrics disabled". > Metrics registry provide an access to all metrics sets from exporters side. > It is possible that metrics registry is overloaded by functionality (manage > by metrics sources and metrics sets), so, probably, special component is need > for these purposes (e.g. metrics manager). > Each instance of metric has a name (local in some metric set) and > description. So the full metric name it is a concatenation of metrics source > name and metric name separated by dot. > For composite metrics like distribution we should treat each metrics inside > (e.g. each range) as separate metric. So the full name for each internal > metric will be metrics source + dot + metric instance name + dot + range as > string (e.g. 0_100). > Metrics set must be immutable in order to meet the requirements described in > the epic. > Data structure (likely map) that is responsible for keeping enabled metrics > set should be modified using copy-on-write semantics in order to avoid data > races between main functionality (metrics enabling\disabling) and exporters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15818) [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and re-implementation
[ https://issues.apache.org/jira/browse/IGNITE-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-15818. -- Resolution: Fixed The basic functionality is implemented in child tickets. > [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and > re-implementation > --- > > Key: IGNITE-15818 > URL: https://issues.apache.org/jira/browse/IGNITE-15818 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > h2. Goal > Port and refactor core classes implementing page-based persistent store in > Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager, > PageMemoryImpl, Checkpointer, FileWriteAheadLogManager. > New checkpoint implementation to avoid excessive logging. > Store lifecycle clarification to avoid complicated and invasive code of > custom lifecycle managed mostly by DatabaseSharedManager. > h2. Items to pay attention to > New checkpoint implementation based on split-file storage, new page index > structure to maintain disk-memory page mapping. > File page store implementation should be extracted from > GridCacheOffheapManager to a separate entity, target implementation should > support new version of checkpoint (split-file store to enable > always-consistent store and to eliminate binary recovery phase). > Support of big pages (256+ kB). > Support of throttling algorithms. > h2. References > New checkpoint design overview is available > [here|https://github.com/apache/ignite-3/blob/ignite-14647/modules/vault/README.md] > h2. Thoughts > Although there is a technical opportunity to have independent checkpoints for > different data regions, managing them could be a nightmare and it's > definitely in the realm of optimizations and out of scope right now. > So, let's assume that there's one good old checkpoint process. There's still > a requirement to have checkpoint markers, but they will not have a reference > to WAL, because there's no WAL. Instead, we will have to store RAFT log > revision per partition. Or not, I'm not that familiar with a recovery > procedure that's currently in development. > Unlike checkpoints in Ignite 2.x, that had DO and REDO operations, new > version will have DO and UNDO. This drastically simplifies both checkpoint > itself and node recovery. But is complicates data access. > There will be two process that will share storage resource: "checkpointer" > and "compactor". Let's examine what compactor should or shouldn't do: > * it should not work in parallel with checkpointer, except for cases when > there are too many layers (more on that later) > * it should merge later checkpoint delta files into main partition files > * it should delete checkpoint markers once all merges are completed for it, > thus markers are decoupled from RAFT log > About "cases when there are too many layers" - too many layers could > compromise reading speed. Number of layers should not increase > uncontrollably. So, when a threshold is exceeded, compactor should start > working no mater what. If anything, writing load can be throttled, reading > matters more. > Recovery procedure: > * read the list of checkpoint markers on engines start > * remove all data from unfinished checkpoint, if it's there > * trim main partition files to their proper size (should check it it's > actually beneficial) > Table start procedure: > * read all layer files headers according to the list of checkpoints > * construct a list oh hash tables (pageId -> pageIndex) for all layers, make > it as effective as possible > * everything else is just like before > Partition removal might be tricky, but we'll see. It's tricky in Ignite 2.x > after all. "Restore partition states" procedure could be revisited, I don't > know how this will work yet. > How to store hashmaps: > regular maps might be too much, we should consider roaring map implementation > or something similar that'll occupy less space. This is only a concern for > in-memory structures. Files on disk may have a list of pairs, that's fine. > Generally speaking, checkpoints with a size of 100 thousand pages are close > to the top limit for most users. Splitting that to 500 partitions, for > example, gives us 200 pages per partition. Entire map should fit into a > single page. > The only exception to these calculations is index.bin. Amount of pages per > checkpoint can be an orders of magnitudes higher, so we should keep an eye on > it, It'll be the main target for testing/benchmarking. Anyway, 4 kilobytes is > enough to fit 512 integer pairs, scaling to 2048 for regular 16 kilobytes > pages.
[jira] [Created] (IGNITE-17466) Remove TableStorage and PartitionStorage implementations
Kirill Tkalenko created IGNITE-17466: Summary: Remove TableStorage and PartitionStorage implementations Key: IGNITE-17466 URL: https://issues.apache.org/jira/browse/IGNITE-17466 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Fix For: 3.0.0-alpha6 All implementations of *TableStorage* and *PartitionStorage* should be removed, as well as the code associated with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17451) Provide internal access to BinaryContext in thin client
[
https://issues.apache.org/jira/browse/IGNITE-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575122#comment-17575122
]
Ignite TC Bot commented on IGNITE-17451:
{panel:title=Branch: [pull/10179/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10179/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6711077]]
* {color:#013220}ClientTestSuite: MetadataRegistrationTest.testMapping -
PASSED{color}
* {color:#013220}ClientTestSuite: MetadataRegistrationTest.testBinaryMeta -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6711087buildTypeId=IgniteTests24Java8_RunAll]
> Provide internal access to BinaryContext in thin client
> ---
>
> Key: IGNITE-17451
> URL: https://issues.apache.org/jira/browse/IGNITE-17451
> Project: Ignite
> Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Provide internal access to BinaryContext in thin client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17465) Backport several releases from Jraft to our fork
Mirza Aliev created IGNITE-17465: Summary: Backport several releases from Jraft to our fork Key: IGNITE-17465 URL: https://issues.apache.org/jira/browse/IGNITE-17465 Project: Ignite Issue Type: Task Reporter: Mirza Aliev Assignee: Mirza Aliev TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15759) [IEP-80] Removal of LOCAL caches support
[
https://issues.apache.org/jira/browse/IGNITE-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575093#comment-17575093
]
Ignite TC Bot commented on IGNITE-15759:
{panel:title=Branch: [pull/10157/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10157/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 8{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6710957]]
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsFifo - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsSorted - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsLru - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6708175buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-80] Removal of LOCAL caches support
>
>
> Key: IGNITE-15759
> URL: https://issues.apache.org/jira/browse/IGNITE-15759
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: IEP-80
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> LOCAL cachens has huge amount of known limitation and not intended to be used
> in production environment.
> Should be removed in 2.13
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-17286:
Assignee: Mirza Aliev
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15000) putAllConflict removeAllConfict support in thin client
[
https://issues.apache.org/jira/browse/IGNITE-15000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575088#comment-17575088
]
Ignite TC Bot commented on IGNITE-15000:
{panel:title=Branch: [pull/9915/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9915/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
6|https://ci2.ignite.apache.org/viewLog.html?buildId=6545307]]
* {color:#013220}ClientTestSuite:
DataReplicationOperationsTest.testPutAllConflict[binary=false] - PASSED{color}
* {color:#013220}ClientTestSuite:
DataReplicationOperationsTest.testWithExpiryPolicy[binary=false] - PASSED{color}
* {color:#013220}ClientTestSuite:
DataReplicationOperationsTest.testRemoveAllConflict[binary=false] -
PASSED{color}
* {color:#013220}ClientTestSuite:
DataReplicationOperationsTest.testPutAllConflict[binary=true] - PASSED{color}
* {color:#013220}ClientTestSuite:
DataReplicationOperationsTest.testWithExpiryPolicy[binary=true] - PASSED{color}
* {color:#013220}ClientTestSuite:
DataReplicationOperationsTest.testRemoveAllConflict[binary=true] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6545317buildTypeId=IgniteTests24Java8_RunAll]
> putAllConflict removeAllConfict support in thin client
> --
>
> Key: IGNITE-15000
> URL: https://issues.apache.org/jira/browse/IGNITE-15000
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-59
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{IgniteInternalCache}} contains methods {{putAllConfict}},
> {{removeAllConfict}} that can be used to perform put, remove operations with
> entry {{GridCacheVersion}}.
> To implement multi-cluster replication using thin clients we need to add
> these methods to the thin client protocol.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17464) Network messages multiple inheritance code generation issue
[
https://issues.apache.org/jira/browse/IGNITE-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17464:
-
Description:
COMPILATION ERROR : Getter with name 'a' is already defined is thrown in case
of following network messages inheritance graph.
{code:java}
interface A
void a()
interface B extends A
interface C extends A
interface D extends B,C
{code}
was:
COMPILATION ERROR : Getter with name 'a' is already defined
is thrown in case of following network messages inheritance graph.
{code:java}
interface A
void a()
interface B extends A
interface C extends A
interface D extends B,C
{code}
> Network messages multiple inheritance code generation issue
> ---
>
> Key: IGNITE-17464
> URL: https://issues.apache.org/jira/browse/IGNITE-17464
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> COMPILATION ERROR : Getter with name 'a' is already defined is thrown in case
> of following network messages inheritance graph.
> {code:java}
> interface A
> void a()
>
> interface B extends A
> interface C extends A
> interface D extends B,C
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17464) Network messages multiple inheritance code generation issue.
Alexander Lapin created IGNITE-17464:
Summary: Network messages multiple inheritance code generation
issue.
Key: IGNITE-17464
URL: https://issues.apache.org/jira/browse/IGNITE-17464
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
COMPILATION ERROR : Getter with name 'a' is already defined
is thrown in case of following network messages inheritance graph.
{code:java}
interface A
void a()
interface B extends A
interface C extends A
interface D extends B,C
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17464) Network messages multiple inheritance code generation issue
[
https://issues.apache.org/jira/browse/IGNITE-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17464:
-
Issue Type: Bug (was: Improvement)
> Network messages multiple inheritance code generation issue
> ---
>
> Key: IGNITE-17464
> URL: https://issues.apache.org/jira/browse/IGNITE-17464
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> COMPILATION ERROR : Getter with name 'a' is already defined is thrown in case
> of following network messages inheritance graph.
> {code:java}
> interface A
> void a()
>
> interface B extends A
> interface C extends A
> interface D extends B,C
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17464) Network messages multiple inheritance code generation issue
[
https://issues.apache.org/jira/browse/IGNITE-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17464:
-
Summary: Network messages multiple inheritance code generation issue (was:
Network messages multiple inheritance code generation issue. )
> Network messages multiple inheritance code generation issue
> ---
>
> Key: IGNITE-17464
> URL: https://issues.apache.org/jira/browse/IGNITE-17464
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> COMPILATION ERROR : Getter with name 'a' is already defined
> is thrown in case of following network messages inheritance graph.
>
> {code:java}
> interface A
> void a()
>
> interface B extends A
> interface C extends A
> interface D extends B,C
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
