[jira] [Comment Edited] (IGNITE-19241) Java thin 3.0: propagate table schema updates to client on write-only operations
[ https://issues.apache.org/jira/browse/IGNITE-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716081#comment-17716081 ] Pavel Tupitsyn edited comment on IGNITE-19241 at 4/25/23 5:17 AM: -- [~isapego] can you please help me with the C++ client? I'm not sure how to fix *table_impl::read_tuples* correctly, do we need *read_array_raw* there? I've only changed *packInt* to *packArrayHeader* on the server side. https://github.com/apache/ignite-3/pull/1975 was (Author: ptupitsyn): [~isapego] can you please help me with the C++ client? I'm not sure how to fix *table_impl::read_tuples* correctly, do we need *read_array_raw* there? I've only changed *packInt* to *packArrayHeader* on the server side. > Java thin 3.0: propagate table schema updates to client on write-only > operations > > > Key: IGNITE-19241 > URL: https://issues.apache.org/jira/browse/IGNITE-19241 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, Java client receives table schema updates when write-read requests > are performed. For example, client performs TUPLE_GET request, sends key > tuple using old schema version, receives result tuple with the latest schema > version, and retrieves the latest schema. > However, some requests are "write-only": client sends a tuple, but does not > receive one back, like TUPLE_UPSERT. No schema updates are performed in this > case. > To fix this, include the latest schema version into all write-only operation > responses: > * TUPLE_UPSERT > * TUPLE_UPSERT_ALL > * TUPLE_INSERT > * TUPLE_INSERT_ALL > * TUPLE_REPLACE > * TUPLE_REPLACE_EXACT > * TUPLE_DELETE > * TUPLE_DELETE_ALL > * TUPLE_DELETE_EXACT > * TUPLE_DELETE_ALL_EXACT > * TUPLE_CONTAINS_KEY > Client will compare this version to the known one and perform a background > update, if necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19241) Java thin 3.0: propagate table schema updates to client on write-only operations
[ https://issues.apache.org/jira/browse/IGNITE-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716081#comment-17716081 ] Pavel Tupitsyn commented on IGNITE-19241: - [~isapego] can you please help me with the C++ client? I'm not sure how to fix *table_impl::read_tuples* correctly, do we need *read_array_raw* there? I've only changed *packInt* to *packArrayHeader* on the server side. > Java thin 3.0: propagate table schema updates to client on write-only > operations > > > Key: IGNITE-19241 > URL: https://issues.apache.org/jira/browse/IGNITE-19241 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, Java client receives table schema updates when write-read requests > are performed. For example, client performs TUPLE_GET request, sends key > tuple using old schema version, receives result tuple with the latest schema > version, and retrieves the latest schema. > However, some requests are "write-only": client sends a tuple, but does not > receive one back, like TUPLE_UPSERT. No schema updates are performed in this > case. > To fix this, include the latest schema version into all write-only operation > responses: > * TUPLE_UPSERT > * TUPLE_UPSERT_ALL > * TUPLE_INSERT > * TUPLE_INSERT_ALL > * TUPLE_REPLACE > * TUPLE_REPLACE_EXACT > * TUPLE_DELETE > * TUPLE_DELETE_ALL > * TUPLE_DELETE_EXACT > * TUPLE_DELETE_ALL_EXACT > * TUPLE_CONTAINS_KEY > Client will compare this version to the known one and perform a background > update, if necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15322:
---
Release Note: Granting permissions to system compute tasks by their FQN has
been replaced with predefined system permissions
> System tasks should run without any explicitly granted permissions
> --
>
> Key: IGNITE-15322
> URL: https://issues.apache.org/jira/browse/IGNITE-15322
> Project: Ignite
> Issue Type: Bug
> Components: compute, security
>Reporter: Ilya Kazakov
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> For example, this code needs TASK_EXECUTE permissions.
> {code:java}
> Affinity affinity = ignite.affinity("TEST");
> affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
> This is unexpected behavior, because:
> - the task started implicitly (under the hood), customer should not to know
> about it.
> - this is a system task (not defined by a customer), the tasks needs for a
> normal grid workflow.
> Also, I suppose there are any other implicitly tasks, which could lead to
> unexpected behavior (need permissions).
> Proposed way to solve this issue:
> 1. Add mechanism to destinguish whether task class is SYSTEM (part of the
> Ignite codebase) or USER.
> Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
> Sanbox implementation.
> 2. Add mechanism to detect if task execution was initiated by the user
> (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
> It seems that the easiest way to achieve this is to completely separate the
> public and private Compute APIs.
> Task executioin requests received through Ignite Thin Clients are considered
> PUBLIC CALLs.
> The first two steps give us the ability to
> A. safely skip authorization of SYSTEM tasks which are
> called through INTERNAL API.
> B. keep authorization of PUBLIC tasks intact
> C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it
> means that all user task execution requests received through REST or Thin
> client protocols MUST be executed through PUBLIC API).
> 3. Add the ability to explicitly specify for SYSTEM
> task/callable/runnable/closure what permission should be checked before its
> execution.
> It can be solved by introducing optional interface that compute job can
> implement.
> {code:java}
> /** */
> public interface PublicAccessJob {
> /** */
> public SecurityPermissionSet requiredPermissions();
> }
> {code}
> 4. SYSTEM tasks can splitted into two categories -
> SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
> tasks (tasks that are part oof the ignite code but are available to the user
> and can be executed through the PUBLIC API)
> Example of SYSTEM public tasks - Visor tasks on which the user control script
> is implemented
> They are executed through Thin Client which is considered Public API.
> Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
> we must force the developer to explicitly specify permissions for tasks of
> this type. It can be done by checking that SYSTEM tasks that are executed
> through PUBLIC API impelements PublicAwareJob interface described above.
> ||X||Public API||Private API||
> |PUBLIC task|auth by task name|restricted|
> |SYSTEM INTERNAL task|restricted|auth skipped|
> |SYSTEM PUBLIC task|auth by explicitly specified permissions|auth skipped|
> By the way the PublicAccessJob interface, implemented by all Visor jobs,
> allows you to specify for each specific Visor job what permissions it
> requires. Also it is proposed to guard all Visor Jobs with ADMIN_OPS
> permission by default.
> 5. Authorization of SYSTEM tasks cancellation must be skipped it they are
> canceled by the same user who started them, oterwise dedicated permissions is
> required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their
> names.
> Possible troubles:
> 1. Mentioned SecurityUtils#isSystemType works only for the ignite-core
> module. If some tasks are defined inside other Ignite modules - they will not
> be considered SYSTEM. Currently there are no such task.
> 2. Currently all DotNet code is wrapped and executed via special SYSTEM
> tasks. As a result all DotNet runnable/callable/tasks are authorized by the
> name of the SYSTEM wrapper task. So if TASK_EXECUTE permissions for the
> SYSTEM wrapper task is granted - user can execute whathever DotNet custom tas
> he wants. After the propsed changes SYTEM task authorization will no more.be
> performed. So DotNet custom code execution will become completeley
> unauthorised. We should fix it in a separate ticket.
[jira] [Updated] (IGNITE-19030) Platforms: Add authorization of DotNet Compute tasks
[ https://issues.apache.org/jira/browse/IGNITE-19030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19030: --- Release Note: Added authorization of .NET and C++ compute tasks > Platforms: Add authorization of DotNet Compute tasks > > > Key: IGNITE-19030 > URL: https://issues.apache.org/jira/browse/IGNITE-19030 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: .NET, cpp > Fix For: 2.15 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Prior to https://issues.apache.org/jira/browse/IGNITE-15322, all DotNet and > CPP tasks were authorized by the name of the internal Ignite system task that > executes them on the Java side. > After https://issues.apache.org/jira/browse/IGNITE-15322 has been resolved, > authorization of internal tasks is no longer performed. As a result, we do > not have the ability to control the authorization of DotNet/CPP tasks. We > need to implement it. > It is proposed to reuse the same approach that the Java implementation uses - > to authorize DotNet tasks by their FQN - to authorize CPP tasks by the name f > the corresponding binary type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19277) Add authorization of Ignite Cluster Node stop/restart operations.
[ https://issues.apache.org/jira/browse/IGNITE-19277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19277: --- Release Note: Added authorization of Ignite Cluster Node stop/start/restart operations. > Add authorization of Ignite Cluster Node stop/restart operations. > - > > Key: IGNITE-19277 > URL: https://issues.apache.org/jira/browse/IGNITE-19277 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Critical > Labels: security > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Before https://issues.apache.org/jira/browse/IGNITE-15322 > IgniteCluster#restartNodes()/stopNodes() operations were authorized by the > name of the internal tasks that is used during their execution - > org.apache.ignite.internal.cluster.IgniteKillTask. > After https://issues.apache.org/jira/browse/IGNITE-15322 has been resolved, > authorization of internal tasks is no longer performed. So > IgniteCluster#restartNodes()/stopNodes() operations are not authorized at > all. > We must to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17567) C++: Implement Java-based continuous query remote filter for a thick client
[ https://issues.apache.org/jira/browse/IGNITE-17567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17567: --- Release Note: Added ability to use java-based continuous query remote filters to C++ thick clients > C++: Implement Java-based continuous query remote filter for a thick client > --- > > Key: IGNITE-17567 > URL: https://issues.apache.org/jira/browse/IGNITE-17567 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > C++ thick clients have to be able to use java-based continuous query remote > filters when they interact with ignite java cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17594:
---
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Need to expose internal API to provide ability to listen query start/finish
> events. This allow to monitor query execution in monitoring tools.
> Need to pass following properties: query, queryType,
> schemaName, startTime, finishTime, local, {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
> {{failedReason}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17870) SQL. Do not yield separate query result for comments
[ https://issues.apache.org/jira/browse/IGNITE-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17870: --- Release Note: SQL: Fixed redundant query results for commented lines > SQL. Do not yield separate query result for comments > > > Key: IGNITE-17870 > URL: https://issues.apache.org/jira/browse/IGNITE-17870 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Motivation > Currently, lines with commented out lines yield additional query result. For > the query below, three results will be returned (result for comment is > “updated rows: 0“). You can play with the comments position within the entire > query, the behavior with comments is not consistent and clear. > -- asdf > SELECT * FROM Test_Person limit 1; > update Test_Person set name='sdfsdf' where id = ; > -- come > -- asdf > What to do > Do not yield a separate query result for commented out lines. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17736) Consistency repair should support multiply partitions specification
[
https://issues.apache.org/jira/browse/IGNITE-17736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17736:
---
Release Note: Control-utility: Added multiple partitions support to
consistency repair command
> Consistency repair should support multiply partitions specification
> ---
>
> Key: IGNITE-17736
> URL: https://issues.apache.org/jira/browse/IGNITE-17736
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.15
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Checks should be performed in parallel.
>
> Also, this issue is a good place for repformance tuning.
> We have some information from test environment:
> idle_verify for *641* partitions with *3* backups with *~ 600k* entries per
> partition tooks {*}11 minutes{*}, but fix with RELATIVE_MAJORITY strategy
> tooks {*}16 hours{*}.
> Parallel execution should decrease the duration significantly.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17962) Fix serializable lambda serialization on Java 17
[ https://issues.apache.org/jira/browse/IGNITE-17962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17962: --- Release Note: Fixed lambdas serialization on Java 17 > Fix serializable lambda serialization on Java 17 > > > Key: IGNITE-17962 > URL: https://issues.apache.org/jira/browse/IGNITE-17962 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.14 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Ignite fails to serialize/deserialize lambdas on Java 17: > java.lang.UnsupportedOperationException: can't get field offset on a hidden > class -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17995) Idle_verify must print broken partitions list
[
https://issues.apache.org/jira/browse/IGNITE-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17995:
---
Release Note: Control-utility: Added broken partitions list printing to
idle-verify command
> Idle_verify must print broken partitions list
> -
>
> Key: IGNITE-17995
> URL: https://issues.apache.org/jira/browse/IGNITE-17995
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, idle_verify provides per partition information, but not just a set
> of broken partitions.
> So, additional actions is necessary to get the list required by consistency
> repair tool.
> {noformat}
> idle_verify task was executed with the following args: caches=[],
> excluded=[], cacheFilter=[DEFAULT]
> idle_verify check has finished, found XXX conflict partitions:
> [counterConflicts=0, hashConflicts=XXX]
> Hash conflicts:
> Conflict partition: PartitionKeyV2 [grpId=CacheGroup1,
> grpName=CacheGroup1Cache, partId=600]
> ...
> Control utility [ver. XXX]
> 2021 Copyright(C) Apache Software Foundation
> User: xxx
> Time: XXX
>
>
>
> Command [CACHE] finished with code: 0
> Control utility has completed execution at: XXX
> Execution time: XXX ms
> {noformat}
> Let's, in addition to detailed view, provide such lists.
> Something like:
> {noformat}
> Total:
> CacheGroup1 (18/1024)
> 1,7,42,987,99
> CacheGroup2 (15/1024)
> 5,14,17,850,900
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[ https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17741: --- Release Note: Control-utility: Improved entries versions checking by idle_verify command (was: Control-utility: Added entries versions checking to idle_verify command) > idle_verify must provide explicit data and version hashes > - > > Key: IGNITE-17741 > URL: https://issues.apache.org/jira/browse/IGNITE-17741 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-31, ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently we have a single hash. > Separated hashes will provide more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[ https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17741: --- Release Note: Control-utility: Added entries versions checking to idle_verify command > idle_verify must provide explicit data and version hashes > - > > Key: IGNITE-17741 > URL: https://issues.apache.org/jira/browse/IGNITE-17741 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-31, ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently we have a single hash. > Separated hashes will provide more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17793) Historical rebalance must use HWM instead of LWM to seek the proper checkpoint to avoid the data loss
[
https://issues.apache.org/jira/browse/IGNITE-17793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17793:
---
Release Note: Fixed potential data loss on historical rebalance
> Historical rebalance must use HWM instead of LWM to seek the proper
> checkpoint to avoid the data loss
> -
>
> Key: IGNITE-17793
> URL: https://issues.apache.org/jira/browse/IGNITE-17793
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.15
>
> Attachments: HistoricalRebalanceCheckpointTest.java
>
>
> Currently, historical rebalance at
> {{CheckpointHistory#searchEarliestWalPointer}} seeks for the newest
> checkpoint with counter less that lowest entry has to be rebalanced.
> Unfortunately, we may have more that one checkpoint with the same counter and
> it's impossible to use the newest one as a rebalance start point.
> For example, we have partition with LWM=100, some gaps and HWM=200.
> Checkpoint will have the counter == 100.
> Then we may close some gaps, exluding 101 (to keep LWM == 100).
> And again, checkpoint will have counter == 100.
> Newest checkpoint (marked with counter 100) will not cointain all committed
> entries with counter > 100.
> Then lets close the rest of the gaps to make historical rebalance possible.
> And after the rebalance finish, we'll see a warning "Some partition entries
> were missed during historical rebalance" and inconsistent cluster state.
> See reproducer at [^HistoricalRebalanceCheckpointTest.java]
> Possible solution is to use HWM instead of LWM during the search.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18424) WAL segment rollover does not happen after walForceArchiveTimeout
[
https://issues.apache.org/jira/browse/IGNITE-18424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18424:
---
Release Note: Fixed WAL timeout rollover
> WAL segment rollover does not happen after walForceArchiveTimeout
> -
>
> Key: IGNITE-18424
> URL: https://issues.apache.org/jira/browse/IGNITE-18424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ilya Shishkov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> How to reproduce:
> # Start and activate persistent cluster with such properties:
> ## {{DataStorageConfiguration#walForceArchiveTimeout > 0}}, eg. 1 millis.
> ## {{DataRegion#cdcEnabled=true}}.
> ## {{DataStorageConfiguration#walSegmentSize=1Gb}}.
> ## {{DataStorageConfiguration#maxWalArchiveSize=20Gb}}.
> # Start data changing (put some entries continuously).
> # Rollover of WAL is not happening. You can wait some period exceeding
> {{walForceArchiveTimeout}} to ensure.
> # Stop loading the data.
> # Rollover happens.
> If you does not stop to load the data, rollover _will not happen until WAL
> segment will beсome full, i.e until to rollover by a segment size_.
> Under low loads, filling of 1Gb segment can occur after a dozen of minutes or
> even after several hours, which causes a large lag of a CDC replication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18209:
---
Fix Version/s: (was: 2.15)
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, when CDC through Kafka is used there are possible delays in
> replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries
> to update binary metadata and marshaller mappings.
> Delays caused by calls of {{KafkaConsumer#poll}} in
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
> metadata topic. If there are few binary types and mappings to update, first
> {{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
> topic.
> # {{KafkaToIgniteCdcStreamerApplier}} consequently call
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
> update marker. All further consequent calls will wait for
> {{kafkaReqTimeout}}.
> # Also there is a bottleneck, when multiple applier threads tries to update
> metadata and call synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
> {{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
> # Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of
> event topic from every node: firstly, in case of type mappings updates,
> secondly, in case of binary types update there are possible delays up to
> {{clusterSize x (topicPartitions x 2 - 1) x kafkaReqTimeout}}.
> # Data updates are blocked for Kafka partitions with unprocessed update
> markers.
> # For example for default timeout and 16 Kafka partitions _last partition
> will be consumed after 1.5 minutes_ in case of two one-node clusters.
> Links:
> #
> [https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17852) an error caused the server node to exit; "CRC hasn't been calculated"
[
https://issues.apache.org/jira/browse/IGNITE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17852:
---
Release Note: Fixed incorrect assertion on CRC calculation when disk page
compression is enabled
> an error caused the server node to exit; "CRC hasn't been calculated"
> -
>
> Key: IGNITE-17852
> URL: https://issues.apache.org/jira/browse/IGNITE-17852
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.12
>Reporter: Denis Kuznetsov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> an error caused the server node to exit:
> {code:java}
> 2022-10-04 20:00:48.828 [ERROR][db-checkpoint-thread-#220][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailure
> Handler [tryStop=false, timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failur
> eCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> ~[ignite-core-2.12.0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> ~[ignite-core-2.12.0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> ~[ignite-core-2.12.0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478)
> ~[ignite-core-2.12.0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointPagesWriter.run(CheckpointPagesWriter.java:166)
> ~[ignite-core-2.12.0-p6.jar:2.12.
> 0-p6]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]
> Suppressed: java.lang.AssertionError: CRC hasn't been calculated,
> crc=0
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:737)
> ~[ignite-core-2.12.0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageReadWriteManagerImpl.write(PageReadWriteManagerImpl.java:116)
> ~[ignite-core-2.12.0
> -p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.write(FilePageStoreManager.java:637)
> ~[ignite-core-2.12.0-p6.jar:2.1
> 2.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointManager.lambda$new$0(CheckpointManager.java:175)
> ~[ignite-core-2.12.0-p6.
> jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointPagesWriter$1.writePage(CheckpointPagesWriter.java:266)
> ~[ignite-core-2.1
> 2.0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1343)
> ~[ignite-core-2.12.0-p6
> .jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1250)
> ~[ignite-core-2.12.0-p6.j
> ar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointPagesWriter.writePages(CheckpointPagesWriter.java:207)
> ~[ignite-core-2.12
> .0-p6.jar:2.12.0-p6]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointPagesWriter.run(CheckpointPagesWriter.java:151)
> ~[ignite-core-2.12.0-p6.j
> ar:2.12.0-p6]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:829) [?:?] {code}
> node configured with compression:
> {code:java}
> {code}
> the node exited during the snapshot and caused the snapshot to stop:
> {code:java}
> 20221005_092448 ignite.log:2022-10-05 02:58:50.787
> [ERROR][disco-event-worker-#190][org.apache.ignite.internal.processors.cache.p
>
[jira] [Updated] (IGNITE-18249) ignite-cdc not stop on client node crash
[
https://issues.apache.org/jira/browse/IGNITE-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18249:
---
Release Note: Fixed ignite-cdc stopping on client node crush
> ignite-cdc not stop on client node crash
>
>
> Key: IGNITE-18249
> URL: https://issues.apache.org/jira/browse/IGNITE-18249
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: IEP-59, ise
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case
> # client node inside {{IgniteToIgniteCdcConsumer}} stops due to connection
> loss
> # AND no new CDC events
> ignite-cdc process not stopped and continue to work.
> This must be fixed - ignite-cdc must stop immediately on client node crash.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18403) ignite-cdc.sh fails to start with non-default work directory location
[ https://issues.apache.org/jira/browse/IGNITE-18403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18403: --- Release Note: Fixed ignite-cdc.sh start failure with non-defailt work directory > ignite-cdc.sh fails to start with non-default work directory location > - > > Key: IGNITE-18403 > URL: https://issues.apache.org/jira/browse/IGNITE-18403 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Korotkov >Assignee: Nikolay Izhikov >Priority: Minor > Labels: IEP-59, ise > Fix For: 2.15 > > Attachments: ignite-cdc.png > > Time Spent: 40m > Remaining Estimate: 0h > > ignite-cdc.sh fails to start if the non-default work directory is configured. > As shown on the screenshot attached, it correctly detects the work directory > location at the begining of work, but afterwards tries to access / create the > work directory in the default location. > If directory can not be created (say because of permissions lack or read-only > filesystem) ignite-cdc.sh just doesn't start. > !ignite-cdc.png|height=250! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17177) Implement incremental snapshots
[ https://issues.apache.org/jira/browse/IGNITE-17177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17177: --- Release Note: Added new feature: Incremental snapshots > Implement incremental snapshots > --- > > Key: IGNITE-17177 > URL: https://issues.apache.org/jira/browse/IGNITE-17177 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > Solution is incremental snapshots based on the Consistent Cut algorithm and > collecting WAL segments. > IEP-89: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-89%3A+Incremental+Snapshots -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18652) CdcMain is not committing state during index rebuilding
[ https://issues.apache.org/jira/browse/IGNITE-18652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18652: --- Release Note: Fixed CdcMain state committing during index rebuild > CdcMain is not committing state during index rebuilding > --- > > Key: IGNITE-18652 > URL: https://issues.apache.org/jira/browse/IGNITE-18652 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.14 >Reporter: Ilya Shishkov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59, ise > Fix For: 2.15 > > Attachments: CdcRebuildTest.patch > > Time Spent: 20m > Remaining Estimate: 0h > > For persistent cluster CdcMain is not committing state during index > rebuilding if there are no data updates. > It can cause to sharp increase of cdc WAL-archive size in case of big indexes. > Here is a reproducer patch: [^CdcRebuildTest.patch] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18404) ignite-cdc.sh doesn't call the CdcConsumer::stop()
[ https://issues.apache.org/jira/browse/IGNITE-18404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18404: --- Release Note: Fixed CdcConsumer stopping on ignite-cdc.sh stop > ignite-cdc.sh doesn't call the CdcConsumer::stop() > -- > > Key: IGNITE-18404 > URL: https://issues.apache.org/jira/browse/IGNITE-18404 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Korotkov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59, ise > Fix For: 2.15 > > Attachments: ignite-cdc-ducktest.zip > > Time Spent: 20m > Remaining Estimate: 0h > > Upon stop ignite-cdc.sh doesn't call the CdcConsumer::stop() method of the > consumer configured. > *** > Reproducer is in the ducktest: [https://github.com/apache/ignite/pull/10439] > ignite-cdc.log does contain log records from the CdcConsumer's start() and > on*() methods. But not from the stop() one. > PLease see the test results atached. > [^ignite-cdc-ducktest.zip] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18935) Late stopping of TTL workers during deactivation leads to corrupted PDS
[
https://issues.apache.org/jira/browse/IGNITE-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18935:
---
Release Note: Fixed PDS corruption on deactivation during entries expire
> Late stopping of TTL workers during deactivation leads to corrupted PDS
> ---
>
> Key: IGNITE-18935
> URL: https://issues.apache.org/jira/browse/IGNITE-18935
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Step to reproduce
> 1. Reduce wal history size and wal segment size to 16MB and 8MB respectively,
> set checkpoint frequency to 1
> 2. Perform heavy load with a lot of entries with TTL 5000 and with eager ttl
> enabled
> 3. Perform deactivation of cluster, stop grid and restart, provided that an
> expiration process is active during the process of restart.
> {code}
> [15:11:58,022][SEVERE][ttl-cleanup-worker-#52%None%][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [groupId=-459905951, pageIds=[], msg=Runtime failure on bounds:
> [lower=null, upper=PendingRow []
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=-459905951, pageIds=[], msg=Runtime failure on
> bounds: [lower=null, upper=PendingRow []]]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6434)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1294)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1249)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1237)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:3061)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:3010)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:246)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:199)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:198)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:750)
> Caused by:
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTreeRuntimeException:
>
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTreeRuntimeException:
> java.lang.IllegalStateException: Item not found: 24
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findLowerUnbounded(BPlusTree.java:1216)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1276)
> ... 12 more
> Caused by:
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTreeRuntimeException:
> java.lang.IllegalStateException: Item not found: 24
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.doInitFromLink(CacheDataRowAdapter.java:345)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:165)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:136)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:123)
> at
>
[jira] [Updated] (IGNITE-18993) ODBC: Regression. Missed handling of single quotes
[
https://issues.apache.org/jira/browse/IGNITE-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18993:
---
Release Note: ODBC: Fixed handling of single quotes
> ODBC: Regression. Missed handling of single quotes
> --
>
> Key: IGNITE-18993
> URL: https://issues.apache.org/jira/browse/IGNITE-18993
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8, 2.9, 2.10, 2.11, 2.12, 2.13, 2.14
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: c++, odbc
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When {{SQLTables}} is called with param 'table type' {{'TABLES'}} (with
> single comma), it returns an empty table list.
> It is a quite common way of calling this procedure (i.e. by INFORMATICA)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18976) Affinity broken on thick client after reconnection
[
https://issues.apache.org/jira/browse/IGNITE-18976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18976:
---
Release Note: Fixed broken affinity after thick client reconnection
> Affinity broken on thick client after reconnection
> --
>
> Key: IGNITE-18976
> URL: https://issues.apache.org/jira/browse/IGNITE-18976
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.14
>Reporter: Sergey Kosarev
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
> Attachments: IgniteClientReconnectAffinityTest.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 1 Using AffinyKey +BynaryTypeconfiguration
> 2 Client is reconnected
> 3 Affinity is Broken and Binary marshalling is broken:
> on Affinity.partition wrong value is returning:
> {noformat}
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertEquals(JUnitAssertAware.java:95)
> at
> org.apache.ignite.internal.IgniteClientReconnectAffinityTest.doReconnectClientAffinityKeyPartition(IgniteClientReconnectAffinityTest.java:213)
> at
> org.apache.ignite.internal.IgniteClientReconnectAffinityTest.testReconnectClientAnnotatedAffinityKeyWithBinaryConfigPartition(IgniteClientReconnectAffinityTest.java:123)
> 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:2504)
> at java.lang.Thread.run(Thread.java:748)
> {noformat} [^IgniteClientReconnectAffinityTest.java]
> Exception on cache.get :
> {noformat}
> class org.apache.ignite.binary.BinaryObjectException: Failed to serialize
> object
> [typeName=org.apache.ignite.internal.IgniteClientReconnectAffinityTest$TestAnnotatedKey]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:916)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:583)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:1492)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:1287)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheKeyObject(GridCacheContext.java:1818)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:279)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4759)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.repairableGet(GridCacheAdapter.java:4725)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1373)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:686)
> at
> org.apache.ignite.internal.IgniteClientReconnectAffinityTest.doReconnectClientAffinityKeyGet(IgniteClientReconnectAffinityTest.java:180)
> at
>
[jira] [Updated] (IGNITE-19020) Specify expire time during conflict resolution
[ https://issues.apache.org/jira/browse/IGNITE-19020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19020: --- Release Note: Added ability to provide expireTime during CDC conflict resolution > Specify expire time during conflict resolution > -- > > Key: IGNITE-19020 > URL: https://issues.apache.org/jira/browse/IGNITE-19020 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59, ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > In case usage of putAllConflict, expireTime behaviour differs from standart > cache operations. > We must allow to the plugin providers to specify expiryTime when resolving > entries conflicts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17449) CDC support eviction policy of entries
[
https://issues.apache.org/jira/browse/IGNITE-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17449:
---
Release Note: Added expiry policy support for CDC
> CDC support eviction policy of entries
> --
>
> Key: IGNITE-17449
> URL: https://issues.apache.org/jira/browse/IGNITE-17449
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The eviction policy can be set not only by configuration but via
> {{IgniteCache#withExpiryPolicy}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17157) Documentation of the Ignite index reader
[
https://issues.apache.org/jira/browse/IGNITE-17157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17157:
Labels: documentation ise (was: documentation)
> Documentation of the Ignite index reader
>
>
> Key: IGNITE-17157
> URL: https://issues.apache.org/jira/browse/IGNITE-17157
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Priority: Major
> Labels: documentation, ise
>
> It would be nice to have a documentation for the Ignite index reader utility
> that was added in IGNITE-14529.
> {panel:title=Draft}
> // Here should also be an overview with the description of the purposes of
> the utility
> To run this utility, use index-reader.sh/index-reader.bat script from Ignite
> *bin* directory.
> *Command line parameters:*
> *--dir*: partition directory, where index.bin and (optionally) partition
> files are located.
> *--part-cnt*: full partitions count in cache group. Default value: 0
> *--page-size*: page size. Default value: 4096
> *--page-store-ver*: page store version. Default value: 2
> *--indexes*: you can specify index tree names that will be processed,
> separated by comma without spaces, other index trees will be skipped. Default
> value: null. Index tree names are not the same as index names, they have
> format _cacheId_typeId_indexName##H2Tree%segmentNumber_, e.g.
> {{2652_885397586_T0_F0_F1_IDX##H2Tree%0}}. You can see them in utility
> output, in traversal information sections (RECURSIVE and HORIZONTAL).
> *--dest-file*: file to print the report to (by default report is printed to
> console). Default value: null
> *--check-parts*: check cache data tree in partition files and it's
> consistency with indexes. Default value: false
> The utility can analyze index.bin and optionally partitions, if *--part-cnt*
> greater that 0 and partition files are present, to read CacheDataTree and to
> look into data pages to check their availability. It reads all index trees
> from index.bin and traverses them in two ways:
> - recursive traversal from root to leaves
> - traversal by each level, as all pages on one level are connected through
> forward ids.
> Also it reads page reuse lists. After all, it scans all pages in file, trying
> to detect orphan pages (those which don’t have any references from index
> trees and reuse lists).
> So, the output of the IgniteIndexReader consists of 4 main sections:
> - recursive traversal info (with prefix )
> - horizontal traversal info (with prefix )
> - page reuse lists info (with prefix )
> - sequential scan of all pages.
> Optionally, with *--check-parts* parameter, it can have information about how
> CacheDataTree matches SQL indexes. If there are no errors, then there is only
> message like this:
> {noformat}
> Partitions check detected no errors.
> Partition check finished, total errors: 0, total problem partitions: 0
> {noformat}
> Otherwise, there is “Partitions check:“ section with list of errors. For
> example, this is how looks message about the entry that was found in
> CacheDataTree, but was not found in SQL indexes:
> {noformat}
> Errors detected in partition, partId=1023
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F0_F1_IDX##H2Tree%0, pageId=0002000d],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F2_IDX##H2Tree%0, pageId=0002000b],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> All errors in the output have prefix .
> {noformat}
> h3. Command line examples
> Analyze files from /gridgain/corrupted_idxs, there should be also 1024
> partitions in this cache group (some of partition files can be missing if
> node where they have been received from was not owning these partitions), use
> pageSize=4096 and page store version 2, report goes to report.txt:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --page-size 4096 --page-store-ver 2 --dest-file "report.txt"
> {noformat}
> Read only SQL indexes:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --dest-file "report.txt"
> {noformat}
> Read SQL indexes and check cache data tree in partitions:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --check-parts --dest-file "rep
> {noformat}
> h3. Output samples
> and output sections contain information about index
> trees: tree name, root page id, page type statistics, count of items. The
> format for both traversals is the same.
> {noformat}
> Index tree: I [idxName=2654_-1177891018__key_PK##H2Tree%0,
> pageId=02020066]
> -- Page stat:
> H2ExtrasLeafIO: 2
> H2ExtrasInnerIO: 1
> BPlusMetaIO: 1
> -- Count of items found in leaf pages: 200
> No
[jira] [Assigned] (IGNITE-17157) Documentation of the Ignite index reader
[
https://issues.apache.org/jira/browse/IGNITE-17157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-17157:
---
Assignee: Julia Bakulina
> Documentation of the Ignite index reader
>
>
> Key: IGNITE-17157
> URL: https://issues.apache.org/jira/browse/IGNITE-17157
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Julia Bakulina
>Priority: Major
> Labels: documentation, ise
>
> It would be nice to have a documentation for the Ignite index reader utility
> that was added in IGNITE-14529.
> {panel:title=Draft}
> // Here should also be an overview with the description of the purposes of
> the utility
> To run this utility, use index-reader.sh/index-reader.bat script from Ignite
> *bin* directory.
> *Command line parameters:*
> *--dir*: partition directory, where index.bin and (optionally) partition
> files are located.
> *--part-cnt*: full partitions count in cache group. Default value: 0
> *--page-size*: page size. Default value: 4096
> *--page-store-ver*: page store version. Default value: 2
> *--indexes*: you can specify index tree names that will be processed,
> separated by comma without spaces, other index trees will be skipped. Default
> value: null. Index tree names are not the same as index names, they have
> format _cacheId_typeId_indexName##H2Tree%segmentNumber_, e.g.
> {{2652_885397586_T0_F0_F1_IDX##H2Tree%0}}. You can see them in utility
> output, in traversal information sections (RECURSIVE and HORIZONTAL).
> *--dest-file*: file to print the report to (by default report is printed to
> console). Default value: null
> *--check-parts*: check cache data tree in partition files and it's
> consistency with indexes. Default value: false
> The utility can analyze index.bin and optionally partitions, if *--part-cnt*
> greater that 0 and partition files are present, to read CacheDataTree and to
> look into data pages to check their availability. It reads all index trees
> from index.bin and traverses them in two ways:
> - recursive traversal from root to leaves
> - traversal by each level, as all pages on one level are connected through
> forward ids.
> Also it reads page reuse lists. After all, it scans all pages in file, trying
> to detect orphan pages (those which don’t have any references from index
> trees and reuse lists).
> So, the output of the IgniteIndexReader consists of 4 main sections:
> - recursive traversal info (with prefix )
> - horizontal traversal info (with prefix )
> - page reuse lists info (with prefix )
> - sequential scan of all pages.
> Optionally, with *--check-parts* parameter, it can have information about how
> CacheDataTree matches SQL indexes. If there are no errors, then there is only
> message like this:
> {noformat}
> Partitions check detected no errors.
> Partition check finished, total errors: 0, total problem partitions: 0
> {noformat}
> Otherwise, there is “Partitions check:“ section with list of errors. For
> example, this is how looks message about the entry that was found in
> CacheDataTree, but was not found in SQL indexes:
> {noformat}
> Errors detected in partition, partId=1023
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F0_F1_IDX##H2Tree%0, pageId=0002000d],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F2_IDX##H2Tree%0, pageId=0002000b],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> All errors in the output have prefix .
> {noformat}
> h3. Command line examples
> Analyze files from /gridgain/corrupted_idxs, there should be also 1024
> partitions in this cache group (some of partition files can be missing if
> node where they have been received from was not owning these partitions), use
> pageSize=4096 and page store version 2, report goes to report.txt:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --page-size 4096 --page-store-ver 2 --dest-file "report.txt"
> {noformat}
> Read only SQL indexes:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --dest-file "report.txt"
> {noformat}
> Read SQL indexes and check cache data tree in partitions:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --check-parts --dest-file "rep
> {noformat}
> h3. Output samples
> and output sections contain information about index
> trees: tree name, root page id, page type statistics, count of items. The
> format for both traversals is the same.
> {noformat}
> Index tree: I [idxName=2654_-1177891018__key_PK##H2Tree%0,
> pageId=02020066]
> -- Page stat:
> H2ExtrasLeafIO: 2
> H2ExtrasInnerIO: 1
> BPlusMetaIO: 1
> -- Count of items found in
[jira] [Updated] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--
Description:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem with character types:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
Problem with numeric types:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS DECIMAL(2))").withParams(new
BigDecimal("123")).check();
}
{code}
The code returns original value where Postgres/Oracle/SQL Server return
conversion error.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
was:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against the rules of calcite's enumerables/link4j (on which the
> code is based), which expect dynamic parameters to be converted into their
> java values according to their inferred types.
> The following code illustrates the problem with character types:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> Problem with numeric types:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS DECIMAL(2))").withParams(new
> BigDecimal("123")).check();
> }
> {code}
> The code returns original value where Postgres/Oracle/SQL Server return
> conversion error.
> *Solution*: convert values of dynamic parameters to java values according to
> type information inferred at the validation stage and pass converted values
> to expression execution runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19350) Fix assertion error in case of empty SQL query
[
https://issues.apache.org/jira/browse/IGNITE-19350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715775#comment-17715775
]
Ignite TC Bot commented on IGNITE-19350:
{panel:title=Branch: [pull/10663/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10663/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7150227]]
* {color:#013220}ClientTestSuite: FunctionalQueryTest.testEmptyQuery -
PASSED{color}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7150160]]
* {color:#013220}IgniteCalciteTestSuite:
CalciteQueryProcessorTest.testEmptyQuery - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7150241buildTypeId=IgniteTests24Java8_RunAll]
> Fix assertion error in case of empty SQL query
> --
>
> Key: IGNITE-19350
> URL: https://issues.apache.org/jira/browse/IGNITE-19350
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Empty SQL query throws AssertionError or IndexOutOfBoundsException.
> SqlParseException is more suitable for this case.
> {noformat}
> [20:43:59,672][SEVERE][client-connector-#84%48a3ed6f-4945-42c9-a5f6-09c1f1d26e35%][ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.cache.ClientCacheSqlFieldsQueryRequest@5fa679b6,
> msg=null]
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCacheSqlFieldsQueryRequest.process(ClientCacheSqlFieldsQueryRequest.java:152)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:101)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:209)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:55)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> [20:43:59] (err) Unexpected exception
> message.org.apache.ignite.client.ClientException: Ignite failed to process
> request [3]: 5: null (server status code [1])
> {noformat}
> {noformat}
> [20:42:55] (err) Unexpected exception.java.lang.IndexOutOfBoundsException:
> Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659)
> at java.util.ArrayList.get(ArrayList.java:435)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2985)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19356) Remove headers from JavaDoc comments
Igor Gusev created IGNITE-19356: --- Summary: Remove headers from JavaDoc comments Key: IGNITE-19356 URL: https://issues.apache.org/jira/browse/IGNITE-19356 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev We have accidently added HTML headers to Javadoc, which causes issues with javadoc release build. We need to replace them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19355) .NET: Thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
[ https://issues.apache.org/jira/browse/IGNITE-19355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19355: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Same schema version is retrieved multiple times in concurrent > scenarios > --- > > Key: IGNITE-19355 > URL: https://issues.apache.org/jira/browse/IGNITE-19355 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > When *Table.ReadSchemaAsync* is called, we send a request for the given > schema version every time, even if another request for that version is active > (e.g. in case of multiple concurrent TUPLE_GET requests). > Instead of caching *ClientSchema*, we should cache *Task*, and > use *GetOrAdd* to guarantee only one request for the given version. Make sure > to handle failures - if a cached Task is failed, send a new request. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19355) .NET: Thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
[ https://issues.apache.org/jira/browse/IGNITE-19355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19355: Description: When *Table.ReadSchemaAsync* is called, we send a request for the given schema version every time, even if another request for that version is active (e.g. in case of multiple concurrent TUPLE_GET requests). Instead of caching *ClientSchema*, we should cache *Task*, and use *GetOrAdd* to guarantee only one request for the given version. Make sure to handle failures - if a cached Task is failed, send a new request. was: When *ClientTable.getSchema* is called, we send a request for the given schema version every time, even if another request for that version is active (e.g. in case of multiple concurrent TUPLE_GET requests). Instead of caching *ClientSchema*, we should cache *CompletableFuture*, and use *computeIfAbsent* to guarantee only one request for the given version. Make sure to handle failures - if a cached future is failed, send a new request. > .NET: Thin 3.0: Same schema version is retrieved multiple times in concurrent > scenarios > --- > > Key: IGNITE-19355 > URL: https://issues.apache.org/jira/browse/IGNITE-19355 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When *Table.ReadSchemaAsync* is called, we send a request for the given > schema version every time, even if another request for that version is active > (e.g. in case of multiple concurrent TUPLE_GET requests). > Instead of caching *ClientSchema*, we should cache *Task*, and > use *GetOrAdd* to guarantee only one request for the given version. Make sure > to handle failures - if a cached Task is failed, send a new request. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19355) .NET: Thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
Pavel Tupitsyn created IGNITE-19355: --- Summary: .NET: Thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios Key: IGNITE-19355 URL: https://issues.apache.org/jira/browse/IGNITE-19355 Project: Ignite Issue Type: Bug Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 When *ClientTable.getSchema* is called, we send a request for the given schema version every time, even if another request for that version is active (e.g. in case of multiple concurrent TUPLE_GET requests). Instead of caching *ClientSchema*, we should cache *CompletableFuture*, and use *computeIfAbsent* to guarantee only one request for the given version. Make sure to handle failures - if a cached future is failed, send a new request. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19354) Java thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
[ https://issues.apache.org/jira/browse/IGNITE-19354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19354: Description: When *ClientTable.getSchema* is called, we send a request for the given schema version every time, even if another request for that version is active (e.g. in case of multiple concurrent TUPLE_GET requests). Instead of caching *ClientSchema*, we should cache *CompletableFuture*, and use *computeIfAbsent* to guarantee only one request for the given version. Make sure to handle failures - if a cached future is failed, send a new request. > Java thin 3.0: Same schema version is retrieved multiple times in concurrent > scenarios > -- > > Key: IGNITE-19354 > URL: https://issues.apache.org/jira/browse/IGNITE-19354 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When *ClientTable.getSchema* is called, we send a request for the given > schema version every time, even if another request for that version is active > (e.g. in case of multiple concurrent TUPLE_GET requests). > Instead of caching *ClientSchema*, we should cache > *CompletableFuture*, and use *computeIfAbsent* to guarantee > only one request for the given version. Make sure to handle failures - if a > cached future is failed, send a new request. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--
Description:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
was:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against the rules of calcite's enumerables/link4j (on which the
> code is based), which expect dynamic parameters to be converted into their
> java values according to their inferred types.
> The following code illustrates the problem:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> *Solution*: convert values of dynamic parameters to java values according to
> type information inferred at the validation stage and pass converted values
> to expression execution runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--
Description:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
was:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: expression execution runtime should use values of dynamic
parameters converted to java values according to type information inferred at
the validation stage.
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against the rules of calcite's enumerables/link4j (on which the
> code is based), which expect dynamic parameters to be converted into their
> java values according to their inferred types.
> The following code illustrates the problem:
> {code:java}
> @Test
> public void testReduceLength() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> *Solution*: convert values of dynamic parameters to java values according to
> type information inferred at the validation stage and pass converted values
> to expression execution runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--
Description:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: expression execution runtime should use values of dynamic
parameters converted to java values according to type information inferred at
the validation stage.
was:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: expression execution runtime should use values of dynamic
parameters converted to java values according to type information inferred at
the validation stage.
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against the rules of calcite's enumerables/link4j (on which the
> code is based), which expect dynamic parameters to be converted into their
> java values according to their inferred types.
> The following code illustrates the problem:
> {code:java}
> @Test
> public void testReduceLength() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> *Solution*: expression execution runtime should use values of dynamic
> parameters converted to java values according to type information inferred at
> the validation stage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19354) Java thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
[ https://issues.apache.org/jira/browse/IGNITE-19354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19354: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Java thin 3.0: Same schema version is retrieved multiple times in concurrent > scenarios > -- > > Key: IGNITE-19354 > URL: https://issues.apache.org/jira/browse/IGNITE-19354 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19354) Java thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
[ https://issues.apache.org/jira/browse/IGNITE-19354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19354: Ignite Flags: (was: Release Notes Required) > Java thin 3.0: Same schema version is retrieved multiple times in concurrent > scenarios > -- > > Key: IGNITE-19354 > URL: https://issues.apache.org/jira/browse/IGNITE-19354 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--
Description:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: expression execution runtime should use values of dynamic
parameters converted to java values according to type information inferred at
the validation stage.
was:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
Solution: convert dynamic parameters to java value according their types
inferred at the validation stage.
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against rules of calcite's enumerables/link4j (on which the code
> is based), which expect dynamic parameters to be converted into their java
> values according to their inferred types.
> The following code illustrates the problem:
> {code:java}
> @Test
> public void testReduceLength() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> *Solution*: expression execution runtime should use values of dynamic
> parameters converted to java values according to type information inferred at
> the validation stage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--
Labels: ignite-3 (was: )
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against rules of calcite's enumerables/link4j (on which the code
> is based), which expect dynamic parameters to be converted into their java
> values according to their inferred types.
> The following code illustrates the problem:
> {code:java}
> @Test
> public void testReduceLength() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> *Solution*: expression execution runtime should use values of dynamic
> parameters converted to java values according to type information inferred at
> the validation stage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19354) Java thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
Pavel Tupitsyn created IGNITE-19354: --- Summary: Java thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios Key: IGNITE-19354 URL: https://issues.apache.org/jira/browse/IGNITE-19354 Project: Ignite Issue Type: Bug Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19354) Java thin 3.0: Same schema version is retrieved multiple times in concurrent scenarios
[ https://issues.apache.org/jira/browse/IGNITE-19354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19354: Component/s: thin client > Java thin 3.0: Same schema version is retrieved multiple times in concurrent > scenarios > -- > > Key: IGNITE-19354 > URL: https://issues.apache.org/jira/browse/IGNITE-19354 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
Maksim Zhuravkov created IGNITE-19353:
-
Summary: Sql. Incorrect type conversion for dynamic parameters -
CAST operation ignores type precision.
Key: IGNITE-19353
URL: https://issues.apache.org/jira/browse/IGNITE-19353
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void testReduceLength() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
Solution: convert dynamic parameters to java value according their types
inferred at the validation stage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19339) Get rid of deprecated GridSslContextFactory at public API
[ https://issues.apache.org/jira/browse/IGNITE-19339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715747#comment-17715747 ] Taras Ledkov commented on IGNITE-19339: --- [~av], OK with me. > Get rid of deprecated GridSslContextFactory at public API > -- > > Key: IGNITE-19339 > URL: https://issues.apache.org/jira/browse/IGNITE-19339 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > GridSslContextFactory deprecated since 2015, and it's time to get rid of it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19352) Create table from query result
[
https://issues.apache.org/jira/browse/IGNITE-19352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Khitrin updated IGNITE-19352:
Affects Version/s: 3.0.0-beta1
> Create table from query result
> --
>
> Key: IGNITE-19352
> URL: https://issues.apache.org/jira/browse/IGNITE-19352
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> Like in IGNITE-14555 for AI2, it would be useful to create tables from the
> result of the query:
> {code:sql}
> CREATE TABLE AS
> {code}
> In the AI3 beta1 and current `main` it's not possible:
> {code:sql}
> sql-cli> create table xx (key_field INT PRIMARY KEY, field1 INT);
> Updated 0 rows.
> sql-cli> insert into xx values (1, 1);
> Updated 1 rows.
> sql-cli> insert into xx values (2, 10);
> Updated 1 rows.
> sql-cli> create table xy as select key_field, field1 from xx where field1 < 5;
> SQL query execution error
> Exception while executing query [query=create table xy as select key_field,
> field1 from xx where field1 < 5;]. Error message:IGN-SQL-3
> TraceId:ff6bc711-14e5-42ab-b80c-5515a8b77c7c Failed to parse query:
> Encountered " "AS" "as "" at line 1, column 17.
> Was expecting:
> "(" ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19055) CPP: Incorrect Compute task failure handling
[
https://issues.apache.org/jira/browse/IGNITE-19055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-19055:
Assignee: Igor Sapego
> CPP: Incorrect Compute task failure handling
>
>
> Key: IGNITE-19055
> URL: https://issues.apache.org/jira/browse/IGNITE-19055
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Mikhail Petrov
>Assignee: Igor Sapego
>Priority: Major
>
> All calculation methods, except for those whose names contain the word
> "affinity", fail to handle errors that occure during task execution.
> They just fail with the following message:
> {code:java}
> Broken promise. Value will never be set due to internal error.
> {code}
> It appears that the CPP IgniteEnvironment::ComputeTaskComplete method does
> not deserialize the exception information at all, which is generated by the
> Java side (see PlatformAbstractTask#onDone).
> DotNet does not have such problems due to the correct implementation of
> exception info deserialization (see
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.ComputeTaskComplete).
> *compute_secutiry_test.cpp should be improved to check for the correct
> security exception message when the issue described in this ticket is
> resolved.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18917) C++ 3.0: Add SQL tests with UUID columns
[ https://issues.apache.org/jira/browse/IGNITE-18917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-18917: Assignee: Igor Sapego > C++ 3.0: Add SQL tests with UUID columns > > > Key: IGNITE-18917 > URL: https://issues.apache.org/jira/browse/IGNITE-18917 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Now when UUID support is implemented for SQL core > (https://issues.apache.org/jira/browse/IGNITE-16376), we need to add tests > with UUID columns to clients to ensure that everything works well in clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19352) Create table from query result
Andrey Khitrin created IGNITE-19352:
---
Summary: Create table from query result
Key: IGNITE-19352
URL: https://issues.apache.org/jira/browse/IGNITE-19352
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Andrey Khitrin
Like in IGNITE-14555 for AI2, it would be useful to create tables from the
result of the query:
{code:sql}
CREATE TABLE AS
{code}
In the AI3 beta1 and current `main` it's not possible:
{code:sql}
sql-cli> create table xx (key_field INT PRIMARY KEY, field1 INT);
Updated 0 rows.
sql-cli> insert into xx values (1, 1);
Updated 1 rows.
sql-cli> insert into xx values (2, 10);
Updated 1 rows.
sql-cli> create table xy as select key_field, field1 from xx where field1 < 5;
SQL query execution error
Exception while executing query [query=create table xy as select key_field,
field1 from xx where field1 < 5;]. Error message:IGN-SQL-3
TraceId:ff6bc711-14e5-42ab-b80c-5515a8b77c7c Failed to parse query: Encountered
" "AS" "as "" at line 1, column 17.
Was expecting:
"(" ...
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19339) Get rid of deprecated GridSslContextFactory at public API
[
https://issues.apache.org/jira/browse/IGNITE-19339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715697#comment-17715697
]
Ignite TC Bot commented on IGNITE-19339:
{panel:title=Branch: [pull/10660/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10660/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7146008buildTypeId=IgniteTests24Java8_RunAll]
> Get rid of deprecated GridSslContextFactory at public API
> --
>
> Key: IGNITE-19339
> URL: https://issues.apache.org/jira/browse/IGNITE-19339
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GridSslContextFactory deprecated since 2015, and it's time to get rid of it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19348) Fix test build
[ https://issues.apache.org/jira/browse/IGNITE-19348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19348: Priority: Blocker (was: Major) > Fix test build > -- > > Key: IGNITE-19348 > URL: https://issues.apache.org/jira/browse/IGNITE-19348 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Some methods were renamed in the IGNITE-19194 which broke test compilation > after IGNITE-19036 was merged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19348) Fix test build
[ https://issues.apache.org/jira/browse/IGNITE-19348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-19348. - Fix Version/s: 3.0.0-beta2 Resolution: Fixed > Fix test build > -- > > Key: IGNITE-19348 > URL: https://issues.apache.org/jira/browse/IGNITE-19348 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Some methods were renamed in the IGNITE-19194 which broke test compilation > after IGNITE-19036 was merged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19348) Fix test build
[ https://issues.apache.org/jira/browse/IGNITE-19348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715690#comment-17715690 ] Pavel Tupitsyn commented on IGNITE-19348: - Merged to main: a08b234e2420b388a63573ff0c76322279ee1853 > Fix test build > -- > > Key: IGNITE-19348 > URL: https://issues.apache.org/jira/browse/IGNITE-19348 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Some methods were renamed in the IGNITE-19194 which broke test compilation > after IGNITE-19036 was merged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-14306) Calcite. Hint ENFORCE JOIN ORDER support
[ https://issues.apache.org/jira/browse/IGNITE-14306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-14306: --- Summary: Calcite. Hint ENFORCE JOIN ORDER support (was: Calcite. Hints ENFORCE JOIN ORDER support) > Calcite. Hint ENFORCE JOIN ORDER support > > > Key: IGNITE-14306 > URL: https://issues.apache.org/jira/browse/IGNITE-14306 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Critical > Labels: calcite2-required, calcite3-required > > We need to introduce hints for the new SQL engine. > At least it could be planner hints, like an ENFORCE JOIN ORDER, Algorithm of > join, switch on/off some planer rules. Maybe we could pass as a hint the > whole execution plan, or modify some parameters, like costs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-14306) Calcite. Hints ENFORCE JOIN ORDER support
[ https://issues.apache.org/jira/browse/IGNITE-14306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-14306: --- Summary: Calcite. Hints ENFORCE JOIN ORDER support (was: Calcite. Hints support) > Calcite. Hints ENFORCE JOIN ORDER support > - > > Key: IGNITE-14306 > URL: https://issues.apache.org/jira/browse/IGNITE-14306 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Critical > Labels: calcite2-required, calcite3-required > > We need to introduce hints for the new SQL engine. > At least it could be planner hints, like an ENFORCE JOIN ORDER, Algorithm of > join, switch on/off some planer rules. Maybe we could pass as a hint the > whole execution plan, or modify some parameters, like costs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19351) Fix flaky ItIgnitePicocliCommandsTest
Mikhail Pochatkin created IGNITE-19351: -- Summary: Fix flaky ItIgnitePicocliCommandsTest Key: IGNITE-19351 URL: https://issues.apache.org/jira/browse/IGNITE-19351 Project: Ignite Issue Type: Test Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17685) SQL engine should send messages asynchronous
[
https://issues.apache.org/jira/browse/IGNITE-17685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-17685:
-
Assignee: Konstantin Orlov
> SQL engine should send messages asynchronous
> -
>
> Key: IGNITE-17685
> URL: https://issues.apache.org/jira/browse/IGNITE-17685
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3, tech-debt
>
> Ignite 3 use asynchronius maner for commnunicaion between nodes. However SQL
> make synchronos wrapper , like
> {code:java}
> messagingSrvc.send(node, msg).join();
> {code}
> It blocks execution thread and could sequinataly lead to full blocking
> queries executoin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
