Re: [DISCUSSION] 3.0/3.1 compatibility on aarch64 and some other platforms

Hi guys! > Do I understand correctly, that mostly affected are the users that are currently using Ignite on aarch64 (and some other, rare architectures)? Yes, that's correct. Only by those users. > What are those, can you please provide examples? "aarch64", for example, that's the architecture

Re: [DISCUSSION] 3.0/3.1 compatibility on aarch64 and some other platforms

> Little Endian architectures that are NOT > included in the following list: "i386", "x86", "amd64", and "x86_64" What are those, can you please provide examples? On Wed, Jul 23, 2025 at 9:50 PM Aleksandr Polovtsev wrote: > > Thank you, Ivan, for the detailed explanation. > Do I understand corr

Re: [DISCUSSION] 3.0/3.1 compatibility on aarch64 and some other platforms

Thank you, Ivan, for the detailed explanation. Do I understand correctly, that mostly affected are the users that are currently using Ignite on aarch64 (and some other, rare architectures)? If yes, then your proposal makes sense, Ignite is mostly targeted at the servers which usually run on x86_64.

[DISCUSSION] 3.0/3.1 compatibility on aarch64 and some other platforms

Hello, Igniters! Recently we encountered an unexpected issue. Let me start with its roots, before I start discussing potential fixes. We noticed that certain benchmarks showed some inefficiencies when being run on new MacBooks. They were related to low-level serialization code, and the cause of i

[DISCUSSION] IEP-139: Ignite 3. SQL client and JDBC partition awareness

Hi Igniters! Please review the proposal for Ignite-3 [1] and let me know what you think   [1]  https://cwiki.apache.org/confluence/display/IGNITE/IEP-139%3A+SQL+client+and+JDBC+partition+awareness      

Re: [DISCUSSION] IEP-137: Ignite 3. Sql. EXPLAIN command

Hi Konstantin, The proposal looks good to me. It will be really helpful for understanding how a query will be executed вт, 20 мая 2025 г. в 10:43, Konstantin Orlov : > Hi Igniters! > > Please review the proposal for Ignite-3 [1] and let me know what you think. > > [1] IEP-137: Ignite 3. Sql. EXP

[DISCUSSION] IEP-137: Ignite 3. Sql. EXPLAIN command

Hi Igniters! Please review the proposal for Ignite-3 [1] and let me know what you think. [1] IEP-137: Ignite 3. Sql. EXPLAIN command -- Regards, Konstantin Orlov

[DISCUSSION] IEP-136 .NET Platform Compute (Ignite 3)

Igniters, Please have a look at the .NET Platform Compute proposal for Ignite 3 and let me know what you think. https://cwiki.apache.org/confluence/display/IGNITE/IEP-136+Platform+Compute

[DISCUSSION] IEP-135 Migration Tools. (Ignite-3)

Hello Igniters, Please take a look at this new proposal for Ignite 3: IEP-135 Migration Tools [1]. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-135+Migration+Tools Best Regards, Tiago Marques Godinho.

[DISCUSSION]

Hello Igniters! Please take a look at the proposal for Ignite 3 [1]. [1] IEP-131: Partition Majority Unavailability Handling https://cwiki.apache.org/confluence/display/IGNITE/IEP-131%3A+Partition+Majority+Unavailability+Handling

[DISCUSSION] IEP-134 SQL-schema support. (Ignite-3)

Hello Igniters, Please, take a look at the proposal for Ignite 3: IEP-134 SQL-schema support [1]. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-134+SQL-schema+Support -- Best regards, Andrey V. Mashenkov

[DISCUSSION] IEP-133: Replicated zones

Hello Igniters, Please take a look at this proposal [1]. [1] IEP-133 Replicated zones https://cwiki.apache.org/confluence/display/IGNITE/IEP-133+Replicated+zones -- Denis Chudov

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

I implemented it without changing the default of the property. Now it will be allowed to execute system tasks even if ThinClientConfiguration#setMaxActiveComputeTasksPerConnection is 0. This makes it possible to run management tasks even when the user has explicitly disabled the execution of user t

Re: [DISCUSSION] IEP-132 Rolling Upgrade

Hello, Slava. > MessageFactory `MessageFactory` are deprecated and related to Communication SPI which must be reworked for supporting compatibility. So, I think we must clean up this code and remove all deprecated parts before starting. Moreover, current approach when we want to sent each fiel

Re: [DISCUSSION] IEP-130: Spring Boot support

Ok, this makes sense, thank you. On Tue, Dec 3, 2024 at 4:30 PM Maxim Myskov wrote: > Yes, it would be easier to manage configs if they could be identical on > all nodes. This would avoid situations where several nodes have this flag > (in case if it is a flag) enabled. > -- > Maksim Myskov > >

Re: [DISCUSSION] IEP-130: Spring Boot support

Yes, it would be easier to manage configs if they could be identical on all nodes. This would avoid situations where several nodes have this flag (in case if it is a flag) enabled. -- Maksim Myskov > On 3 Dec 2024, at 17:13, Pavel Tupitsyn wrote: > >> adding the "ignite.bootstrap.nodeName" pro

Re: [DISCUSSION] IEP-130: Spring Boot support

> adding the "ignite.bootstrap.nodeName" property to define the node that performs cluster initialization on startup Why node name and not a boolean flag? Is that so the config is the same on all nodes, but only the node with the matching name starts initialization? On Tue, Dec 3, 2024 at 3:56 PM

Re: [DISCUSSION] IEP-130: Spring Boot support

Hello Pavel, What do you think about the approach? -- Maksim Myskov > On 28 Nov 2024, at 11:54, Maxim Myskov wrote: > > Hello Pavel, > > I updated the "Embedded mode” section, please take a look. > In short, I propose adding the "ignite.bootstrap.nodeName" property to define > the node that

Re: [DISCUSSION] IEP-132 Rolling Upgrade

Hello Nickolay, This is a good idea! I fully support it. Could you please specify the particular points related to phase 0 (code cleanup)? - MessageFactory. - IgniteDataTransferObject What should be done with IgniteDataTransferObject and why? Thanks, S. пт, 29 нояб. 2024 г. в 18:35, Ni

[DISCUSSION] IEP-132 Rolling Upgrade

Hello, Igniters. Rolling Upgrade are crucial missing feature for Ignite. I propose to implement it. RU support are complex task and require some well thought out decisions to be made. Please, take a look at the IEP [1] and share your feedback. [1] https://cwiki.apache.org/confluence/display/IGN

Re: [DISCUSSION] IEP-130: Spring Boot support

Hello Pavel, I updated the "Embedded mode” section, please take a look. In short, I propose adding the "ignite.bootstrap.nodeName" property to define the node that performs cluster initialization on startup. I look forward to receiving feedback on this approach. -- Maksim Myskov > On 22 Nov 2

Re: [DISCUSSION] IEP-130: Spring Boot support

Hi, Maksim. First of all, thanks for your efforts. I have one concern, and probably I'm over exaggerating this problem, but which Spring version we're targeting? Spring 6? What we're going to do if, let's say after couple of years, Spring 7 will appear

Re: [DISCUSSION] IEP-130: Spring Boot support

Hello Maksim, The proposal looks good in general. I think we need more details on cluster initialization mechanism - who calls init and when? What if there are multiple Spring-based embedded nodes? On Fri, Nov 22, 2024 at 1:36 PM Maksim Myskov wrote: > Hello Ignite devs, > > Please, take a loo

[DISCUSSION] IEP-130: Spring Boot support

Hello Ignite devs, Please, take a look at the proposal for Ignite3 https://cwiki.apache.org/confluence/display/IGNITE/IEP-130%3A+Spring+Boot+support -- Maksim Myskov

Re: [DISCUSSION] Location of Spring Boot support modules in Ignite 3

I prefer the "same repo" approach - a lot easier to manage. Let's keep things simple unless there is a very good reason to have a separate repo. On Wed, Nov 20, 2024 at 11:51 AM Maksim Myskov wrote: > Hi Ignite devs, > > I’d like to raise a question regarding the location of future Spring Boot >

[DISCUSSION] Location of Spring Boot support modules in Ignite 3

Hi Ignite devs, I’d like to raise a question regarding the location of future Spring Boot support modules. For Ignite 2, the approach was to have a separate extensions repository (https://github.com/apache/ignite-extensions/) where all extensions, including Spring Boot, were located. As there’s

Re: [DISCUSSION] IEP-129 Application Context

Hi Igniters, I received a few valuable comments for the IEP (thanks to Nikolay Izhikov). I worked on them and updated the IEP [1]. It now introduces some changes in API: 1. Opportunity to use non-static QuerySqlFunctions. 2. Specifying attributes to Ignite#withApplicationAttributes. 3. A

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

Ok, you have convinced me, thanks. Let's make sure to reflect the default value change in the release notes. On Tue, Nov 12, 2024 at 1:26 PM Nikita Amelchev wrote: > > Changing the default behavior to a less secure one > > My point is that both options represent security issues. > > If we want t

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

> Changing the default behavior to a less secure one My point is that both options represent security issues. If we want to migrate to a thin client, we need to allow management tasks to be executed anyway. Among them are those that can read and delete user data (cache scan/clear/destroy commands

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

Nikita, I see two issues: - Changing the default behavior to a less secure one - Mixing management tasks and user-defined tasks What about a separate client operation code for management tasks? This will provide a way to control this functionality separately, and keep the default compute behavior

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

Hi, Pavel. > Which tasks are required for control.sh? All management tasks inherit from the `VisorMultiNodeTask` class. > Should we add a special case for them instead of enabling all tasks by > default? We can do it this way, but then it is possible to execute any task in the Ignite classpath

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

I agree with the proposal in general, but this part is concerning: > Change the default parameter - ThinClientConfiguration#setMaxActiveComputeTasksPerConnection (enable tasks execution by default) This might become a security issue. As a user, I might want to disable thin client compute tasks bu

Re: [DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

+1 > On 8 Nov 2024, at 08:26, Nikita Amelchev wrote: > > Hello, Igniters. > > I propose to migrate the control.sh utility to a thin client. This > will allow us to: > > - Remove the legacy GridClient, which is used only for control.sh; > - Developers will support one thin client, instead of tw

[DISCUSSION] IEP-81 Phase 3. Use IgniteClient instead of GridClient in the control.sh utility

Hello, Igniters. I propose to migrate the control.sh utility to a thin client. This will allow us to: - Remove the legacy GridClient, which is used only for control.sh; - Developers will support one thin client, instead of two; - Simplify cluster configuration. Implementation details and migrati

[DISCUSSION] IEP-130: Ignite 3. KILL queries

Hi Igniters! Please review the proposal for Ignite-3 [1] and let me know what you think. [1] IEP-130: Ignite 3. KILL queries -- Regards, Konstantin Orlov

[DISCUSSION] IEP-129 Application Context

Hi Igniters, I'd like to propose a new feature to Ignite. It provides access to application specific data from code run on Ignite nodes - SQL, QuerySqlFunction, CacheInterceptor, CacheQuery predicates, etc. Please take a look [1], any thoughts are welcome. [1] https://cwiki.apache.org/confluence

[DISCUSSION] IEP-128: CMG and Metastorage Disaster Recovery

Hi Igniters. Another proposal [1] for Ignite 3 is ready for review, please take a look at it and share your thoughts. [1] IEP-128: CMG and Metastorage Disaster Recovery Roman Puchkovskiy

Re: [DISCUSSION] IEP-127 Catalog Service

Forgot to mention, that this proposal is for Ignite-3. On Fri, Aug 30, 2024 at 5:57 PM Konstantin Orlov wrote: > Hi Igniters! > > Please review the proposal [1] and let me know what you think. > > [1] IEP-127: Catalog Service >

[DISCUSSION] IEP-127 Catalog Service

Hi Igniters! Please review the proposal [1] and let me know what you think. [1] IEP-127: Catalog Service -- Regards, Konstantin Orlov

Re: [DISCUSSION] [IGNITE-3] IEP-126: Table/zone disaster recovery

Hello! First of all, I'd like to ask you to communicate using English, it's more convenient for everyone, thank you! Secondly, as far as I know, any member of the community can work on any issues, and the code will then be discussed and committed into a main branch, if approved by a *committer*.

Re: [DISCUSSION] [IGNITE-3] IEP-126: Table/zone disaster recovery

请问提交多少代码有希望成为apache commit呢？ jh w 于2024年8月10日周六 19:34写道： > You mean I can develop this requirement? > > > Ivan Bessonov 于2024年8月8日周四 16:23写道： > >> Hello Igniters! >> >> I prepared an IEP for Ignite 3 disaster recovery basic features and API, >> please take a look. >> >> [1] >> https://cwiki.apa

Re: [DISCUSSION] [IGNITE-3] IEP-126: Table/zone disaster recovery

You mean I can develop this requirement? Ivan Bessonov 于2024年8月8日周四 16:23写道： > Hello Igniters! > > I prepared an IEP for Ignite 3 disaster recovery basic features and API, > please take a look. > > [1] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315493878 > > -- > Sincere

[DISCUSSION] [IGNITE-3] IEP-126: Table/zone disaster recovery

Hello Igniters! I prepared an IEP for Ignite 3 disaster recovery basic features and API, please take a look. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315493878 -- Sincerely yours, Ivan Bessonov

Re: [DISCUSSION] IEP-125 Transaction aware queries

> Then I suppose the behavior you describe should be enabled/disabled by flag. Yes. This feature will change Ignite behavior. It will be enabled by the flag. > How do you plan to implement this? Sent tx state to the node performing table/index scan and combine both Btree and tx data there. > W

Re: [DISCUSSION] IEP-125 Transaction aware queries

Hi Nikolay! I have a few questions: Ignite primary use-cases are around OLTP workload which means we deal with > small and fast transactions that change coupld of entries I know at least one popular use-case of our clients. Some clients have pretty complex logic of clearing data. They use Scan

[DISCUSSION] IEP-125 Transaction aware queries

Hello, Igniters. About decade Ignite 2.x lacks of support of transactions aware queries. This IEP [1] is tend to fill this gap. Any comments are welcome. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-125+Transactions+aware+queries

Re: [DISCUSSION] IEP-124: User Object Serialization

> From the link you shared: "User object serialization must follow Java Serialization API contracts" Yes, but this is about support for classes that extend Serializable, it doesn't affect classes that don't extend anything. On Thu, Jul 11, 2024 at 7:10 PM Aleksandr Pakhomov wrote: > I see, we h

Re: [DISCUSSION] IEP-124: User Object Serialization

I see, we have to support not only Java classes but all platforms (C++, Python, C#). So we can not use the protocol from internal networking. From the link you shared: "User object serialization must follow Java Serialization API contracts" -- Best regards, Aleksandr Pakhomov > On 11 Jul 2024

Re: [DISCUSSION] IEP-124: User Object Serialization

No, I'm talking about the protocol described here: https://cwiki.apache.org/confluence/display/IGNITE/IEP-67%3A+Networking+module#IEP67:Networkingmodule-UserObjectSerialization On Thu, Jul 11, 2024 at 6:47 PM Aleksandr Pakhomov wrote: > Thanks for the question, Aleksandr. Can you clarify what do

Re: [DISCUSSION] IEP-124: User Object Serialization

Thanks for the question, Aleksandr. Can you clarify what do you mean by existing User Object Serialization protocol? Am I right assuming that you are talking about Mappers that are supported in Record and KV APIs? -- Best regards, Aleksandr Pakhomov > On 11 Jul 2024, at 18:39, Aleksandr Polovt

Re: [DISCUSSION] IEP-124: User Object Serialization

Hi, Aleksandr, thank you for the great effort! Could you please explain how this protocol differs from the existing User Object Serialization protocol? Why do we need another one? On Thu, Jul 11, 2024 at 6:20 PM Aleksandr Pakhomov wrote: > Hi, dear community. > > I would like to propose the des

[DISCUSSION] IEP-124: User Object Serialization

Hi, dear community. I would like to propose the design for supporting user objects in Ignite 3. All APIs that can accept/return custom objects that are not a part of Ignite 3 distribution are going to have additional parameter -- argument/result marshaller. I would appreciate any feedback, f

Re: [DISCUSSION] IEP-123: ORM API (Create tables from Java classes) Ignite3

Greetings, 1. Both key and value can be annotated with @Table, key will be processed first. Everything will be added to the resulting query. 2. Perhaps just need to rewrite an example to eliminate confusion. Effectively, there is no restriction on how to compose pojo, as it will be converted to a

Re: [DISCUSSION] IEP-123: ORM API (Create tables from Java classes) Ignite3

HI, I have a few questions. Assume, a user creates table via key-value annotated classes: ignite.catalog().create(PojoKey.class, PojoValue.class).execute(); 1. What is the difference between having @Table annotation on the key class or on the value class? When both classes are annotated, which on

Re: [DISCUSSION] IEP-120: MapReduce API Ignite3

Mikhail, could you please use JIRA labels to link tickets to IEPs? - Add iep-xxx label to tickets - Use "JIRA" macro in Confluence with "labels=iep-xxx" filter On Thu, May 16, 2024 at 10:43 AM Mikhail Pochatkin wrote: > Igniters, > > Please review the proposal [1] and let me know what you think

[DISCUSSION] IEP-120: MapReduce API Ignite3

Igniters, Please review the proposal [1] and let me know what you think [1] IEP-120: MapReduce API - Apache Ignite - Apache Software Foundation

[DISCUSSION] IEP-123: ORM API (Create tables from Java classes) Ignite3

Igniters, Please review the proposal [1] and let me know what you think [1] IEP-123: ORM API (Create tables from Java classes) - Apache Ignite - Apache Software Foundation

Re: [DISCUSSION] IEP-122 Thin client invoke/invokeAll cache operations

> So, we need to inform the client that the > error was caused by EntryProcessor. First option to do this: introduce > new error code, second option: use dedicated "success" flag. Thanks for the explanation. I lean towards a new error code for this. On Wed, May 8, 2024 at 9:05 AM Alex Plehanov w

Re: [DISCUSSION] IEP-122 Thin client invoke/invokeAll cache operations

Sameiksha, send email to dev-unsubscr...@ignite.apache.org if you are no longer interested in Ignite dev list messages. ср, 8 мая 2024 г. в 08:06, sameiksha kiran k : > > Can u please remove from this mail chain , this is so much unwanted mails > in my inbox from ignite Apache mails > > On Tue, Ma

Re: [DISCUSSION] IEP-122 Thin client invoke/invokeAll cache operations

Pavel, it's not about the stack trace, it's about the right exception to be thrown to the user. JCache specifies that if any exception is thrown by the EntryProcessor, this exception should be wrapped into EntryProcessorException. So, we need to inform the client that the error was caused by EntryP

Re: [DISCUSSION] IEP-122 Thin client invoke/invokeAll cache operations

Can u please remove from this mail chain , this is so much unwanted mails in my inbox from ignite Apache mails On Tue, May 7, 2024 at 10:35 PM Pavel Tupitsyn wrote: > > In case of such response we need some new > > error code to distinguish entry processor exceptions and general > client/server

Re: [DISCUSSION] IEP-122 Thin client invoke/invokeAll cache operations

> In case of such response we need some new > error code to distinguish entry processor exceptions and general client/server exceptions. I don't think we do this anywhere else (e.g. Compute). Full stack trace should be present in the server logs, or sent back to the client when sendServerException

[DISCUSSION] IEP-122 Thin client invoke/invokeAll cache operations

Hi Igniters! I've prepared a proposal about implementation of invoke/invokeAll cache operations for thin clients. All proposed changes to the protocol and client API (currently for java thin client only) are described in IEP-122 [1] Please have a look and share your thoughts. [1] https://cwiki.

Re: [DISCUSSION] IEP-121: Data Streamer with Receiver (Ignite 3)

> 1. I think that the "streamData" method has quite a lot of parameters. Can > we reduce their number by introducing a holder class, for example > "ReceiverOptions" or "ReceiverConfig"? I think that's ok. The last 3 parameters are consistent with the Compute API. > 2. Can you please elaborate on

Re: [DISCUSSION] IEP-121: Data Streamer with Receiver (Ignite 3)

Hi, Pavel, thanks for the great proposal. I have the following comments: 1. I think that the "streamData" method has quite a lot of parameters. Can we reduce their number by introducing a holder class, for example "ReceiverOptions" or "ReceiverConfig"? 2. Can you please elaborate on the "motivati

[DISCUSSION] IEP-121: Data Streamer with Receiver (Ignite 3)

Igniters, Please review the proposal [1] and let me know what you think [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-121%3A+Data+Streamer+with+Receiver

Re: [DISCUSSION] IEP-114: Custom Metrics

Vladimir, good job. LGTM. Igniters, if there are no objections, I will merge the PR soon. https://github.com/apache/ignite/pull/11223 ср, 31 янв. 2024 г. в 13:45, Anton Vinogradov : > > +1, LGTM > > On Tue, Jan 30, 2024 at 11:36 PM Nikita Amelchev > wrote: > > > Hello, Vladimir. > > > > Thanks

Re: [DISCUSSION] IEP-119 Binary infrastructure modularization

> Looks like current available counter is 119. Renamed - https://cwiki.apache.org/confluence/display/IGNITE/IEP-119+Binary+infrastructure+modularization > As I understand, all the answers are NO, and this is only a refactoring - > correct? Yes. We must not change anything from the user perspec

Re: [DISCUSSION] IEP-115 Binary infrastructure modularization

Could you please clarify: - Does this proposal affect the user in any way? - Does it introduce or remove functionality? - Does it affect compatibility? As I understand, all the answers are NO, and this is only a refactoring - correct? Let's make this clear in the IEP P.S. Separate IEP naming for

Re: [DISCUSSION] IEP-115 Binary infrastructure modularization

Mikhail, as we discussed earlier, Ignite-3 should use it's own counters since it's a different project. Better case for me is to use I3EP-XX naming. Nikolay, +1 to your proposal. On Thu, Feb 8, 2024 at 6:57 PM Mikhail Pochatkin wrote: > Hello, Nikolay. > > Thanks for your IEP. I would say that

Re: [DISCUSSION] IEP-115 Binary infrastructure modularization

Hello, Nikolay. Thanks for your IEP. I would say that IEP-115 already exists in Apache Ignite 3 section. Looks like current available counter is 119. чт, 8 февр. 2024 г., 18:27 Николай Ижиков : > Hello, Igniters. > > I want to discuss IEP-115 [1] Binary infrastructure modularization > Two main

[DISCUSSION] IEP-115 Binary infrastructure modularization

Hello, Igniters. I want to discuss IEP-115 [1] Binary infrastructure modularization Two main goal of IEP: - remove coupling between specific marshaller(BinaryMarshaller) and Ignite core code. - simplify Binary code improvements. - clear SerDes abstraction in core code. As a result of this IEP w

Re: [DISCUSSION] IEP-114: Custom Metrics

+1, LGTM On Tue, Jan 30, 2024 at 11:36 PM Nikita Amelchev wrote: > Hello, Vladimir. > > Thanks for the IEP. I have reviewed the proposal, good plan. Let's > implement this. > > ср, 17 янв. 2024 г. в 18:48, Vladimir Steshin : > > > > Hi, Igniters! I'd like to propose a new feature - Custom Metric

Re: [DISCUSSION] IEP-114: Custom Metrics

Hello, Vladimir. Thanks for the IEP. I have reviewed the proposal, good plan. Let's implement this. ср, 17 янв. 2024 г. в 18:48, Vladimir Steshin : > > Hi, Igniters! I'd like to propose a new feature - Custom Metrics. This > would allow a user to register his own measurement and monitoring values

[DISCUSSION] IEP-114: Custom Metrics

Hi, Igniters! I'd like to propose a new feature - Custom Metrics. This would allow a user to register his own measurement and monitoring values. Short IEP description: 1. Custom metrics are convenient to gather different application metrics using the same client/platform/API. Or when the existin

[DISCUSSION] IEP-117: Pluggable Storage Support (Apache Ignite 3)

Igniters, please, take a look at IEP-117: Pluggable Storages Support [1] which is a proposal for Apache Ignite 3. The main idea is to have the possibility to support various storages for different tables in order to provide the best suitable storage engine for a user's data. 1. https://cwiki.ap

[DISCUSSION] IEP-116: Metrics (Apache Ignite 3)

Igniters, please, take a look at IEP-116: Metrics [1] which is a proposal for Apache Ignite 3. While we already implement metrics in the proposed way any comments are still welcome. 1. https://cwiki.apache.org/confluence/display/IGNITE/IEP-116%3A+Metrics

[DISCUSSION] IEP-115: Criteria API queries in Apache Ignite 3

Hi, Igniters, Please take a look at the proposal for Criteria API queries in Apache Ignite 3 [1] Thanks for any feedback! 1. https://cwiki.apache.org/confluence/display/IGNITE/IEP-115%3A+Ignite+3.+Criteria+API+queries

Re: [DISCUSSION] IEP-112: Ignite 3. Criteria API queries

Hi Roman. Nice catch. It was my fault. I will fix and resend email with correct number of IEP On Wed, Nov 15, 2023 at 7:17 PM Roman Puchkovskiy wrote: > > Hi Andrey. I believe IEP-112 is already taken, please consult > https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals > The lowe

Re: [DISCUSSION] IEP-112: Ignite 3. Criteria API queries

Hi Andrey. I believe IEP-112 is already taken, please consult https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals The lowest free number is 115. ср, 15 нояб. 2023 г. в 16:12, Andrey Novikov : > > Hi all, > > Please review "IEP-112: Ignite 3. Criteria API queries” proposal. > The ma

[DISCUSSION] IEP-112: Ignite 3. Criteria API queries

Hi all, Please review "IEP-112: Ignite 3. Criteria API queries” proposal. The main purpose of this document is to describe criteria API queries from the user's point of view. https://cwiki.apache.org/confluence/display/IGNITE/IEP-112%3A+Ignite+3.+Criteria+API+querie s

Re: [DISCUSSION] Service awareness for thin client.

Sure: IEP : https://cwiki.apache.org/confluence/display/IGNITE/IEP-112+Thin+Client+Service+Awareness Ticket: https://issues.apache.org/jira/browse/IGNITE-20656 On 26.10.2023 18:15, Pavel Tupitsyn wrote: Vladimir, could you please share the new IEP link here, and also link it to the tick

Re: [DISCUSSION] Service awareness for thin client.

Vladimir, could you please share the new IEP link here, and also link it to the ticket? On Thu, Oct 26, 2023 at 1:30 PM Vladimir Steshin wrote: > Roman, hi. > > Done. Thanks! > > On 26.10.2023 13:25, Roman Puchkovskiy wrote: > > Hi Vladimir. Sorry to intervene, but we have a clash with IEP

Re: [DISCUSSION] Service awareness for thin client.

    Roman, hi. Done. Thanks! On 26.10.2023 13:25, Roman Puchkovskiy wrote: Hi Vladimir. Sorry to intervene, but we have a clash with IEP numbers, there is already IEP-110 in Ignite 3, it was created on August, 1: https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronizati

Re: [DISCUSSION] Service awareness for thin client.

Hi Vladimir. Sorry to intervene, but we have a clash with IEP numbers, there is already IEP-110 in Ignite 3, it was created on August, 1: https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes Is it possible to pick another number, while your I

Re: [DISCUSSION] Service awareness for thin client.

    All right. Pavel, thank you. IEP: https://cwiki.apache.org/confluence/display/IGNITE/IEP-110+Thin+Client+Service+Awareness Ticket: https://issues.apache.org/jira/browse/IGNITE-20656 On 25.10.2023 11:04, Pavel Tupitsyn wrote: Looks good to me On Tue, Oct 24, 2023 at 1:50 PM Vladimir Stes

Re: [DISCUSSION] Service awareness for thin client.

Looks good to me On Tue, Oct 24, 2023 at 1:50 PM Vladimir Steshin wrote: > We've privately discussed with Mikhail Petrov and Alexey Plekhanov. > To us, #2 seems OK with the exceptions that a dedicated request would be > better for transferring the service topology. And it should be processe

Re: [DISCUSSION] Service awareness for thin client.

    We've privately discussed with Mikhail Petrov and Alexey Plekhanov. To us, #2 seems OK with the exceptions that a dedicated request would be better for transferring the service topology. And it should be processed by the client instead of every service proxy. So, the suggested solution is:

Re: [DISCUSSION] Service awareness for thin client.

    They barely can guarantee. If client miss service instance node, the request is just redirected. But I talk about the most reliable way to keep actual service topology. If we watch cluster topology change event, we have to take in account cases like: - Client request service, gets its topo

Re: [DISCUSSION] Service awareness for thin client.

None of the described approaches provides 100% guarantee of hitting the primary node in all conditions. And it is fine to miss a few requests. I don't see a reason to increase complexity trying to optimize a rare use case. On Tue, Oct 17, 2023 at 2:49 PM wrote: > What if topology change event pr

Re: [DISCUSSION] Service awareness for thin client.

What if topology change event preceedes service redeployment and service mapping change? There a possibility for client to save new topology version before services are actually redeployed. If we rely on actual change of the service mapping (redeployment), there is no such problem. On 17.10.20

Re: [DISCUSSION] Service awareness for thin client.

I think if it's good enough for cache partition awareness, then it's good enough for services. Topology changes are not that frequent. On Tue, Oct 17, 2023 at 12:22 PM wrote: > Hi, Pavel. > > 1. Correct. > 2. Yes, client watches ClientFlag.AFFINITY_TOPOLOGY_CHANGED flag and sends > additional Cl

[DISCUSSION] IEP-111: Ignite 3. Basic Multi-Statement Support

Hi all, Please review "IEP-111: Ignite 3. Basic Multi-Statement Support” proposal. The main purpose of this document is to state behavior of script processing from the user's point of view. https://cwiki.apache.org/confluence/display/IGNITE/IEP-111%3A+Ignite+3.+Basic+Multi-Statement+Support

Re: [DISCUSSION] Service awareness for thin client.

Hi, Pavel. 1. Correct. 2. Yes, client watches ClientFlag.AFFINITY_TOPOLOGY_CHANGED flag and sends additional ClientOperation.CLUSTER_GROUP_GET_NODE_ENDPOINTS to get new cluster topology. Thus, the topology updates with some delay. We could watch this event somehow in the service proxy. But dir

Re: [DISCUSSION] Service awareness for thin client.

Hi Vladimir, 1. A topology of a deployed service can change only when the cluster topology changes. 2. We already have a topology change flag in every server response. Therefore, the client can request the topology once per service, and refresh it when cluster topology changes, right? On Mon, O

[DISCUSSION] Service awareness for thin client.

Hi Igniters! I propose to add the /service awareness feature to the thin client/. I remember a couple of users asked of it. Looks nice to have and simple to implement. Similar to the partition awareness. Reason: A service can be deployed only on one or few nodes. Currently, the thin client choo

Re: [DISCUSSION] IEP-110: Schema synchronization: basic schema changes

Hi Andrey. Thanks for noting this, I've added the implementation tickets. чт, 27 июл. 2023 г. в 17:35, Andrey Gura : > > Hi, Roman. > > Thanks for IEP. Could you please also add tickets to the corresponding > section (see otghert IEP's for example). > > On Mon, Jul 24, 2023 at 9:28 AM Roman Puchk

Re: [DISCUSSION] IEP-110: Schema synchronization: basic schema changes

Hi, Roman. Thanks for IEP. Could you please also add tickets to the corresponding section (see otghert IEP's for example). On Mon, Jul 24, 2023 at 9:28 AM Roman Puchkovskiy wrote: > > Hi Igniters! > > Please take a look at a proposal about the application of the Schema > Synchronization framewor

[DISCUSSION] IEP-110: Schema synchronization: basic schema changes

Hi Igniters! Please take a look at a proposal about the application of the Schema Synchronization framework to basic schema change types in Ignite 3 [1]. 1. https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes

Re: [DISCUSSION] IEP-103: Code Deployment in Apache Ignite 3

One more change to the original IEP. The "Dependency resolving and class loading" section [1] proposes to throw an instance of ClassNotFoundException for cases where a deployment unit is not found or can't be used. The same exception should be thrown in cases where a class loader is not able to loa

  1   2   3   4   5   6   7   8   9   10   >