[jira] [Commented] (IGNITE-18081) .NET: Thin 3.0: LINQ: Basic select queries
[ https://issues.apache.org/jira/browse/IGNITE-18081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632605#comment-17632605 ] Igor Sapego commented on IGNITE-18081: -- [~ptupitsyn] Looks good to me, only left 1 comment. > .NET: Thin 3.0: LINQ: Basic select queries > -- > > Key: IGNITE-18081 > URL: https://issues.apache.org/jira/browse/IGNITE-18081 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement basic LINQ provider with simple SELECT query support. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18126) Fix NPE in RebalanceRaftGroupEventsListener#onLeaderElected()
[
https://issues.apache.org/jira/browse/IGNITE-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18126:
---
Description: I've seen this a few times: {{entry.empty()}} returned false,
but the value was null
> Fix NPE in RebalanceRaftGroupEventsListener#onLeaderElected()
> -
>
> Key: IGNITE-18126
> URL: https://issues.apache.org/jira/browse/IGNITE-18126
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've seen this a few times: {{entry.empty()}} returned false, but the value
> was null
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18122) Track last applied term and group config in storages
Roman Puchkovskiy created IGNITE-18122:
--
Summary: Track last applied term and group config in storages
Key: IGNITE-18122
URL: https://issues.apache.org/jira/browse/IGNITE-18122
Project: Ignite
Issue Type: Improvement
Components: persistence
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
Fix For: 3.0.0-beta2
We need last applied index, term and group config to build a snapshot meta. In
the current implementation, only the index is stored our storages (MV and TX),
but term and config are taken from JRaft's {{{}LogManager{}}}. This is
unreliable as the log might be truncated.
We must store term and config in our storages as well (term in both of them as
it is kinda required attribute of a RAFT index, and group only in MV storage).
Also, we must make sure that on ANY command processed by {{PartitionListener}}
(and on configuration committed event, too), we update lastAppliedIndex+term in
one of the storages, Otherwise, a resulting gap might hinder {{AppendEntries}}
calls to followers requiring to install a snapshot in an infinite loop.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18093) Introduce distribution zone manager for the purposes of zones configuration
[
https://issues.apache.org/jira/browse/IGNITE-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel reassigned IGNITE-18093:
--
Assignee: Sergey Uttsel
> Introduce distribution zone manager for the purposes of zones configuration
> ---
>
> Key: IGNITE-18093
> URL: https://issues.apache.org/jira/browse/IGNITE-18093
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Distribution zones manager is an ignite component that is responsible for
> both zones configuration(create/update/drop) and dataNodes calculation that
> is triggered by corresponding topology and zone modification events.
> Within the scope of current ticket it's expected that DistributionZoneManager
> will be introduced with an internal API to create, drop and alter
> distribution zones.
> h3. Definition of Done
> * New ignite component DistributionZoneManager is introduced.
> * It is inlined into ignite node start/stop flow.
> * It's possible to create/alter/drop distribution zone with the help of
> ignite internal api that technically leads to cluster configuration changes.
> h3. Implementation Notes
> 1. First of all we should introduce new root zones configuration schema:
> {code:java}
> @ConfigurationRoot(rootName = "zone", type = ConfigurationType.DISTRIBUTED)
> public class DistributionZonesConfigurationSchema {
> /** Global integer id counter. Used as an auto-increment counter to generate
> integer identifiers for distribution zone. */
> @Value(hasDefault = true)
> public int globalIdCounter = 0;
>
> /** List of configured distribution zones. */
> @NamedConfigValue
> public DistributionZoneConfigurationSchema distributionZones;
> }{code}
> and zone configuration itself:
> {code:java}
> /**
> * Distribution zone configuration schema class.
> */
> @Config
> public class DistributionZoneConfigurationSchema {
> /** Zone name. */
> @InjectedName
> public String name;
> /** Integer zone id. */
> @Immutable
> @Range(min = 1)
> @Value(hasDefault = true)
> public int zoneId = 1;
> public int dataNodesAutoAdjustScaleUp;
> public int dataNodesAutoAdjustScaleDown;
> public int dataNodesAutoAdjust;
> } {code}
> Filter and affinity function type will be added to configuration later.
> 2. It's also required to introduce DistributionZoneManager as an
> IgniteComponent that should be started and stopped during node start and stop
> flow. The proper place to insert distributionZoneManager.start() is somewhere
> after clusterCfgMgr.start().
> 3. DistributionZoneManager should expose (as in internal API) methods to
> create alter and drop distribution zones.
> 4. Aforementioned create/alter/dropZone API should be available as part of
> Ignite @TestOnly internal api.
> 5. Internally all that methods should call update configuration closures.
> 6. The only interesting part here is input data and drop validations.
> * In case of drop we should check whether there are tables binded to given
> zone. Let's say that CASCADE is not supported for now.
> * Zone name should be checked for uniqueness. Let's ask SE teem about proper
> way of doing such checks, maybe there's an annotation that will help.
> * Neither scaleUp or scaleDown are compatible with common auto adjust, so we
> should complete create result future (yep it's async) exceptionally if user
> specifies both (scaleUp || scaleDown) and common auto adjust. In case of
> alter proposed property should override non-compatible ones.
> * All-in-all some explicit validation, some configuration validators (see
> @TableValidator) and tests are expected.
> 7. Lot's of unit tests are expected to be written, that will check that
> distibutionZoneManager.create()/update()/drop() is either returns future
> completed exceptionally with proper exception or actually change the
> configuration.
> 8. Please pay attention, that within given ticket its' not expected for
> partitions and replicas to be moved inside Zones. Let it still be tables for
> now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18069) Check incremental snapshot before restoring it
[ https://issues.apache.org/jira/browse/IGNITE-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18069: Description: Incremental snapshot must be checked before restoring: # IS matches base snapshot (checks meta files). # All previous incremental snapshot exists. # All WAL segments are present. was:Incremental snapshot must be checked before restoring. > Check incremental snapshot before restoring it > -- > > Key: IGNITE-18069 > URL: https://issues.apache.org/jira/browse/IGNITE-18069 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89 > Time Spent: 10m > Remaining Estimate: 0h > > Incremental snapshot must be checked before restoring: > # IS matches base snapshot (checks meta files). > # All previous incremental snapshot exists. > # All WAL segments are present. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18126) Fix NPE in RebalanceRaftGroupEventsListener#onLeaderElected()
Roman Puchkovskiy created IGNITE-18126: -- Summary: Fix NPE in RebalanceRaftGroupEventsListener#onLeaderElected() Key: IGNITE-18126 URL: https://issues.apache.org/jira/browse/IGNITE-18126 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17977) Help command does not work in some cases
[ https://issues.apache.org/jira/browse/IGNITE-17977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632248#comment-17632248 ] Pavel Tupitsyn commented on IGNITE-17977: - Looks good to me, merged to main: 3c13c03d70eb2cbee0abf56fd017a4c42705c105 > Help command does not work in some cases > > > Key: IGNITE-17977 > URL: https://issues.apache.org/jira/browse/IGNITE-17977 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Aleksandr >Assignee: Ivan Gagarkin >Priority: Critical > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > Case 1: `help sql` does not shows help. > Instead, it executes the `sql` command. That is not expected. For example, > help cluster config displays help info. > Case 2: `help cluster` shows confusing info. > Case 3: `help exit` > We have to think about including this ticket to the beta1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17977) Help command does not work in some cases
[ https://issues.apache.org/jira/browse/IGNITE-17977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17977: Fix Version/s: 3.0.0-beta2 > Help command does not work in some cases > > > Key: IGNITE-17977 > URL: https://issues.apache.org/jira/browse/IGNITE-17977 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Aleksandr >Assignee: Ivan Gagarkin >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > Case 1: `help sql` does not shows help. > Instead, it executes the `sql` command. That is not expected. For example, > help cluster config displays help info. > Case 2: `help cluster` shows confusing info. > Case 3: `help exit` > We have to think about including this ticket to the beta1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18124) [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Available
[ https://issues.apache.org/jira/browse/IGNITE-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenia updated IGNITE-18124: - Summary: [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Available (was: [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Availabla) > [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now > Available > - > > Key: IGNITE-18124 > URL: https://issues.apache.org/jira/browse/IGNITE-18124 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Priority: Major > Attachments: Events.jpg, docs.jpg, ignite-Summit.jpg > > > Please update Ignite Summit event banners. > > All the links should lead to [Ignite Summit November 9, 2022 - Join > virtually! (ignite-summit.org)|https://ignite-summit.org/2022-november/] > Places to update banners: > 1) Featured events > [Distributed Database - Apache Ignite|https://ignite.apache.org/] > 2) Doc's banner > [https://ignite.apache.org/docs/latest/] > 3) Text banner at the top (doc's page) > Ignite Summit Europe — Recordings Available — Watch Now > 4) Update the event page with a new image > [Apache Ignite Events - Meetups, Summit, > Conference|https://ignite.apache.org/events.html#summit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17417) Node name support in CLI
[
https://issues.apache.org/jira/browse/IGNITE-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632249#comment-17632249
]
Pavel Tupitsyn commented on IGNITE-17417:
-
Merged to main: a50582fa75d4087930690120ae7831f411597975
> Node name support in CLI
>
>
> Key: IGNITE-17417
> URL: https://issues.apache.org/jira/browse/IGNITE-17417
> Project: Ignite
> Issue Type: Task
> Components: cli
>Reporter: Aleksandr
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Now there is only one way to point at the ignite node in the CLI – `node-url`
> or `cluster-url` options. They are represented as an URL that sometimes is
> too annoying to type and remember. It would be much more user-friendly to
> have the second option here. I think node name could be used as a CLI option.
> I propose to add `node-name` option to every command that requires
> `cluster-url` or `node-url`. So, the following user story would be possible:
> {code:bash}
> > ignite
> [disconnected]> connect node2
> [node2]> connect node2
> [node2]> node config show --node-name node1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17417) Node name support in CLI
[
https://issues.apache.org/jira/browse/IGNITE-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17417:
Fix Version/s: 3.0.0-beta2
> Node name support in CLI
>
>
> Key: IGNITE-17417
> URL: https://issues.apache.org/jira/browse/IGNITE-17417
> Project: Ignite
> Issue Type: Task
> Components: cli
>Reporter: Aleksandr
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-beta2
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Now there is only one way to point at the ignite node in the CLI – `node-url`
> or `cluster-url` options. They are represented as an URL that sometimes is
> too annoying to type and remember. It would be much more user-friendly to
> have the second option here. I think node name could be used as a CLI option.
> I propose to add `node-name` option to every command that requires
> `cluster-url` or `node-url`. So, the following user story would be possible:
> {code:bash}
> > ignite
> [disconnected]> connect node2
> [node2]> connect node2
> [node2]> node config show --node-name node1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18124) [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Available
[ https://issues.apache.org/jira/browse/IGNITE-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlan Aytpaev reassigned IGNITE-18124: -- Assignee: Erlan Aytpaev > [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now > Available > - > > Key: IGNITE-18124 > URL: https://issues.apache.org/jira/browse/IGNITE-18124 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Major > Attachments: Events.jpg, docs.jpg, ignite-Summit.jpg > > > Please update Ignite Summit event banners. > > All the links should lead to [Ignite Summit November 9, 2022 - Join > virtually! (ignite-summit.org)|https://ignite-summit.org/2022-november/] > Places to update banners: > 1) Featured events > [Distributed Database - Apache Ignite|https://ignite.apache.org/] > 2) Doc's banner > [https://ignite.apache.org/docs/latest/] > 3) Text banner at the top (doc's page) > Ignite Summit Europe — Recordings Available — Watch Now > 4) Update the event page with a new image > [Apache Ignite Events - Meetups, Summit, > Conference|https://ignite.apache.org/events.html#summit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18127) Create documentation for AI3 thin clients
Igor Gusev created IGNITE-18127: --- Summary: Create documentation for AI3 thin clients Key: IGNITE-18127 URL: https://issues.apache.org/jira/browse/IGNITE-18127 Project: Ignite Issue Type: Task Components: ignite-3 Reporter: Igor Gusev Thin clients have been added to AI3 recently. We should add documentation for them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18124) [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Available
[ https://issues.apache.org/jira/browse/IGNITE-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlan Aytpaev resolved IGNITE-18124. Resolution: Fixed > [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now > Available > - > > Key: IGNITE-18124 > URL: https://issues.apache.org/jira/browse/IGNITE-18124 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Major > Attachments: Events.jpg, docs.jpg, ignite-Summit.jpg > > > Please update Ignite Summit event banners. > > All the links should lead to [Ignite Summit November 9, 2022 - Join > virtually! (ignite-summit.org)|https://ignite-summit.org/2022-november/] > Places to update banners: > 1) Featured events > [Distributed Database - Apache Ignite|https://ignite.apache.org/] > 2) Doc's banner > [https://ignite.apache.org/docs/latest/] > 3) Text banner at the top (doc's page) > Ignite Summit Europe — Recordings Available — Watch Now > 4) Update the event page with a new image > [Apache Ignite Events - Meetups, Summit, > Conference|https://ignite.apache.org/events.html#summit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17704) Get rid of usage of RelDataType in execution nodes
[
https://issues.apache.org/jira/browse/IGNITE-17704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-17704:
-
Assignee: Pavel Pereslegin
> Get rid of usage of RelDataType in execution nodes
> --
>
> Key: IGNITE-17704
> URL: https://issues.apache.org/jira/browse/IGNITE-17704
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, tech-debt
>
> Execution-related classes have no third-party dependencies except for apache
> calcite. The only thing connecting them is the RelDataType class, describing
> a type of the row.
> Seems the only actual usage of row type is inside
> {{CorrelatedNestedLoopJoinNode}}.
> So let's get rid of unnecessary coupling by reworking
> {{CorrelatedNestedLoopJoinNode}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18123) .NET: Thin 3.0: LINQ: Skip and Take (offset / limit) support
Pavel Tupitsyn created IGNITE-18123: --- Summary: .NET: Thin 3.0: LINQ: Skip and Take (offset / limit) support Key: IGNITE-18123 URL: https://issues.apache.org/jira/browse/IGNITE-18123 Project: Ignite Issue Type: Sub-task Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement *KeyValueView.AsQueryable*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18123) .NET: Thin 3.0: LINQ: Skip and Take (offset / limit) support
[ https://issues.apache.org/jira/browse/IGNITE-18123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18123: Description: Add support for *Skip* and *Take* (which map to SQL *offset* and *limit*). * Test them together and separately. * Test them at the end of the query and in the middle. was:Implement *KeyValueView.AsQueryable*. > .NET: Thin 3.0: LINQ: Skip and Take (offset / limit) support > > > Key: IGNITE-18123 > URL: https://issues.apache.org/jira/browse/IGNITE-18123 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Add support for *Skip* and *Take* (which map to SQL *offset* and *limit*). > * Test them together and separately. > * Test them at the end of the query and in the middle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18124) [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Availabla
Evgenia created IGNITE-18124: Summary: [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Availabla Key: IGNITE-18124 URL: https://issues.apache.org/jira/browse/IGNITE-18124 Project: Ignite Issue Type: Task Components: website Reporter: Evgenia Attachments: Events.jpg, docs.jpg, ignite-Summit.jpg Please update Ignite Summit event banners. All the links should lead to [Ignite Summit November 9, 2022 - Join virtually! (ignite-summit.org)|https://ignite-summit.org/2022-november/] Places to update banners: 1) Featured events [Distributed Database - Apache Ignite|https://ignite.apache.org/] 2) Doc's banner [https://ignite.apache.org/docs/latest/] 3) Text banner at the top (doc's page) Ignite Summit Europe — Recordings Available — Watch Now 4) Update the event page with a new image [Apache Ignite Events - Meetups, Summit, Conference|https://ignite.apache.org/events.html#summit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17918) Use a single zip task for uber zip file
[
https://issues.apache.org/jira/browse/IGNITE-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17918:
Fix Version/s: 3.0.0-beta2
> Use a single zip task for uber zip file
> ---
>
> Key: IGNITE-17918
> URL: https://issues.apache.org/jira/browse/IGNITE-17918
> Project: Ignite
> Issue Type: Task
> Components: build
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now there is a workaround task
> {code:java}
> task copyCliAndDbZip(type: Copy) {
> from(configurations.cliZip)
> from(configurations.cliZip)
> into("$buildDir/tmp/zip/")
> }
> {code}
> which is required to define a dependency on configurations.cliZip and
> configurations.cliZip but for nothing else. This is not the best solution. We
> have to define dependencies directly in allDistZip task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17918) Use a single zip task for uber zip file
[
https://issues.apache.org/jira/browse/IGNITE-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632234#comment-17632234
]
Pavel Tupitsyn commented on IGNITE-17918:
-
Looks good to me, merged to main: 4fe138332c63f2edcb8c9a90a65fa7aa93af7a3e
> Use a single zip task for uber zip file
> ---
>
> Key: IGNITE-17918
> URL: https://issues.apache.org/jira/browse/IGNITE-17918
> Project: Ignite
> Issue Type: Task
> Components: build
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now there is a workaround task
> {code:java}
> task copyCliAndDbZip(type: Copy) {
> from(configurations.cliZip)
> from(configurations.cliZip)
> into("$buildDir/tmp/zip/")
> }
> {code}
> which is required to define a dependency on configurations.cliZip and
> configurations.cliZip but for nothing else. This is not the best solution. We
> have to define dependencies directly in allDistZip task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18114) Ordered requests can be crushed if CacheConfiguration#queryParallelism is different from default.
[
https://issues.apache.org/jira/browse/IGNITE-18114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632233#comment-17632233
]
Andrey Mashenkov commented on IGNITE-18114:
---
[~zstan], merged to master.
Thanks for your contribution.
> Ordered requests can be crushed if CacheConfiguration#queryParallelism is
> different from default.
> -
>
> Key: IGNITE-18114
> URL: https://issues.apache.org/jira/browse/IGNITE-18114
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.14
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Query with different from default i.e.
> CacheConfiguration#setQueryParallelism(N)
> {noformat}
> "SELECT p.name, p.id FROM \"pers\".Person p INNER JOIN \"org\".Organization o
> ON " +
> "p.orgId = o.id WHERE p.orgId in (3, 4) ORDER BY p.id"
> {noformat}
> fail with :
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.ignite.internal.processors.query.h2.twostep.SortedReducer.addPage0(SortedReducer.java:217)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.AbstractReducer.addPage(AbstractReducer.java:217)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onNextPage(GridReduceQueryExecutor.java:302)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.sendNextPage(GridMapQueryExecutor.java:979)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:517)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.lambda$onQueryRequest$0(GridMapQueryExecutor.java:255)
> ~[classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
Roman Puchkovskiy created IGNITE-18125: -- Summary: Fix NullPointerException in InternalTableImpl#enlist() Key: IGNITE-18125 URL: https://issues.apache.org/jira/browse/IGNITE-18125 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17846) Direct configuration request leads to synchronously waiting on network
[
https://issues.apache.org/jira/browse/IGNITE-17846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632239#comment-17632239
]
Vladislav Pyatkov commented on IGNITE-17846:
Merged 3cce42b9ca95179864484b306c4b646d3b2de1b4
> Direct configuration request leads to synchronously waiting on network
> --
>
> Key: IGNITE-17846
> URL: https://issues.apache.org/jira/browse/IGNITE-17846
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> .NET suite periodical hang out. Log shows the suspicious trace frizzing on a
> getting direct configuration value:
> {noformat}
> "org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2-srv-worker-3"
> #102 prio=10 os_prio=0 cpu=1958.85ms elapsed=391.19s tid=0x7fcb8c005800
> nid=0x3f7b55 waiting on condition [0x7fcce43f2000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.16.1/Native Method)
> - parking to wait for <0x00071e057c88> (a
> java.util.concurrent.CompletableFuture$Signaller)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16.1/LockSupport.java:194)
> at
> java.util.concurrent.CompletableFuture$Signaller.block(java.base@11.0.16.1/CompletableFuture.java:1796)
> at
> java.util.concurrent.ForkJoinPool.managedBlock(java.base@11.0.16.1/ForkJoinPool.java:3128)
> at
> java.util.concurrent.CompletableFuture.waitingGet(java.base@11.0.16.1/CompletableFuture.java:1823)
> at
> java.util.concurrent.CompletableFuture.get(java.base@11.0.16.1/CompletableFuture.java:1998)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.get(ConfigurationChanger.java:627)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.getLatest(ConfigurationChanger.java:328)
> at
> org.apache.ignite.internal.configuration.direct.DirectPropertyProxy.value(DirectPropertyProxy.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.directTableId(TableManager.java:1470)
> at
> org.apache.ignite.internal.table.distributed.TableManager.tableAsyncInternal(TableManager.java:1542)
> at
> org.apache.ignite.internal.table.distributed.TableManager.tableAsync(TableManager.java:1502)
> at
> org.apache.ignite.client.handler.requests.table.ClientTableGetRequest.process(ClientTableGetRequest.java:45)
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:376)
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:336)
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:187)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
>
[jira] [Updated] (IGNITE-18126) Fix NPE in RebalanceRaftGroupEventsListener#onLeaderElected()
[ https://issues.apache.org/jira/browse/IGNITE-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-18126: --- Reviewer: Kirill Gusakov [~kgusakov] could you please take a look? > Fix NPE in RebalanceRaftGroupEventsListener#onLeaderElected() > - > > Key: IGNITE-18126 > URL: https://issues.apache.org/jira/browse/IGNITE-18126 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18122) Track last applied term and group config in storages
[
https://issues.apache.org/jira/browse/IGNITE-18122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632162#comment-17632162
]
Roman Puchkovskiy edited comment on IGNITE-18122 at 11/11/22 11:42 AM:
---
[~apolovtcev] could you please take a look at the attached PR?
was (Author: rpuch):
@Aleksandr Polovtcev could you please take a look at the attached PR?
> Track last applied term and group config in storages
>
>
> Key: IGNITE-18122
> URL: https://issues.apache.org/jira/browse/IGNITE-18122
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need last applied index, term and group config to build a snapshot meta.
> In the current implementation, only the index is stored our storages (MV and
> TX), but term and config are taken from JRaft's {{{}LogManager{}}}. This is
> unreliable as the log might be truncated.
> We must store term and config in our storages as well (term in both of them
> as it is kinda required attribute of a RAFT index, and group only in MV
> storage).
> Also, we must make sure that on ANY command processed by
> {{PartitionListener}} (and on configuration committed event, too), we update
> lastAppliedIndex+term in one of the storages, Otherwise, a resulting gap
> might hinder {{AppendEntries}} calls to followers requiring to install a
> snapshot in an infinite loop.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18128) ReplicaIsAlreadyStartedException when starting a node having a table with at least 2 replicas
Roman Puchkovskiy created IGNITE-18128:
--
Summary: ReplicaIsAlreadyStartedException when starting a node
having a table with at least 2 replicas
Key: IGNITE-18128
URL: https://issues.apache.org/jira/browse/IGNITE-18128
Project: Ignite
Issue Type: Bug
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
How to reproduce:
# Start a cluster of at least 2 nodes (I had 3)
# Create a table with at least 2 replicas (I had 3), wait for a couple of
seconds so it gets replicated
# Restart one of the nodes
{{ReplicaIsAlreadyStartedException}} is thrown because
{{ReplicaManager#startReplica()}} is invoked twice for same replica.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
Stanislav Lukyanov created IGNITE-18129: --- Summary: Fix Ignite 3 build and publishing for beta 1 Key: IGNITE-18129 URL: https://issues.apache.org/jira/browse/IGNITE-18129 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: zip, rpm, deb * nuget -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
[ https://issues.apache.org/jira/browse/IGNITE-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18129: Description: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: jar * nuget was: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: zip, rpm, deb * nuget > Fix Ignite 3 build and publishing for beta 1 > > > Key: IGNITE-18129 > URL: https://issues.apache.org/jira/browse/IGNITE-18129 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > Need to make a few small fixes in the build and publishing process: > * Fix the readme to mention beta 1 instead of alpha 5 > * Automatically build and sign src.zip > * Automatically build and sign .NET NuGet package (package .nuget into a > .nuget.zip like it is done in 2.x) > * Update release.md as needed > The following artifacts need to be uploaded to the release repository: > * src.zip > * ignite: zip, rpm, deb > * ignite-db: zip, rpm, deb > * ignite-client: jar > * nuget -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
[ https://issues.apache.org/jira/browse/IGNITE-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18129: Description: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: jar * nuget.zip was: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: jar * nuget > Fix Ignite 3 build and publishing for beta 1 > > > Key: IGNITE-18129 > URL: https://issues.apache.org/jira/browse/IGNITE-18129 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > Need to make a few small fixes in the build and publishing process: > * Fix the readme to mention beta 1 instead of alpha 5 > * Automatically build and sign src.zip > * Automatically build and sign .NET NuGet package (package .nuget into a > .nuget.zip like it is done in 2.x) > * Update release.md as needed > The following artifacts need to be uploaded to the release repository: > * src.zip > * ignite: zip, rpm, deb > * ignite-db: zip, rpm, deb > * ignite-client: jar > * nuget.zip -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
[ https://issues.apache.org/jira/browse/IGNITE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-18125: --- Reviewer: Alexander Lapin (was: Alexander Lapin) > Fix NullPointerException in InternalTableImpl#enlist() > -- > > Key: IGNITE-18125 > URL: https://issues.apache.org/jira/browse/IGNITE-18125 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
[ https://issues.apache.org/jira/browse/IGNITE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-18125: --- Reviewer: Alexander Lapin [~sanpwc] could you please take a look at the attached PR? > Fix NullPointerException in InternalTableImpl#enlist() > -- > > Key: IGNITE-18125 > URL: https://issues.apache.org/jira/browse/IGNITE-18125 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18130) Increase visibility of SslContextFactory variables and methods
[ https://issues.apache.org/jira/browse/IGNITE-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-18130: Assignee: Nikolay Izhikov > Increase visibility of SslContextFactory variables and methods > -- > > Key: IGNITE-18130 > URL: https://issues.apache.org/jira/browse/IGNITE-18130 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > > To simplify custom implementation of SslContextFactory in case of using > custom key providers (Vault, etc). it will be usefull to increase visibility > of variables and methods. > > From private to protected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18130) Increase visibility of SslContextFactory variables and methods
Nikolay Izhikov created IGNITE-18130: Summary: Increase visibility of SslContextFactory variables and methods Key: IGNITE-18130 URL: https://issues.apache.org/jira/browse/IGNITE-18130 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov To simplify custom implementation of SslContextFactory in case of using custom key providers (Vault, etc). it will be usefull to increase visibility of variables and methods. >From private to protected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18133) .NET: Thin 3.0: Build may fail due to Maven artifacts
[
https://issues.apache.org/jira/browse/IGNITE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18133:
Description:
*ApiException.java* is autogenerated, and occurs in multiple places (cli/target
and cli/build). We should ignore those in the source generator.
{code}
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
MSBuild version 17.3.2+561848881 for .NET
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException", сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Ошибка сборки.
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException",
сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Предупреждений: 0
Ошибок: 2
Прошло времени 00:00:02.78
{code}
was:
ApiException.java is generated, and occurs in multiple places (cli/target and
cli/build). We should ignore those in the source generator.
{code}
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
MSBuild version 17.3.2+561848881 for .NET
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException", сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Ошибка сборки.
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException",
сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Предупреждений: 0
Ошибок: 2
Прошло времени 00:00:02.78
{code}
> .NET: Thin 3.0: Build may fail due to Maven artifacts
> -
>
> Key: IGNITE-18133
> URL: https://issues.apache.org/jira/browse/IGNITE-18133
> Project: Ignite
> Issue Type: Bug
>Affects Versions:
[jira] [Updated] (IGNITE-18133) .NET: Thin 3.0: Build may fail due to Maven artifacts
[
https://issues.apache.org/jira/browse/IGNITE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18133:
Description:
ApiException.java is generated, and occurs in multiple places (cli/target and
cli/build). We should ignore those in the source generator.
{code}
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
MSBuild version 17.3.2+561848881 for .NET
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException", сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Ошибка сборки.
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException",
сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Предупреждений: 0
Ошибок: 2
Прошло времени 00:00:02.78
{code}
was:
{code}
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
MSBuild version 17.3.2+561848881 for .NET
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException", сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Ошибка сборки.
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException",
сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Предупреждений: 0
Ошибок: 2
Прошло времени 00:00:02.78
{code}
> .NET: Thin 3.0: Build may fail due to Maven artifacts
> -
>
> Key: IGNITE-18133
> URL: https://issues.apache.org/jira/browse/IGNITE-18133
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET,
[jira] [Updated] (IGNITE-17999) Incorrect handling of TxStateReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17999:
---
Description:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there is
no a reference to the raft client, the sending will be happening to the node
from an assignment. It {{PrimaryReplicaMissException}} will be caught, the
request should be resent to next node from the assignment.
# We can use a specific read command for read through RAFT. The same command
had been already written before and removed after. Need to resurrect the
command or write similar yourselves.
was:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from PlacementDriver, there is no a
reference to the raft client, the sending will be happening to the node from an
assignment. It PrimaryReplicaMissException will be caught, the request should
be resent to next node from the assignment.
# We can use a specific read command for read through RAFT. The same command
had been already written before and removed after. Need to resurrect the
command or write similar yourselves.
> Incorrect handling of TxStateReplicaRequest
> ---
>
> Key: IGNITE-17999
> URL: https://issues.apache.org/jira/browse/IGNITE-17999
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> After observation, the following points were highlighting to fix:
> # The request has a property named is commitTimestamp, but it is not a time
> to commit. This property should be renamed to readTimestamp, because it is a
> time with which a transaction tries to read another transaction state (to
> read an entry).
> # The request should to be handled by a primary replica (presently, it is
> handled by leader, that can be a different node).
> # TxMata should be read through RAFT, because the leader can be changed, and
> the actual data will be store on the new one.
> *Definition of done:*
> # Property {{TxStateReplicaRequest#commitTimestamp}} should change to
> {{TxStateReplicaRequest#readTimestamp}}.
> # Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there
> is no a reference to the raft client, the sending will be happening to the
> node from an assignment. It {{PrimaryReplicaMissException}} will be caught,
> the request should be resent to next node from the assignment.
> # We can use a specific read command for read through RAFT. The same command
> had been already written before and removed after. Need to resurrect the
> command or write similar yourselves.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17999) Incorrect handling of TxStateReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17999:
---
Description:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from PlacementDriver, there is no a
reference to the raft client, the sending will be happening to the node from an
assignment. It PrimaryReplicaMissException will be caught, the request should
be resent to next node from the assignment.
# We can use a specific read command for read through RAFT. The same command
had been already written before and removed after. Need to resurrect the
command or write similar yourselves.
was:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
Property {{TxStateReplicaRequest#commitTimestamp}} should chage to
{{TxStateReplicaRequest#readTimestamp}}.
> Incorrect handling of TxStateReplicaRequest
> ---
>
> Key: IGNITE-17999
> URL: https://issues.apache.org/jira/browse/IGNITE-17999
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> After observation, the following points were highlighting to fix:
> # The request has a property named is commitTimestamp, but it is not a time
> to commit. This property should be renamed to readTimestamp, because it is a
> time with which a transaction tries to read another transaction state (to
> read an entry).
> # The request should to be handled by a primary replica (presently, it is
> handled by leader, that can be a different node).
> # TxMata should be read through RAFT, because the leader can be changed, and
> the actual data will be store on the new one.
> *Definition of done:*
> # Property {{TxStateReplicaRequest#commitTimestamp}} should change to
> {{TxStateReplicaRequest#readTimestamp}}.
> # Because {{TxStateReplicaRequest}} is sent from PlacementDriver, there is no
> a reference to the raft client, the sending will be happening to the node
> from an assignment. It PrimaryReplicaMissException will be caught, the
> request should be resent to next node from the assignment.
> # We can use a specific read command for read through RAFT. The same command
> had been already written before and removed after. Need to resurrect the
> command or write similar yourselves.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18133) .NET: Thin 3.0: Build may fail due to Maven artifacts
[
https://issues.apache.org/jira/browse/IGNITE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632450#comment-17632450
]
Igor Sapego commented on IGNITE-18133:
--
[~ptupitsyn] looks good to me.
> .NET: Thin 3.0: Build may fail due to Maven artifacts
> -
>
> Key: IGNITE-18133
> URL: https://issues.apache.org/jira/browse/IGNITE-18133
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *ApiException.java* is autogenerated, and occurs in multiple places
> (cli/target and cli/build). We should ignore those in the source generator.
> {code}
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
> MSBuild version 17.3.2+561848881 for .NET
> Определение проектов для восстановления...
> Все проекты обновлены для восстановления.
> Apache.Ignite.Internal.Generators ->
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
> Apache.Ignite.Internal.Generators ->
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
> CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
> источник. Это не повлияет на выходные данные и ошибки компиляции, которые
> могут возникнуть в результате. Тип возникшего исключения:
> "ArgumentException", сообщен
> ие: "An item with the same key has already been added. Key: ApiException"
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
> error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
> orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> Ошибка сборки.
> CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
> источник. Это не повлияет на выходные данные и ошибки компиляции, которые
> могут возникнуть в результате. Тип возникшего исключения:
> "ArgumentException", сообщен
> ие: "An item with the same key has already been added. Key: ApiException"
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
> error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
> orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> Предупреждений: 0
> Ошибок: 2
> Прошло времени 00:00:02.78
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18138) .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
[ https://issues.apache.org/jira/browse/IGNITE-18138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18138: Description: Currently, we use *SELECT * * when mapping query results to the original RecordView type (see *IgniteQueryExpressionVisitor.VisitQuerySourceReference*). (was: Currently, we use *SELECT ** when mapping query results to the original RecordView type (see *IgniteQueryExpressionVisitor.VisitQuerySourceReference*).) > .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns > > > Key: IGNITE-18138 > URL: https://issues.apache.org/jira/browse/IGNITE-18138 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, we use *SELECT * * when mapping query results to the original > RecordView type (see > *IgniteQueryExpressionVisitor.VisitQuerySourceReference*). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18138) .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
[
https://issues.apache.org/jira/browse/IGNITE-18138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18138:
Description: Currently, we use {{SELECT *}} when mapping query results to
the original RecordView type (see
*IgniteQueryExpressionVisitor.VisitQuerySourceReference*). (was: Currently, we
use {code}SELECT *{code} when mapping query results to the original RecordView
type (see *IgniteQueryExpressionVisitor.VisitQuerySourceReference*).)
> .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
>
>
> Key: IGNITE-18138
> URL: https://issues.apache.org/jira/browse/IGNITE-18138
> Project: Ignite
> Issue Type: Sub-task
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, we use {{SELECT *}} when mapping query results to the original
> RecordView type (see
> *IgniteQueryExpressionVisitor.VisitQuerySourceReference*).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18138) .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
[
https://issues.apache.org/jira/browse/IGNITE-18138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18138:
Description: Currently, we use *SELECT ** when mapping query results to the
original RecordView type (see
*IgniteQueryExpressionVisitor.VisitQuerySourceReference*). (was: Currently, we
use {{SELECT *}} when mapping query results to the original RecordView type
(see *IgniteQueryExpressionVisitor.VisitQuerySourceReference*).)
> .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
>
>
> Key: IGNITE-18138
> URL: https://issues.apache.org/jira/browse/IGNITE-18138
> Project: Ignite
> Issue Type: Sub-task
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, we use *SELECT ** when mapping query results to the original
> RecordView type (see
> *IgniteQueryExpressionVisitor.VisitQuerySourceReference*).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18138) .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
[
https://issues.apache.org/jira/browse/IGNITE-18138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18138:
Description: Currently, we use {code}SELECT *{code} when mapping query
results to the original RecordView type (see
*IgniteQueryExpressionVisitor.VisitQuerySourceReference*). (was: Implement
data updates with LINQ.)
> .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
>
>
> Key: IGNITE-18138
> URL: https://issues.apache.org/jira/browse/IGNITE-18138
> Project: Ignite
> Issue Type: Sub-task
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, we use {code}SELECT *{code} when mapping query results to the
> original RecordView type (see
> *IgniteQueryExpressionVisitor.VisitQuerySourceReference*).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18130) Increase visibility of SslContextFactory variables and methods
[ https://issues.apache.org/jira/browse/IGNITE-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-18130: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Increase visibility of SslContextFactory variables and methods > -- > > Key: IGNITE-18130 > URL: https://issues.apache.org/jira/browse/IGNITE-18130 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > To simplify custom implementation of SslContextFactory in case of using > custom key providers (Vault, etc). it will be usefull to increase visibility > of variables and methods. > > From private to protected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17592) Fix synchronous await on futures in raft group events rebalance listener
[ https://issues.apache.org/jira/browse/IGNITE-17592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632361#comment-17632361 ] Kirill Gusakov edited comment on IGNITE-17592 at 11/11/22 1:49 PM: --- It looks like we can replace these gets by * futures chain * return the result future from RebalanceRaftGroupEventsListener#onNewPeersConfigurationApplied * push this future to NodeImpl.getOptions().getCommonExecutor() for async execution But we should return to this issue, only if this place will not be removed at all after IGNITE-18060 was (Author: kgusakov): It looks like we can replace these gets by * futures chain * return the result future from RebalanceRaftGroupEventsListener#onNewPeersConfigurationApplied * push this future to NodeImpl.getOptions().getCommonExecutor() for async execution But we should to return to this issue, only if this place will not be removed at all after IGNITE-18060 > Fix synchronous await on futures in raft group events rebalance listener > > > Key: IGNITE-17592 > URL: https://issues.apache.org/jira/browse/IGNITE-17592 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > Raft group events listener should not be blocked by Future#get methods as it > can move the system to the unstable state. > See the TODOs with this ticket in the source code of > RebalanceRaftGroupEventsListener. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18136) .NET: Thin 3.0: LINQ: Replace reflection with emitted delegates
[ https://issues.apache.org/jira/browse/IGNITE-18136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18136: Description: Replace naive reflection usage with emitted and cached delegates: * *ExpressionWalker.CompileMemberReader* * *IgniteQueryExecutor.GetResultSelector* was:Add full support for *Distinct*. Some scenarios do not work currently - see *TestSelectOrderDistinct*. > .NET: Thin 3.0: LINQ: Replace reflection with emitted delegates > --- > > Key: IGNITE-18136 > URL: https://issues.apache.org/jira/browse/IGNITE-18136 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Replace naive reflection usage with emitted and cached delegates: > * *ExpressionWalker.CompileMemberReader* > * *IgniteQueryExecutor.GetResultSelector* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18136) .NET: Thin 3.0: LINQ: Replace reflection with emitted delegates
Pavel Tupitsyn created IGNITE-18136: --- Summary: .NET: Thin 3.0: LINQ: Replace reflection with emitted delegates Key: IGNITE-18136 URL: https://issues.apache.org/jira/browse/IGNITE-18136 Project: Ignite Issue Type: Sub-task Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Add full support for *Distinct*. Some scenarios do not work currently - see *TestSelectOrderDistinct*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18138) .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
Pavel Tupitsyn created IGNITE-18138: --- Summary: .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns Key: IGNITE-18138 URL: https://issues.apache.org/jira/browse/IGNITE-18138 Project: Ignite Issue Type: Sub-task Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement data updates with LINQ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18134) Introduce common auto adjust scheduler
Alexander Lapin created IGNITE-18134: Summary: Introduce common auto adjust scheduler Key: IGNITE-18134 URL: https://issues.apache.org/jira/browse/IGNITE-18134 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18135) Test GridCommandHandlerMetadataTest#testInvalidArguments should not use target directory
Sergey Chugunov created IGNITE-18135: Summary: Test GridCommandHandlerMetadataTest#testInvalidArguments should not use target directory Key: IGNITE-18135 URL: https://issues.apache.org/jira/browse/IGNITE-18135 Project: Ignite Issue Type: Test Components: control.sh Affects Versions: 2.15 Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.15 Test uses hardcoded *target* folder as part of test logic. It is better to replace usage of this auto-generated folder with tmp folders that are created explicitly by the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17999) Incorrect handling of TxStateReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17999:
---
Description:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there is
no a reference to the raft client, the sending will be happening to the node
from an assignment. It {{PrimaryReplicaMissException}} will be caught, the
request should be resent to next node from the assignment.
was:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there is
no a reference to the raft client, the sending will be happening to the node
from an assignment. It {{PrimaryReplicaMissException}} will be caught, the
request should be resent to next node from the assignment.
# We can use a specific read command for read through RAFT. The same command
had been already written before and removed after. Need to resurrect the
command or write similar yourselves.
> Incorrect handling of TxStateReplicaRequest
> ---
>
> Key: IGNITE-17999
> URL: https://issues.apache.org/jira/browse/IGNITE-17999
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> After observation, the following points were highlighting to fix:
> # The request has a property named is commitTimestamp, but it is not a time
> to commit. This property should be renamed to readTimestamp, because it is a
> time with which a transaction tries to read another transaction state (to
> read an entry).
> # The request should to be handled by a primary replica (presently, it is
> handled by leader, that can be a different node).
> # TxMata should be read through RAFT, because the leader can be changed, and
> the actual data will be store on the new one.
> *Definition of done:*
> # Property {{TxStateReplicaRequest#commitTimestamp}} should change to
> {{TxStateReplicaRequest#readTimestamp}}.
> # Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there
> is no a reference to the raft client, the sending will be happening to the
> node from an assignment. It {{PrimaryReplicaMissException}} will be caught,
> the request should be resent to next node from the assignment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17592) Fix synchronous await on futures in raft group events rebalance listener
[ https://issues.apache.org/jira/browse/IGNITE-17592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632361#comment-17632361 ] Kirill Gusakov commented on IGNITE-17592: - It looks like we can replace these gets by * futures chain * return the result future from RebalanceRaftGroupEventsListener#onNewPeersConfigurationApplied * push this future to NodeImpl.getOptions().getCommonExecutor() for async execution But we should to return to this issue, only if this place will not be removed at all after IGNITE-18060 > Fix synchronous await on futures in raft group events rebalance listener > > > Key: IGNITE-17592 > URL: https://issues.apache.org/jira/browse/IGNITE-17592 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > Raft group events listener should not be blocked by Future#get methods as it > can move the system to the unstable state. > See the TODOs with this ticket in the source code of > RebalanceRaftGroupEventsListener. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
[ https://issues.apache.org/jira/browse/IGNITE-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-18129: -- Assignee: Mikhail Pochatkin > Fix Ignite 3 build and publishing for beta 1 > > > Key: IGNITE-18129 > URL: https://issues.apache.org/jira/browse/IGNITE-18129 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Mikhail Pochatkin >Priority: Major > > Need to make a few small fixes in the build and publishing process: > * Fix the readme to mention beta 1 instead of alpha 5 > * Automatically build and sign src.zip > * Automatically build and sign .NET NuGet package (package .nuget into a > .nuget.zip like it is done in 2.x) > * Update release.md as needed > The following artifacts need to be uploaded to the release repository: > * src.zip > * ignite: zip, rpm, deb > * ignite-db: zip, rpm, deb > * ignite-client: jar > * nuget.zip -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18133) .NET: Thin 3.0: Build may fail due to Maven artifacts
[
https://issues.apache.org/jira/browse/IGNITE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632454#comment-17632454
]
Pavel Tupitsyn commented on IGNITE-18133:
-
Merged to main: 747be38e757f39b310879a6158262d4414020ed6
> .NET: Thin 3.0: Build may fail due to Maven artifacts
> -
>
> Key: IGNITE-18133
> URL: https://issues.apache.org/jira/browse/IGNITE-18133
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *ApiException.java* is autogenerated, and occurs in multiple places
> (cli/target and cli/build). We should ignore those in the source generator.
> {code}
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
> MSBuild version 17.3.2+561848881 for .NET
> Определение проектов для восстановления...
> Все проекты обновлены для восстановления.
> Apache.Ignite.Internal.Generators ->
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
> Apache.Ignite.Internal.Generators ->
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
> CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
> источник. Это не повлияет на выходные данные и ошибки компиляции, которые
> могут возникнуть в результате. Тип возникшего исключения:
> "ArgumentException", сообщен
> ие: "An item with the same key has already been added. Key: ApiException"
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
> error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
> orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> Ошибка сборки.
> CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
> источник. Это не повлияет на выходные данные и ошибки компиляции, которые
> могут возникнуть в результате. Тип возникшего исключения:
> "ArgumentException", сообщен
> ие: "An item with the same key has already been added. Key: ApiException"
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
> error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
> orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> Предупреждений: 0
> Ошибок: 2
> Прошло времени 00:00:02.78
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18131) .NET: Thin 3.0: LINQ: Distinct support
[ https://issues.apache.org/jira/browse/IGNITE-18131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18131: Description: Add full support for *Distinct*. Some scenarios do not work currently - see *TestSelectOrderDistinct*. (was: Add support for *Skip* and *Take* (which map to SQL *offset* and *limit*). * Test them together and separately. * Test them at the end of the query and in the middle.) > .NET: Thin 3.0: LINQ: Distinct support > -- > > Key: IGNITE-18131 > URL: https://issues.apache.org/jira/browse/IGNITE-18131 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Add full support for *Distinct*. Some scenarios do not work currently - see > *TestSelectOrderDistinct*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18121) Introduce scale up scheduler
[
https://issues.apache.org/jira/browse/IGNITE-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18121:
-
Description:
h3. Motivation
Within IGNITE-18115 reaction to the topology events was introduced as an
immediate ms.invoke that will try to update zones..dataNodes key. In
fact, we should defer state recalculation for some time specified by the user
in order to accumulate contiguous topology events. Please check following
example for more details:
|-1|start Node A;
start Node B;
start Node C;
CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300;
CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
nodes A, B, C and creates table Accounts specifying scale up auto adjust
timeout as 300 seconds. Accounts table is created on current topology, meaning
that .dataNodes = [A,B,C]|
|0|start Node D ->
Node D join/validation ->
D enters logical topology ->
logicalTopology.onNodeAdded(Node D) ->
scale_up_auto_adjust(300) timer is
scheduled for the table.|At time 0 seconds the user starts one
more Ignite node D, that joins the cluster. On entering logical topology the
onNodeAdded event is fired. This event schedules a timer of 300 seconds for
table Accounts after which the dataNodes of that table transitively through the
distribution zone will be recalculated from [A,B,C] to [A,B,C,D]
|
|250|start Node E ->
scale_up_auto_adjust(300) is
{*}re{*}scheduled for the table.|At 250 seconds one more node is
added, that action reschedules scale_up_auto_adjust timer for another 300
seconds.|
|550|scale_up_auto_adjust fired ->
set table..dataNodes =
[NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is
fired, that leads to dataNodes recalculation by attaching the
nodes that were added to logical topology - Nodes D and E in the given example.|
|600|start Node F ->
table schedules
scale_up_auto_adjust(300);|At 600 seconds one more node is added, there
are no active scale_up_auto_adjust timers, so given events schedules new one.|
Thus it's required to modify ms topology handler in a way that it should
schedule or re-schedule a timer that will eventually call ms.invoke(dataNodes).
h3. Definition of Done
* DataNodes recalculation is delayed for dataNodesAutoAdjustScaleUp value.
* In case of new scale up toplogy event, existing scale up timers should be
re-scheduled.
h3. Implemention Notes
As usual, pretty straight forward, ScheduledExecutorService with proper naming
should be introduced. Busy locks and proper scheduler stopping required.
> Introduce scale up scheduler
>
>
> Key: IGNITE-18121
> URL: https://issues.apache.org/jira/browse/IGNITE-18121
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Within IGNITE-18115 reaction to the topology events was introduced as an
> immediate ms.invoke that will try to update zones..dataNodes key. In
> fact, we should defer state recalculation for some time specified by the user
> in order to accumulate contiguous topology events. Please check following
> example for more details:
> |-1|start Node A;
> start Node B;
> start Node C;
> CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300;
> CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
> nodes A, B, C and creates table Accounts specifying scale up auto adjust
> timeout as 300 seconds. Accounts table is created on current topology,
> meaning that .dataNodes = [A,B,C]|
> |0|start Node D ->
> Node D join/validation ->
> D enters logical topology ->
> logicalTopology.onNodeAdded(Node D) ->
> scale_up_auto_adjust(300) timer is
> scheduled for the table.|At time 0 seconds the user starts one
> more Ignite node D, that joins the cluster. On entering logical topology the
> onNodeAdded event is fired. This event schedules a timer of 300 seconds for
> table Accounts after which the dataNodes of that table transitively through
> the distribution zone will be recalculated from [A,B,C] to [A,B,C,D]
>
> |
> |250|start Node E ->
> scale_up_auto_adjust(300) is
> {*}re{*}scheduled for the table.|At 250 seconds one more node
> is added, that action reschedules scale_up_auto_adjust timer for another 300
> seconds.|
> |550|scale_up_auto_adjust fired ->
> set table..dataNodes =
> [NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is
> fired, that leads to dataNodes recalculation by attaching the
> nodes that were added to logical topology - Nodes D and E in the given
> example.|
> |600|start Node F ->
> table schedules
> scale_up_auto_adjust(300);|At 600 seconds one more node is added, there
>
[jira] [Created] (IGNITE-18133) .NET: Thin 3.0: Build may fail due to Maven artifacts
Pavel Tupitsyn created IGNITE-18133: --- Summary: .NET: Thin 3.0: Build may fail due to Maven artifacts Key: IGNITE-18133 URL: https://issues.apache.org/jira/browse/IGNITE-18133 Project: Ignite Issue Type: Bug Affects Versions: 3.0.0-beta1 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-18133) .NET: Thin 3.0: Build may fail due to Maven artifacts
[
https://issues.apache.org/jira/browse/IGNITE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18133:
Description:
{code}
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
MSBuild version 17.3.2+561848881 for .NET
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
Apache.Ignite.Internal.Generators ->
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException", сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Ошибка сборки.
CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
источник. Это не повлияет на выходные данные и ошибки компиляции, которые могут
возникнуть в результате. Тип возникшего исключения: "ArgumentException",
сообщен
ие: "An item with the same key has already been added. Key: ApiException"
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
[C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
Предупреждений: 0
Ошибок: 2
Прошло времени 00:00:02.78
{code}
> .NET: Thin 3.0: Build may fail due to Maven artifacts
> -
>
> Key: IGNITE-18133
> URL: https://issues.apache.org/jira/browse/IGNITE-18133
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet>dotnet build
> MSBuild version 17.3.2+561848881 for .NET
> Определение проектов для восстановления...
> Все проекты обновлены для восстановления.
> Apache.Ignite.Internal.Generators ->
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
> Apache.Ignite.Internal.Generators ->
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite.Internal.Generators\bin\Debug\netstandard2.0\Apache.Ignite.Internal.Generators.dll
> CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
> источник. Это не повлияет на выходные данные и ошибки компиляции, которые
> могут возникнуть в результате. Тип возникшего исключения:
> "ArgumentException", сообщен
> ие: "An item with the same key has already been added. Key: ApiException"
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
> error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
> orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> Ошибка сборки.
> CSC : error CS8785: Генератору "ExceptionsGenerator" не удалось создать
> источник. Это не повлияет на выходные данные и ошибки компиляции, которые
> могут возникнуть в результате. Тип возникшего исключения:
> "ArgumentException", сообщен
> ие: "An item with the same key has already been added. Key: ApiException"
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> C:\Users\mapoc\IdeaProjects\ignite-3\modules\platforms\dotnet\Apache.Ignite\Internal\ClientSocket.cs(311,20):
> error CS0103: Имя "ExceptionMapper" не существует в текущем контексте.
> [C:\Users\mapoc\IdeaProjects\ignite-3\modules\platf
> orms\dotnet\Apache.Ignite\Apache.Ignite.csproj]
> Предупреждений: 0
> Ошибок: 2
> Прошло времени 00:00:02.78
> {code}
--
This message was sent by
[jira] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091 ] Denis Chudov deleted comment on IGNITE-18091: --- was (Author: denis chudov): ||Heading 1||Heading 2|| |Col A1|Col A2| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632391#comment-17632391 ] Denis Chudov commented on IGNITE-18091: --- ||Heading 1||Heading 2|| |Col A1|Col A2| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18138) .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns
[ https://issues.apache.org/jira/browse/IGNITE-18138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18138: Description: Currently, we use "SELECT *" when mapping query results to the original RecordView type (see *IgniteQueryExpressionVisitor.VisitQuerySourceReference*). This potentially selects more data than required. We should only select columns that are mapped to the specified type. was:Currently, we use *SELECT * * when mapping query results to the original RecordView type (see *IgniteQueryExpressionVisitor.VisitQuerySourceReference*). > .NET: Thin 3.0: LINQ: Avoid overfetching, select only mapped columns > > > Key: IGNITE-18138 > URL: https://issues.apache.org/jira/browse/IGNITE-18138 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, we use "SELECT *" when mapping query results to the original > RecordView type (see > *IgniteQueryExpressionVisitor.VisitQuerySourceReference*). > This potentially selects more data than required. > We should only select columns that are mapped to the specified type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18132) Introduce scale down scheduler
[
https://issues.apache.org/jira/browse/IGNITE-18132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18132:
-
Description:
h3. Motivation
Surprisingly it's a follow up of an Introduce scale up scheduler
Following logic should be implemented
|-1|start Node A;
start Node B;
start Node C;
CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300,
DATA_NODES_AUTO_ADJUST_{*}SCALE_DOWN{*}= 300_000;
CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
nodes A, B, C and creates table Accounts specifying scale up auto adjust
timeout as 300 seconds. Accounts table is created on current topology, meaning
that .dataNodes = [A,B,C]|
|0|start Node D ->
Node D join/validation ->
D enters logical topology ->
logicalTopology.onNodeAdded(Node D) ->
scale_up_auto_adjust(300) timer is
scheduled for the table.|At time 0 seconds the user starts one
more Ignite node D, that joins the cluster. On entering logical topology the
onNodeAdded event is fired. This event, schedules a timer of 300 seconds for
table Accounts after which the dataNodes of that table will be recalculated
from [A,B,C] to [A,B,C,D]|
|100|stop Node C ->
scale_{*}down{*}_auto_adjust(300_000) timer
is scheduled for the table.|At 100 seconds the user stops Node C
(or it painfully dies). TableManager detects onNodeLeft(Node C) event and
starts scale_down time for 300_000 seconds for table . Please pay
attention that the node left doesn’t affect the scale_up timer.|
|250|start Node E ->
scale_up_auto_adjust(300) timer is
{*}re-{*}scheduled for the table.|At 250 seconds Node E is
added, that re-schedules scale_up_auto_adjust timer for another 300 seconds.
The important part here is that adding the node doesn’t change scale_down time
only scale_up one.|
|550|scale_up_auto_adjust fired ->
set table..dataNodes =
[NodeA, NodeB, {*}NodeC{*}, Node D, Node E]|At 550 seconds scale_up_time is
fired, that leads to dataNodes recalculation by attaching the
nodes that were added to logical topology - Nodes D and E in the given example.
Please pay attention that despite the fact there's no Node C in logical
topology it still takes its place in .dataNodes. |
|300100|*scale_down_auto_adjust fired* ->
set table..dataNodes =
[NodeA, NodeB, Node D, Node E]|At 300_100 seconds scale_down_auto_adjust
timer is fired, that leads to removing Node C from .dataNodes.|
h3. Definition of Done
* DataNodes recalculation transitively triggered by node left event is delayed
for dataNodesAutoAdjustScale{*}Down{*} value.
* In case of new scale down toplogy event, existing scale down timers should
be re-scheduled.
* Scale up timers should not be affected.
h3. Implementation Notes
As as for scale up.
> Introduce scale down scheduler
> --
>
> Key: IGNITE-18132
> URL: https://issues.apache.org/jira/browse/IGNITE-18132
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Surprisingly it's a follow up of an Introduce scale up scheduler
> Following logic should be implemented
> |-1|start Node A;
> start Node B;
> start Node C;
> CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300,
> DATA_NODES_AUTO_ADJUST_{*}SCALE_DOWN{*}= 300_000;
> CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
> nodes A, B, C and creates table Accounts specifying scale up auto adjust
> timeout as 300 seconds. Accounts table is created on current topology,
> meaning that .dataNodes = [A,B,C]|
> |0|start Node D ->
> Node D join/validation ->
> D enters logical topology ->
> logicalTopology.onNodeAdded(Node D) ->
> scale_up_auto_adjust(300) timer is
> scheduled for the table.|At time 0 seconds the user starts one
> more Ignite node D, that joins the cluster. On entering logical topology the
> onNodeAdded event is fired. This event, schedules a timer of 300 seconds for
> table Accounts after which the dataNodes of that table will be recalculated
> from [A,B,C] to [A,B,C,D]|
> |100|stop Node C ->
> scale_{*}down{*}_auto_adjust(300_000) timer
> is scheduled for the table.|At 100 seconds the user stops Node
> C (or it painfully dies). TableManager detects onNodeLeft(Node C) event and
> starts scale_down time for 300_000 seconds for table . Please pay
> attention that the node left doesn’t affect the scale_up timer.|
> |250|start Node E ->
> scale_up_auto_adjust(300) timer is
> {*}re-{*}scheduled for the table.|At 250 seconds Node E is
> added, that re-schedules scale_up_auto_adjust timer for another 300 seconds.
> The important part here is that adding the node doesn’t change scale_down
> time only scale_up one.|
>
[jira] [Updated] (IGNITE-17999) Incorrect handling of TxStateReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17999:
---
Description:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there is
no a reference to the raft client, the sending will be happening to the node
from an assignment. It {{PrimaryReplicaMissException}} will be caught, the
request should be resent to next node from the assignment.
was:
*Motivation:*
After observation, the following points were highlighting to fix:
# The request has a property named is commitTimestamp, but it is not a time to
commit. This property should be renamed to readTimestamp, because it is a time
with which a transaction tries to read another transaction state (to read an
entry).
# The request should to be handled by a primary replica (presently, it is
handled by leader, that can be a different node).
# TxMata should be read through RAFT, because the leader can be changed, and
the actual data will be store on the new one.
*Definition of done:*
# Property {{TxStateReplicaRequest#commitTimestamp}} should change to
{{TxStateReplicaRequest#readTimestamp}}.
# Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there is
no a reference to the raft client, the sending will be happening to the node
from an assignment. It {{PrimaryReplicaMissException}} will be caught, the
request should be resent to next node from the assignment.
> Incorrect handling of TxStateReplicaRequest
> ---
>
> Key: IGNITE-17999
> URL: https://issues.apache.org/jira/browse/IGNITE-17999
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> After observation, the following points were highlighting to fix:
> # The request has a property named is commitTimestamp, but it is not a time
> to commit. This property should be renamed to readTimestamp, because it is a
> time with which a transaction tries to read another transaction state (to
> read an entry).
> # The request should to be handled by a primary replica (presently, it is
> handled by leader, that can be a different node).
> *Definition of done:*
> # Property {{TxStateReplicaRequest#commitTimestamp}} should change to
> {{TxStateReplicaRequest#readTimestamp}}.
> # Because {{TxStateReplicaRequest}} is sent from {{PlacementDriver}}, there
> is no a reference to the raft client, the sending will be happening to the
> node from an assignment. It {{PrimaryReplicaMissException}} will be caught,
> the request should be resent to next node from the assignment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18135) Test GridCommandHandlerMetadataTest#testInvalidArguments should not use target directory
[ https://issues.apache.org/jira/browse/IGNITE-18135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-18135: - Ignite Flags: (was: Docs Required,Release Notes Required) > Test GridCommandHandlerMetadataTest#testInvalidArguments should not use > target directory > > > Key: IGNITE-18135 > URL: https://issues.apache.org/jira/browse/IGNITE-18135 > Project: Ignite > Issue Type: Test > Components: control.sh >Affects Versions: 2.15 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.15 > > > Test uses hardcoded *target* folder as part of test logic. > It is better to replace usage of this auto-generated folder with tmp folders > that are created explicitly by the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18124) [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now Available
[ https://issues.apache.org/jira/browse/IGNITE-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632320#comment-17632320 ] Vladislav Pyatkov commented on IGNITE-18124: Merged 4208d8fa340f7902e196e8115ba4533417003cec > [Ignite Website] Ignite Summit Europe_Update website banners_Recordings Now > Available > - > > Key: IGNITE-18124 > URL: https://issues.apache.org/jira/browse/IGNITE-18124 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Major > Attachments: Events.jpg, docs.jpg, ignite-Summit.jpg > > > Please update Ignite Summit event banners. > > All the links should lead to [Ignite Summit November 9, 2022 - Join > virtually! (ignite-summit.org)|https://ignite-summit.org/2022-november/] > Places to update banners: > 1) Featured events > [Distributed Database - Apache Ignite|https://ignite.apache.org/] > 2) Doc's banner > [https://ignite.apache.org/docs/latest/] > 3) Text banner at the top (doc's page) > Ignite Summit Europe — Recordings Available — Watch Now > 4) Update the event page with a new image > [Apache Ignite Events - Meetups, Summit, > Conference|https://ignite.apache.org/events.html#summit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18121) Introduce scale up scheduler
[
https://issues.apache.org/jira/browse/IGNITE-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18121:
-
Description:
h3. Motivation
Within IGNITE-18115 reaction to the topology events was introduced as an
immediate ms.invoke that will try to update zones..dataNodes key. In
fact, we should defer state recalculation for some time specified by the user
in order to accumulate contiguous topology events. Please check following
example for more details:
|-1|start Node A;
start Node B;
start Node C;
CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300;
CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
nodes A, B, C and creates table Accounts specifying scale up auto adjust
timeout as 300 seconds. Accounts table is created on current topology, meaning
that .dataNodes = [A,B,C]|
|0|start Node D ->
Node D join/validation ->
D enters logical topology ->
logicalTopology.onNodeAdded(Node D) ->
scale_up_auto_adjust(300) timer is
scheduled for the table.|At time 0 seconds the user starts one
more Ignite node D, that joins the cluster. On entering logical topology the
onNodeAdded event is fired. This event schedules a timer of 300 seconds for
table Accounts after which the dataNodes of that table transitively through the
distribution zone will be recalculated from [A,B,C] to [A,B,C,D]
|
|250|start Node E ->
scale_up_auto_adjust(300) is
{*}re{*}scheduled for the table.|At 250 seconds one more node is
added, that action reschedules scale_up_auto_adjust timer for another 300
seconds.|
|550|scale_up_auto_adjust fired ->
set table..dataNodes =
[NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is
fired, that leads to dataNodes recalculation by attaching the
nodes that were added to logical topology - Nodes D and E in the given example.|
|600|start Node F ->
table schedules
scale_up_auto_adjust(300);|At 600 seconds one more node is added, there
are no active scale_up_auto_adjust timers, so given events schedules new one.|
Thus it's required to modify ms topology handler in a way that it should
schedule or re-schedule a timer that will eventually call ms.invoke(dataNodes).
h3. Definition of Done
* DataNodes recalculation transitively triggered by node add event is delayed
for dataNodesAutoAdjustScaleUp value.
* In case of new scale up toplogy event, existing scale up timers should be
re-scheduled.
h3. Implemention Notes
As usual, pretty straight forward, ScheduledExecutorService with proper naming
should be introduced. Busy locks and proper scheduler stopping required.
was:
h3. Motivation
Within IGNITE-18115 reaction to the topology events was introduced as an
immediate ms.invoke that will try to update zones..dataNodes key. In
fact, we should defer state recalculation for some time specified by the user
in order to accumulate contiguous topology events. Please check following
example for more details:
|-1|start Node A;
start Node B;
start Node C;
CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300;
CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite
nodes A, B, C and creates table Accounts specifying scale up auto adjust
timeout as 300 seconds. Accounts table is created on current topology, meaning
that .dataNodes = [A,B,C]|
|0|start Node D ->
Node D join/validation ->
D enters logical topology ->
logicalTopology.onNodeAdded(Node D) ->
scale_up_auto_adjust(300) timer is
scheduled for the table.|At time 0 seconds the user starts one
more Ignite node D, that joins the cluster. On entering logical topology the
onNodeAdded event is fired. This event schedules a timer of 300 seconds for
table Accounts after which the dataNodes of that table transitively through the
distribution zone will be recalculated from [A,B,C] to [A,B,C,D]
|
|250|start Node E ->
scale_up_auto_adjust(300) is
{*}re{*}scheduled for the table.|At 250 seconds one more node is
added, that action reschedules scale_up_auto_adjust timer for another 300
seconds.|
|550|scale_up_auto_adjust fired ->
set table..dataNodes =
[NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is
fired, that leads to dataNodes recalculation by attaching the
nodes that were added to logical topology - Nodes D and E in the given example.|
|600|start Node F ->
table schedules
scale_up_auto_adjust(300);|At 600 seconds one more node is added, there
are no active scale_up_auto_adjust timers, so given events schedules new one.|
Thus it's required to modify ms topology handler in a way that it should
schedule or re-schedule a timer that will eventually call ms.invoke(dataNodes).
h3. Definition of Done
* DataNodes recalculation is delayed for dataNodesAutoAdjustScaleUp value.
* In case of new scale up toplogy event,
[jira] [Updated] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
[
https://issues.apache.org/jira/browse/IGNITE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18125:
---
Description: A {{NullPointerException}} is thrown if an upstream future
completes with an exception, hence {{primaryPeerAndTerm}} is null
> Fix NullPointerException in InternalTableImpl#enlist()
> --
>
> Key: IGNITE-18125
> URL: https://issues.apache.org/jira/browse/IGNITE-18125
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> A {{NullPointerException}} is thrown if an upstream future completes with an
> exception, hence {{primaryPeerAndTerm}} is null
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
[ https://issues.apache.org/jira/browse/IGNITE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632360#comment-17632360 ] Alexander Lapin commented on IGNITE-18125: -- [~rpuch] LGTM, thanks! > Fix NullPointerException in InternalTableImpl#enlist() > -- > > Key: IGNITE-18125 > URL: https://issues.apache.org/jira/browse/IGNITE-18125 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18122) Track last applied term and group config in storages
[
https://issues.apache.org/jira/browse/IGNITE-18122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632401#comment-17632401
]
Aleksandr Polovtcev commented on IGNITE-18122:
--
Looking good!
> Track last applied term and group config in storages
>
>
> Key: IGNITE-18122
> URL: https://issues.apache.org/jira/browse/IGNITE-18122
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> We need last applied index, term and group config to build a snapshot meta.
> In the current implementation, only the index is stored our storages (MV and
> TX), but term and config are taken from JRaft's {{{}LogManager{}}}. This is
> unreliable as the log might be truncated.
> We must store term and config in our storages as well (term in both of them
> as it is kinda required attribute of a RAFT index, and group only in MV
> storage).
> Also, we must make sure that on ANY command processed by
> {{PartitionListener}} (and on configuration committed event, too), we update
> lastAppliedIndex+term in one of the storages, Otherwise, a resulting gap
> might hinder {{AppendEntries}} calls to followers requiring to install a
> snapshot in an infinite loop.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
[
https://issues.apache.org/jira/browse/IGNITE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632427#comment-17632427
]
Roman Puchkovskiy commented on IGNITE-18125:
Thanks for your review!
> Fix NullPointerException in InternalTableImpl#enlist()
> --
>
> Key: IGNITE-18125
> URL: https://issues.apache.org/jira/browse/IGNITE-18125
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> A {{NullPointerException}} is thrown if an upstream future completes with an
> exception, hence {{primaryPeerAndTerm}} is null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18084) .NET: Thin 3.0: LINQ: Async materialization
[ https://issues.apache.org/jira/browse/IGNITE-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18084: Description: Support *ToListAsync*, *ToArrayAsync*, *CountAsync*, etc. * Check how EF does this with *EntityFrameworkQueryableExtensions* was: Support ToListAsync, ToArrayAsync, CountAsync, etc. * Check how EF does this with EntityFrameworkQueryableExtensions > .NET: Thin 3.0: LINQ: Async materialization > --- > > Key: IGNITE-18084 > URL: https://issues.apache.org/jira/browse/IGNITE-18084 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Support *ToListAsync*, *ToArrayAsync*, *CountAsync*, etc. > * Check how EF does this with *EntityFrameworkQueryableExtensions* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18084) .NET: Thin 3.0: LINQ: Async materialization
[ https://issues.apache.org/jira/browse/IGNITE-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18084: Description: Support ToListAsync, ToArrayAsync, CountAsync, etc. * Check how EF does this with EntityFrameworkQueryableExtensions was:Support ToListAsync, ToArrayAsync, CountAsync, etc. > .NET: Thin 3.0: LINQ: Async materialization > --- > > Key: IGNITE-18084 > URL: https://issues.apache.org/jira/browse/IGNITE-18084 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Support ToListAsync, ToArrayAsync, CountAsync, etc. > * Check how EF does this with EntityFrameworkQueryableExtensions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18130) Increase visibility of SslContextFactory variables and methods
[ https://issues.apache.org/jira/browse/IGNITE-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-18130. -- Resolution: Fixed > Increase visibility of SslContextFactory variables and methods > -- > > Key: IGNITE-18130 > URL: https://issues.apache.org/jira/browse/IGNITE-18130 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > To simplify custom implementation of SslContextFactory in case of using > custom key providers (Vault, etc). it will be usefull to increase visibility > of variables and methods. > > From private to protected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18130) Increase visibility of SslContextFactory variables and methods
[ https://issues.apache.org/jira/browse/IGNITE-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-18130: - Fix Version/s: 2.15 > Increase visibility of SslContextFactory variables and methods > -- > > Key: IGNITE-18130 > URL: https://issues.apache.org/jira/browse/IGNITE-18130 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > To simplify custom implementation of SslContextFactory in case of using > custom key providers (Vault, etc). it will be usefull to increase visibility > of variables and methods. > > From private to protected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18131) .NET: Thin 3.0: LINQ: Distinct support
Pavel Tupitsyn created IGNITE-18131: --- Summary: .NET: Thin 3.0: LINQ: Distinct support Key: IGNITE-18131 URL: https://issues.apache.org/jira/browse/IGNITE-18131 Project: Ignite Issue Type: Sub-task Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Add support for *Skip* and *Take* (which map to SQL *offset* and *limit*). * Test them together and separately. * Test them at the end of the query and in the middle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18057) Sql. Fix index scan transactional consistency.
[ https://issues.apache.org/jira/browse/IGNITE-18057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-18057: - Description: h3. Motivation According to tx protocol in order to prevent phantom reads we should lock current key on every iteration that may be bigger than upper bound border. Let's check following example: tbl [3, 5, 8] select * from tbl where k >= 3 and k <= 7 may be internally converted to sorted index scan (lowerBorder=3[included], upperBorder=7[included]) thus we won't see key 8 and won't lock it. That means that tx2 may insert key 6, so that we finish with phantom read anomaly on select * from tbl where k >= 3 and k <= 7 re-run. h3. Definition of Done Aforementioned scenario won't lead to phantom read. h3. Implementation Notes We should lock ceil(upper bound key) or +INF if there's no such key, thus we should iterate over sorted index without upper bound parameter manually comparing next key with users upperBound. was: TBD. Long story short. For now, searching for lower bound looks broken in storage. Storage cursor returns either lower bound (if found) or next item that large lower bound. In second case, * TX1 starts scan and searching for a lower bound, then lock a row next to the desired lower bound. * A concurrent transaction TX2 may add a new row between the lower bound and row which TX1 is about to lock. * TX1 must release lock and retry search, but it can't detect the issue. > Sql. Fix index scan transactional consistency. > -- > > Key: IGNITE-18057 > URL: https://issues.apache.org/jira/browse/IGNITE-18057 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > > h3. Motivation > According to tx protocol in order to prevent phantom reads we should lock > current key on every iteration that may be bigger than upper bound border. > Let's check following example: > tbl [3, 5, 8] > select * from tbl where k >= 3 and k <= 7 may be internally converted to > sorted index scan (lowerBorder=3[included], upperBorder=7[included]) > thus we won't see key 8 and won't lock it. > That means that tx2 may insert key 6, so that we finish with phantom read > anomaly on select * from tbl where k >= 3 and k <= 7 re-run. > h3. Definition of Done > Aforementioned scenario won't lead to phantom read. > h3. Implementation Notes > We should lock ceil(upper bound key) or +INF if there's no such key, thus we > should iterate over sorted index without upper bound parameter manually > comparing next key with users upperBound. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18098) ignite3 db should write logs into the logs folder.
[
https://issues.apache.org/jira/browse/IGNITE-18098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-18098.
Resolution: Duplicate
> ignite3 db should write logs into the logs folder.
> ---
>
> Key: IGNITE-18098
> URL: https://issues.apache.org/jira/browse/IGNITE-18098
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Yury Yudin
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> Currently ignite3db (executed from unpacked zip distro) appears to create an
> empty .log file in the log directory, but most of the logs are
> still written into the IGNITE_HOME/ignite3*.log files instead.
> Should be written into the log directory instead.
> {code:java}
> demo@ymac ignite3-db-3.0.0-SNAPSHOT % l
> ./ README.md ignite3db-0.log.lck work/
> ../ bin/ lib/
> LICENSE etc/ log/
> NOTICE ignite3db-0.log pid
> jjb@demo ignite3-db-3.0.0-SNAPSHOT % ll log
> total 0
> drwxr-xr-x 3 demo staff 96 7 Nov 08:51 .
> drwxr-xr-x 13 demo staff 416 7 Nov 08:51 ..
> -rw-r--r-- 1 demo staff 0 7 Nov 08:51 demo1.log
> demo@ymac ignite3-db-3.0.0-SNAPSHOT % {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18095) Ignite3 db startup script should attempt to guess IGNITE_HOME if not set
[
https://issues.apache.org/jira/browse/IGNITE-18095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632415#comment-17632415
]
Aleksandr commented on IGNITE-18095:
fixed in IGNITE-17917
> Ignite3 db startup script should attempt to guess IGNITE_HOME if not set
>
>
> Key: IGNITE-18095
> URL: https://issues.apache.org/jira/browse/IGNITE-18095
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Yury Yudin
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> demo@mac bin % ./ignite3db
> ./ignite3db: line 25:
> /Users/demo/Ignite/Binaries/ignite3/ignite3-db-3.0.0-SNAPSHOT/bin/etc/bootstrap-config.env:
> No such file or directory
> demo@mac bin % {code}
> It looks like the guess of IGNITE_HOME was incorrect and needs fixing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-18095) Ignite3 db startup script should attempt to guess IGNITE_HOME if not set
[
https://issues.apache.org/jira/browse/IGNITE-18095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-18095.
Resolution: Duplicate
> Ignite3 db startup script should attempt to guess IGNITE_HOME if not set
>
>
> Key: IGNITE-18095
> URL: https://issues.apache.org/jira/browse/IGNITE-18095
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Yury Yudin
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> demo@mac bin % ./ignite3db
> ./ignite3db: line 25:
> /Users/demo/Ignite/Binaries/ignite3/ignite3-db-3.0.0-SNAPSHOT/bin/etc/bootstrap-config.env:
> No such file or directory
> demo@mac bin % {code}
> It looks like the guess of IGNITE_HOME was incorrect and needs fixing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18098) ignite3 db should write logs into the logs folder.
[
https://issues.apache.org/jira/browse/IGNITE-18098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632414#comment-17632414
]
Aleksandr commented on IGNITE-18098:
fixed in IGNITE-17917
> ignite3 db should write logs into the logs folder.
> ---
>
> Key: IGNITE-18098
> URL: https://issues.apache.org/jira/browse/IGNITE-18098
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Yury Yudin
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> Currently ignite3db (executed from unpacked zip distro) appears to create an
> empty .log file in the log directory, but most of the logs are
> still written into the IGNITE_HOME/ignite3*.log files instead.
> Should be written into the log directory instead.
> {code:java}
> demo@ymac ignite3-db-3.0.0-SNAPSHOT % l
> ./ README.md ignite3db-0.log.lck work/
> ../ bin/ lib/
> LICENSE etc/ log/
> NOTICE ignite3db-0.log pid
> jjb@demo ignite3-db-3.0.0-SNAPSHOT % ll log
> total 0
> drwxr-xr-x 3 demo staff 96 7 Nov 08:51 .
> drwxr-xr-x 13 demo staff 416 7 Nov 08:51 ..
> -rw-r--r-- 1 demo staff 0 7 Nov 08:51 demo1.log
> demo@ymac ignite3-db-3.0.0-SNAPSHOT % {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18132) Introduce scale down scheduler
Alexander Lapin created IGNITE-18132: Summary: Introduce scale down scheduler Key: IGNITE-18132 URL: https://issues.apache.org/jira/browse/IGNITE-18132 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18125) Fix NullPointerException in InternalTableImpl#enlist()
[
https://issues.apache.org/jira/browse/IGNITE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18125:
---
Description: A {{NullPointerException}} is thrown if an upstream future
completes with an exception, hence {{primaryPeerAndTerm}} is null. (was: A
{{NullPointerException}} is thrown if an upstream future completes with an
exception, hence {{primaryPeerAndTerm}} is null)
> Fix NullPointerException in InternalTableImpl#enlist()
> --
>
> Key: IGNITE-18125
> URL: https://issues.apache.org/jira/browse/IGNITE-18125
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> A {{NullPointerException}} is thrown if an upstream future completes with an
> exception, hence {{primaryPeerAndTerm}} is null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18137) .NET: Thin 3.0: LINQ: DML
Pavel Tupitsyn created IGNITE-18137: --- Summary: .NET: Thin 3.0: LINQ: DML Key: IGNITE-18137 URL: https://issues.apache.org/jira/browse/IGNITE-18137 Project: Ignite Issue Type: Sub-task Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Replace naive reflection usage with emitted and cached delegates: * *ExpressionWalker.CompileMemberReader* * *IgniteQueryExecutor.GetResultSelector* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18137) .NET: Thin 3.0: LINQ: DML
[ https://issues.apache.org/jira/browse/IGNITE-18137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18137: Description: Implement data updates with LINQ. (was: Replace naive reflection usage with emitted and cached delegates: * *ExpressionWalker.CompileMemberReader* * *IgniteQueryExecutor.GetResultSelector*) > .NET: Thin 3.0: LINQ: DML > - > > Key: IGNITE-18137 > URL: https://issues.apache.org/jira/browse/IGNITE-18137 > Project: Ignite > Issue Type: Sub-task > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement data updates with LINQ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
