[jira] [Commented] (IGNITE-16918) Sql. Races during table creation
[
https://issues.apache.org/jira/browse/IGNITE-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545153#comment-17545153
]
Vladislav Pyatkov commented on IGNITE-16918:
[~Denis Chudov] Could you, please review my PR?
> Sql. Races during table creation
>
>
> Key: IGNITE-16918
> URL: https://issues.apache.org/jira/browse/IGNITE-16918
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Random tests fails on TC with the very same error (table name is varying
> though):
> {code:java}
> [14:04:04][executesColocatedWithMappedKey]
> java.util.concurrent.CompletionException
> [14:04:04][executesColocatedWithMappedKey]
> java.util.concurrent.CompletionException:
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 13 to
> line 1, column 16: Object 'TEST' not found
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 13 to line 1, column 16: Object 'TEST' not found
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'TEST' not found
> {code}
>
> Looks like the root cause of this problem is race in between of completion of
> the future returned by {{TableManager#createTableAsync}} invocation and
> committing a temporal value of {{calciteSchemaVv}} (which was assigned by the
> event handling) by revision update callback.
> Example: ItComputeTest.executesColocatedWithMappedKey is flaky with exception
> above.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16933) PageMemory-based MV storage implementation
[
https://issues.apache.org/jira/browse/IGNITE-16933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545049#comment-17545049
]
Roman Puchkovskiy commented on IGNITE-16933:
Thank you for your review!
> PageMemory-based MV storage implementation
> --
>
> Key: IGNITE-16933
> URL: https://issues.apache.org/jira/browse/IGNITE-16933
> Project: Ignite
> Issue Type: New Feature
>Reporter: Ivan Bessonov
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> Similar to IGNITE-16611, we need an MV-storage implementation for page memory
> storage engine. Currently, I expect only row storage implementation, without
> primary or secondary indexes.
> h2. Chain Structure
> Here I'm going to describe a data format. Each row is stored as a versioned
> chain. It will be represented by a number of data entries that will have
> references to each other.
> {code:java}
> [ Timestamp | NextLink | PayloadSize | Payload ]{code}
> * Timestamp is a 16 bytes value derived from
> {{org.apache.ignite.internal.tx.Timestamp}} instance. It represents a commit
> time of corresponding row.
> * NextLink is a link to the next element in the chain or a NULL_LINK (or any
> other convenient name). It's a long value in standard format for Page Memory
> links (itemId, flag, partitionId, pageIdx). Technically, partition id is not
> needed here, because it's always the same. Removing it could allow us to save
> 2 bytes per chain element.
> * PayloadSize is a 4-bytes integer value that gives us the size of actual
> data in arbitrary format.
> * Payload - I expect it to be a serialized BinaryRow data. This is how it's
> implemented in RocksDB right now.
> For uncommitted (pending) entries I propose using maximal possible timestamp
> - {{{}(Long.MAX_VALUE, Long.MAX_VALUE){}}}. This will simplify things. Note
> that we never store tx id in chain itself.
> Overall, every chain element will have a (16 + 6 + 4 = 26) bytes header. It
> should be used as a header size in corresponding FreeList.
> h2. RowId pointer
> There's a requirement to have an immutable RowId for every versioned chain.
> One could argue that we should just make chain head immutable, but it would
> result in lots of complications. It's better to have a separate structure
> with immutable link, that will point to an actual head of the versioned chain.
> {code:java}
> [ TransactionId | HeadLink | NextLink ]{code}
> * TransactionId is a UUID. Can only be applied to pending entries. For
> committed head I propose storing 16 zeroes.
> * HeadLink is a link to the chain's head. Either 8 or 6 bytes. As already
> mentioned, I'd prefer 6.
> * NextLink is a "NextLink" value from the head chain element. It's a cheap
> shortcut for read-only transactions, you can skip uncommitted entry without
> even trying to read it, if there's a non-null transaction id. Debatable, I
> know, but looks cheap enough.
> In total, RowId is a 8 bytes link, pointing to a structure that has (16 + 6 +
> 6 = 28) bytes of data. There must e a separate FreeList for every partition
> even in In-Memory mode for reasons that I'll give later. "Header" size in
> that list must be equal to these 28 bytes. I wonder how effective FreeList
> will be for this case, where every chunk has the same size. We'll see. Maybe
> we should adjust a number of buckets somehow.
> h2. Data access and Full Scan
> Now, the fun part. There's no mention of B+Tree here. That's because we can
> probably just avoid it. If it existed, it would just point RowId to a
> described RowId structure in partition, but RowId is already a pointer
> itself. The only other problem that is usually solved by a tree-like
> structure is a full-scan of all rows in partition. This is useful when you
> need to rebuild indexes, for example.
> We should keep in mind that there's no code yet for rebuilding indexes. On
> the other hand, there's a method for partition scan in the API. This code
> could be used instead of Primary Index until we have it implemented.
> There's not FreeList full-scan currently in the code, it needs to be
> implemented. And, this particular full-scan is the reason why every partition
> should have its own list of row ids.
> There's also a chance that introducing new flag for row ids might be
> convenient. I don't know yet, let's not do it for now.
> Finally, we need an adequate protection from assertions if we, for some
> reason, have invalid row id. Things that can be checked be a normal code, not
> assertion:
> * data page type
> * number of items in the page
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (IGNITE-17068) Sql: Fix AsyncResultSet.fetchNextPage semantics
[
https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-17068.
---
Resolution: Fixed
Merged to
[main|https://github.com/apache/ignite-3/commit/da2738b575c027864b85fa89198931faa17f]
> Sql: Fix AsyncResultSet.fetchNextPage semantics
> ---
>
> Key: IGNITE-17068
> URL: https://issues.apache.org/jira/browse/IGNITE-17068
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> AsyncResultSet.fetchNextPage has different semantics on client (returns same
> instance) and server (return new instance).
> Since the behavior on the client seems to be more correct, let's bring the
> server implementation in line: call to {{fetchNextPage}} should return the
> same instance of {{AsyncResultSet}} but with updated state.
> Also let's add to the javadoc the proper way to drain the cursor to a
> collection:
> {code:java}
> CompletionStage fetchAllRowsInto(AsyncResultSet resultSet, List
> target) {
> for (var row : resultSet.currentPage()) {
> target.add(row);
> }
> if (!resultSet.hasMorePages()) {
> return CompletableFuture.completedFuture(null);
> }
> return resultSet.fetchNextPage().thenCompose(res -> fetchAllRowsInto(res,
> target));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17070) [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test.
[ https://issues.apache.org/jira/browse/IGNITE-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17070: -- Component/s: extensions > [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test. > - > > Key: IGNITE-17070 > URL: https://issues.apache.org/jira/browse/IGNITE-17070 > Project: Ignite > Issue Type: Test > Components: extensions >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > IgniteCacheTopologyValidatorTest#testSplitWithBaseline is flaky we need to > fix it. > https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests=-4574202048063239300=testDetails > The main problem here is that rebalance of test keys could take more then 30 > seconds to complete. 30 seconds is a timeout that is used by > awaitPartitionMapExchange method in which assertion is arised. > The proposed solution - to decrease the number of test keys. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17070) [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test.
[ https://issues.apache.org/jira/browse/IGNITE-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17070: -- Ignite Flags: (was: Docs Required,Release Notes Required) > [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test. > - > > Key: IGNITE-17070 > URL: https://issues.apache.org/jira/browse/IGNITE-17070 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > IgniteCacheTopologyValidatorTest#testSplitWithBaseline is flaky we need to > fix it. > https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests=-4574202048063239300=testDetails > The main problem here is that rebalance of test keys could take more then 30 > seconds to complete. 30 seconds is a timeout that is used by > awaitPartitionMapExchange method in which assertion is arised. > The proposed solution - to decrease the number of test keys. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16800) Support leader changing during rebalance
[ https://issues.apache.org/jira/browse/IGNITE-16800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16800: - Reviewer: Alexander Lapin > Support leader changing during rebalance > > > Key: IGNITE-16800 > URL: https://issues.apache.org/jira/browse/IGNITE-16800 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > We need to start new rebalance, if leader changes during the current (when it > was in the catching up phase) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16800) Support leader changing during rebalance
[ https://issues.apache.org/jira/browse/IGNITE-16800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545000#comment-17545000 ] Alexander Lapin commented on IGNITE-16800: -- [~kgusakov] LGTM > Support leader changing during rebalance > > > Key: IGNITE-16800 > URL: https://issues.apache.org/jira/browse/IGNITE-16800 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > We need to start new rebalance, if leader changes during the current (when it > was in the catching up phase) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17070) [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test.
[ https://issues.apache.org/jira/browse/IGNITE-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-17070: --- Assignee: Mikhail Petrov > [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test. > - > > Key: IGNITE-17070 > URL: https://issues.apache.org/jira/browse/IGNITE-17070 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > IgniteCacheTopologyValidatorTest#testSplitWithBaseline is flaky we need to > fix it. > https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests=-4574202048063239300=testDetails > The main problem here is that rebalance of test keys could take more then 30 > seconds to complete. 30 seconds is a timeout that is used by > awaitPartitionMapExchange method in which assertion is arised. > The proposed solution - to decrease the number of test keys. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17070) [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test.
Mikhail Petrov created IGNITE-17070: --- Summary: [TEST] Fix flaky IgniteCacheTopologyValidatorTest#testSplitWithBaseline test. Key: IGNITE-17070 URL: https://issues.apache.org/jira/browse/IGNITE-17070 Project: Ignite Issue Type: Test Reporter: Mikhail Petrov IgniteCacheTopologyValidatorTest#testSplitWithBaseline is flaky we need to fix it. https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests=-4574202048063239300=testDetails The main problem here is that rebalance of test keys could take more then 30 seconds to complete. 30 seconds is a timeout that is used by awaitPartitionMapExchange method in which assertion is arised. The proposed solution - to decrease the number of test keys. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17069) Calcite engine. Support segmented indexes
Aleksey Plekhanov created IGNITE-17069: -- Summary: Calcite engine. Support segmented indexes Key: IGNITE-17069 URL: https://issues.apache.org/jira/browse/IGNITE-17069 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currentrly we silently return the wrong result if index is segmented (query parallelism is set for table). While query parallelism is not supported (see IGNITE-13027) by the Calcite query engine, we should at least process all segments of the index during index scan. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544931#comment-17544931
]
Ilya Shishkov edited comment on IGNITE-14913 at 6/1/22 2:20 PM:
[~NSAmelchev], [~PetrovMikhail], thanks a lot for the review!
was (Author: shishkovilja):
[~NSAmelchev], [~PetrovMikhail], thanks a lot for the review.
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a command to manage cache metrics
> collection.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status --caches
> cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which operation should be applied.
> --all-caches - applies operation to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544931#comment-17544931
]
Ilya Shishkov commented on IGNITE-14913:
[~NSAmelchev], [~PetrovMikhail], thanks a lot for the review.
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a command to manage cache metrics
> collection.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status --caches
> cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which operation should be applied.
> --all-caches - applies operation to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544889#comment-17544889
]
Ignite TC Bot commented on IGNITE-14913:
{panel:title=Branch: [pull/9694/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9694/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6596429]]
* {color:#013220}IgniteControlUtilityTestSuite:
CacheMetricsCommandTest.testNotFoundCache - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
CacheMetricsCommandTest.testEnableDisable - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
CacheMetricsCommandTest.testStatus - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
CacheMetricsCommandTest.testInvalidArguments - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6596497buildTypeId=IgniteTests24Java8_RunAll]
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a command to manage cache metrics
> collection.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status --caches
> cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which operation should be applied.
> --all-caches - applies operation to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled
[
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544853#comment-17544853
]
Sergey Chugunov commented on IGNITE-13109:
--
[~nizhikov] , thank you for clarification, rejecting of merging this to master
looks reasonable to me. No need to have it in master.
> Skip distributed metastorage entries that can not be unmarshalled
> -
>
> Key: IGNITE-13109
> URL: https://issues.apache.org/jira/browse/IGNITE-13109
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled
> (These entries can be created by the product that built on Apache Ignite and
> incorporate additional features). It leads that nodes can't join to the first
> started node:
> {noformat}
> [SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
> at org.apache.ignite.Ignition.start(Ignition.java:328)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
> marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
> ... 8 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to
> unmarshal key=ignite.testOldKey
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-17012) Check if random tests failures because of TimeoutException is still reproducible
[
https://issues.apache.org/jira/browse/IGNITE-17012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-17012:
Assignee: Vyacheslav Koptilin
> Check if random tests failures because of TimeoutException is still
> reproducible
> -
>
> Key: IGNITE-17012
> URL: https://issues.apache.org/jira/browse/IGNITE-17012
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> We have the umbrella ticket IGNITE-15655 where the problem of a random tests
> failures because of {{TimeoutException}} was introduced. A lot of problems
> was found when we investigated the issue, and most of them was fixed, so we
> propose to check if the problem is still reproducible.
> The actions that are proposed to do:
> 1 ) Unmute all tests that were disabled with IGNITE-15655 ticket
> 2) Check if they are reproducible with the same problem
> 3) Create new tickets for all found problems
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-17051) Incorrect parsing of 'IN' clause in IgniteQueryGenerator
[
https://issues.apache.org/jira/browse/IGNITE-17051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita reassigned IGNITE-17051:
Assignee: Mikhail Petrov
> Incorrect parsing of 'IN' clause in IgniteQueryGenerator
>
>
> Key: IGNITE-17051
> URL: https://issues.apache.org/jira/browse/IGNITE-17051
> Project: Ignite
> Issue Type: Bug
> Components: springdata
>Reporter: Ilya Shishkov
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: ise
> Attachments: IncorrectInOperator.patch
>
>
> If you create JPA-repository method with with 'IN' operator (eg.
> findBySecondName{*}In{*}), it should be parsed in correct SQL form, but when
> such repository method is called, below error occurs:
> {code:java}
> Syntax error in SQL statement "SELECT ""PersonCache"".""PERSON""._KEY,
> ""PersonCache"".""PERSON""._VAL FROM PERSON WHERE ((PERSON.SECONDNAME IN
> ?[*])) "; expected "("; SQL statement:
> SELECT "PersonCache"."PERSON"._KEY, "PersonCache"."PERSON"._VAL FROM Person
> WHERE ((Person.secondName IN ?)) [42001-197]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:861)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:420)
> at
> org.apache.ignite.springdata.proxy.IgniteNodeCacheProxy.query(IgniteNodeCacheProxy.java:90)
> at
> org.apache.ignite.springdata.repository.query.IgniteRepositoryQuery.execute(IgniteRepositoryQuery.java:348)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:619)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:606)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
> at com.sun.proxy.$Proxy51.findBySecondNameIn(Unknown Source)
> at
> org.apache.ignite.springdata.IgniteSpringDataCrudSelfTest.testGetPersonsBySecondNameInList(IgniteSpringDataCrudSelfTest.java:453)
> 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
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Here is a reproducer patch (apply to master of ignite-extensions):
> [^IncorrectInOperator.patch]. It contains two tests for single argument and
> for list of arguments.
> It seems, that {{IgniteQueryGenerator}} incorrectly handles {{IN}} (and
> {{{}NOT IN{}}}) operator [1], because if you place '?' between parenthesis,
> error will disappear for single argument.
> But there is another problem after addition of parenthesis: if Collection is
> passed as argument below error will occur:
> {code:java}
> General error: "class org.apache.ignite.IgniteCheckedException: Runtime
> failure on bounds: [lower=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9],
> upper=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9]]";
> SQL statement:
> SELECT
> "PersonCache".__Z0._KEY __C0_0,
> "PersonCache".__Z0._VAL __C0_1
> FROM "PersonCache".PERSON __Z0
> WHERE __Z0.SECONDNAME = ?1 [5-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:900)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:987)
> at
>
[jira] [Commented] (IGNITE-17049) Move ignite-spark modules to the Ignite Extensions project
[ https://issues.apache.org/jira/browse/IGNITE-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544804#comment-17544804 ] Maxim Muzafarov commented on IGNITE-17049: -- Merged to the master branch for both Apache Ignite and Apache Ignite Extensions. > Move ignite-spark modules to the Ignite Extensions project > -- > > Key: IGNITE-17049 > URL: https://issues.apache.org/jira/browse/IGNITE-17049 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite-spark, ignite-spark2.4 modules must be moved to the Ignite > Extension project. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17049) Move ignite-spark modules to the Ignite Extensions project
[
https://issues.apache.org/jira/browse/IGNITE-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544802#comment-17544802
]
Ignite TC Bot commented on IGNITE-17049:
{panel:title=Branch: [pull/10057/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}RDD{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6601403]]
{panel}
{panel:title=Branch: [pull/10057/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=6600614buildTypeId=IgniteTests24Java8_RunAll]
> Move ignite-spark modules to the Ignite Extensions project
> --
>
> Key: IGNITE-17049
> URL: https://issues.apache.org/jira/browse/IGNITE-17049
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ignite-spark, ignite-spark2.4 modules must be moved to the Ignite
> Extension project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16582) Improve behavior of speed-based throttling when dirty pages ratio is low
[
https://issues.apache.org/jira/browse/IGNITE-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-16582:
---
Reviewer: Semyon Danilov
> Improve behavior of speed-based throttling when dirty pages ratio is low
>
>
> Key: IGNITE-16582
> URL: https://issues.apache.org/jira/browse/IGNITE-16582
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Affects Versions: 2.12
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> There is a log:
> {{Throttling is applied to page modifications [}}
> percentOfPartTime=0.59,
> markDirty=7424 pages/sec,
> checkpointWrite=6268 pages/sec,
> estIdealMarkDirty=0 pages/sec,
> curDirty=0.00,
> maxDirty=0.24,
> avgParkTime=79770 ns,
> {{pages: (total=67085, evicted=0, written=40916, synced=0, cpBufUsed=3,
> cpBufTotal=518215)]}}
> Here, it can be seen that, although there are plenty of non-dirty pages,
> throttling is applied. This happens because our speed-based throttling has 2
> algorithms for protecting non-dirty pages from exhaustion:
> # A more complex one that computes max allowable dirty ratio and ideal
> marking speed and throttles when both dirty ratio and current marking speed
> surpass these values
> # A simpler one that throttles if the current marking speed is higher than
> the average checkpointing speed
> In the shown example the first algorithm does not throttle, but the second
> one does.
> It looks like the throttling is enabled too early.
> One way to solve this problem is to just disable the second algorithm as the
> first seems to be more adequate (but this needs careful consideration of all
> possible cases).
> Another way is to consider averaged marking speed instead of (or in addition
> to) the current marking speed when deciding whether to throttle or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16641) [Native Persistence 3.0] Support persistent B+Tree-based storage
[ https://issues.apache.org/jira/browse/IGNITE-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16641: - Description: Need to support the persistent B+Tree-based storage case: * Add checkpoint configuration to *PageMemoryStorageEngineConfigurationSchema*; * Add *AbstractPageMemoryDataRegion* implementation for persistent case; * Add *PageMemoryTableStorage* implementation for persistent case; * Fix all *TODO: IGNITE-16641*. was:Need to support the persistent B+Tree-based storage case. > [Native Persistence 3.0] Support persistent B+Tree-based storage > > > Key: IGNITE-16641 > URL: https://issues.apache.org/jira/browse/IGNITE-16641 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Need to support the persistent B+Tree-based storage case: > * Add checkpoint configuration to > *PageMemoryStorageEngineConfigurationSchema*; > * Add *AbstractPageMemoryDataRegion* implementation for persistent case; > * Add *PageMemoryTableStorage* implementation for persistent case; > * Fix all *TODO: IGNITE-16641*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17068) Sql: Fix AsyncResultSet.fetchNextPage semantics
[
https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17068:
--
Description:
AsyncResultSet.fetchNextPage has different semantics on client (returns same
instance) and server (return new instance).
Since the behavior on the client seems to be more correct, let's bring the
server implementation in line: call to {{fetchNextPage}} should return the same
instance of {{AsyncResultSet}} but with updated state.
Also let's add to the javadoc the proper way to drain the cursor to a
collection:
{code:java}
CompletionStage fetchAllRowsInto(AsyncResultSet resultSet, List
target) {
for (var row : resultSet.currentPage()) {
target.add(row);
}
if (!resultSet.hasMorePages()) {
return CompletableFuture.completedFuture(null);
}
return resultSet.fetchNextPage().thenCompose(res -> fetchAllRowsInto(res,
target));
} {code}
was:AsyncResultSet.fetchNextPage has different semantics on client (returns
same instance) and server (return new instance)
> Sql: Fix AsyncResultSet.fetchNextPage semantics
> ---
>
> Key: IGNITE-17068
> URL: https://issues.apache.org/jira/browse/IGNITE-17068
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
>Priority: Major
> Labels: ignite-3
>
> AsyncResultSet.fetchNextPage has different semantics on client (returns same
> instance) and server (return new instance).
> Since the behavior on the client seems to be more correct, let's bring the
> server implementation in line: call to {{fetchNextPage}} should return the
> same instance of {{AsyncResultSet}} but with updated state.
> Also let's add to the javadoc the proper way to drain the cursor to a
> collection:
> {code:java}
> CompletionStage fetchAllRowsInto(AsyncResultSet resultSet, List
> target) {
> for (var row : resultSet.currentPage()) {
> target.add(row);
> }
> if (!resultSet.hasMorePages()) {
> return CompletableFuture.completedFuture(null);
> }
> return resultSet.fetchNextPage().thenCompose(res -> fetchAllRowsInto(res,
> target));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-17068) Sql: Fix AsyncResultSet.fetchNextPage semantics
[ https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov reassigned IGNITE-17068: - Assignee: Taras Ledkov > Sql: Fix AsyncResultSet.fetchNextPage semantics > --- > > Key: IGNITE-17068 > URL: https://issues.apache.org/jira/browse/IGNITE-17068 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > > AsyncResultSet.fetchNextPage has different semantics on client (returns same > instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-16410) Implement Ignite#setBaseline method in thin client
[
https://issues.apache.org/jira/browse/IGNITE-16410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-16410.
--
Fix Version/s: (was: 3.0.0-alpha5)
Resolution: Won't Fix
is not actual anymore (see https://issues.apache.org/jira/browse/IGNITE-14209)
> Implement Ignite#setBaseline method in thin client
> --
>
> Key: IGNITE-16410
> URL: https://issues.apache.org/jira/browse/IGNITE-16410
> Project: Ignite
> Issue Type: Task
> Components: thin client
>Affects Versions: 3.0.0-alpha4
>Reporter: Valentin Kulichenko
>Priority: Major
> Labels: ignite-3
>
> Currently, this method is available only on server side - thin client throws
> {{{}UnsupportedOperationException{}}}. Because of that, {{RebalanceExample}}
> still starts an embedded server node.
> Need to implement the method in the thin client and update the example.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (IGNITE-16980) PageMemoryPartitionStorage#write() can leak page slots
[
https://issues.apache.org/jira/browse/IGNITE-16980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy resolved IGNITE-16980.
Resolution: Won't Fix
Closing as this code will be removed soon
> PageMemoryPartitionStorage#write() can leak page slots
> --
>
> Key: IGNITE-16980
> URL: https://issues.apache.org/jira/browse/IGNITE-16980
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> {{public void write(DataRow row) throws StorageException {}}
> {{ try {}}
> {{ TableDataRow dataRow = wrap(row);}}
> {{ freeList.insertDataRow(dataRow);}}
> {{ tree.put(dataRow);}}
> {{ } catch (IgniteInternalCheckedException e) {}}
> {{ throw new StorageException("Error writing row", e);}}
> {{ }}}
> {{}}}
> This code always occupies a slot in a data page, even if the key was already
> put to the partition. So, if 2 puts with same key occur, one page slot is
> wasted.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17068) Sql: Fix AsyncResultSet.fetchNextPage semantics
[ https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17068: -- Component/s: sql (was: thin client) > Sql: Fix AsyncResultSet.fetchNextPage semantics > --- > > Key: IGNITE-17068 > URL: https://issues.apache.org/jira/browse/IGNITE-17068 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > AsyncResultSet.fetchNextPage has different semantics on client (returns same > instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17068) Sql: Fix AsyncResultSet.fetchNextPage semantics
[ https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17068: -- Summary: Sql: Fix AsyncResultSet.fetchNextPage semantics (was: Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics) > Sql: Fix AsyncResultSet.fetchNextPage semantics > --- > > Key: IGNITE-17068 > URL: https://issues.apache.org/jira/browse/IGNITE-17068 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > AsyncResultSet.fetchNextPage has different semantics on client (returns same > instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17068) Sql: Fix AsyncResultSet.fetchNextPage semantics
[ https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-17068: - Assignee: (was: Pavel Tupitsyn) > Sql: Fix AsyncResultSet.fetchNextPage semantics > --- > > Key: IGNITE-17068 > URL: https://issues.apache.org/jira/browse/IGNITE-17068 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > AsyncResultSet.fetchNextPage has different semantics on client (returns same > instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16641) [Native Persistence 3.0] Support persistent B+Tree-based storage
[ https://issues.apache.org/jira/browse/IGNITE-16641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-16641: Assignee: Kirill Tkalenko > [Native Persistence 3.0] Support persistent B+Tree-based storage > > > Key: IGNITE-16641 > URL: https://issues.apache.org/jira/browse/IGNITE-16641 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Need to support the persistent B+Tree-based storage case. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17068) Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics
[ https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17068: Component/s: thin client > Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics > > > Key: IGNITE-17068 > URL: https://issues.apache.org/jira/browse/IGNITE-17068 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > AsyncResultSet.fetchNextPage has different semantics on client (returns same > instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17068) Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics
Pavel Tupitsyn created IGNITE-17068: --- Summary: Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics Key: IGNITE-17068 URL: https://issues.apache.org/jira/browse/IGNITE-17068 Project: Ignite Issue Type: Bug Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn AsyncResultSet.fetchNextPage has different semantics on client (returns same instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17068) Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics
[ https://issues.apache.org/jira/browse/IGNITE-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17068: Ignite Flags: (was: Docs Required,Release Notes Required) > Thin 3.0: Fix AsyncResultSet.fetchNextPage semantics > > > Key: IGNITE-17068 > URL: https://issues.apache.org/jira/browse/IGNITE-17068 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > AsyncResultSet.fetchNextPage has different semantics on client (returns same > instance) and server (return new instance) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16918) Sql. Races during table creation
[
https://issues.apache.org/jira/browse/IGNITE-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-16918:
--
Assignee: Vladislav Pyatkov (was: Denis Chudov)
> Sql. Races during table creation
>
>
> Key: IGNITE-16918
> URL: https://issues.apache.org/jira/browse/IGNITE-16918
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
>
> Random tests fails on TC with the very same error (table name is varying
> though):
> {code:java}
> [14:04:04][executesColocatedWithMappedKey]
> java.util.concurrent.CompletionException
> [14:04:04][executesColocatedWithMappedKey]
> java.util.concurrent.CompletionException:
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 13 to
> line 1, column 16: Object 'TEST' not found
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 13 to line 1, column 16: Object 'TEST' not found
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Object
> 'TEST' not found
> {code}
>
> Looks like the root cause of this problem is race in between of completion of
> the future returned by {{TableManager#createTableAsync}} invocation and
> committing a temporal value of {{calciteSchemaVv}} (which was assigned by the
> event handling) by revision update callback.
> Example: ItComputeTest.executesColocatedWithMappedKey is flaky with exception
> above.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17020) Update documenation for DDL with examples of using quoted fields
[ https://issues.apache.org/jira/browse/IGNITE-17020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17020: - Fix Version/s: 2.13 > Update documenation for DDL with examples of using quoted fields > > > Key: IGNITE-17020 > URL: https://issues.apache.org/jira/browse/IGNITE-17020 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13, 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Clarify of using quoted files for the CREATE TABLE clause with more examples. > https://ignite.apache.org/docs/2.11.1/sql-reference/ddl#create-table -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17020) Update documenation for DDL with examples of using quoted fields
[ https://issues.apache.org/jira/browse/IGNITE-17020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17020: - Ignite Flags: (was: Docs Required,Release Notes Required) > Update documenation for DDL with examples of using quoted fields > > > Key: IGNITE-17020 > URL: https://issues.apache.org/jira/browse/IGNITE-17020 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13, 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Clarify of using quoted files for the CREATE TABLE clause with more examples. > https://ignite.apache.org/docs/2.11.1/sql-reference/ddl#create-table -- This message was sent by Atlassian Jira (v8.20.7#820007)
