Access to wiki to write a IEP draft
Hello Igniters, I would like to prepare the IEP for some improved loading testing framework for Ignite. Would you please give me a write access to https://cwiki.apache.org/confluence Thanks, -- Sergey Korotkov
Re: Access to wiki to write a IEP draft
Hello, please, provide you Jira ID. > 8 июля 2022 г., в 12:18, Sergey Korotkov > написал(а): > > Hello Igniters, > > I would like to prepare the IEP for some improved loading testing framework > for Ignite. > > Would you please give me a write access to https://cwiki.apache.org/confluence > > Thanks, > > -- > >Sergey Korotkov >
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
Hello, Pavel. I support your proposal to transparently create custom AffinityMapper based on server node classname, in general. Partition Awareness crucial point for a thin client performance so It should be absolutely clear for a user - PA works correctly or not. So, I think, we should implement the following: 0. Add ability to sent custom affinity class name. 1. If `partitionAwarenessEnabled=true` but custom affinity can’t be instantiated on the client - throw an exception. WDYT? > 8 июля 2022 г., в 08:37, Pavel Tupitsyn написал(а): > > To clarify: you can use a different AffinityFunction implementation on the > client side. It just has to map to the same binary typeId. > Even if there is a legacy setup with AffinityKeyMapper on servers, you can > craft an AffinityFunction for the client that achieves correct behavior. > So I believe this should cover any use case. > > On Thu, Jul 7, 2022 at 10:36 PM Pavel Tupitsyn wrote: > >> AffinityKeyMapper is just a subset of AffinityFunction, isn't it? >> So by supporting AffinityFunction we cover all AffinityKeyMapper use cases. >> >> >>> managing the classpath, a user should always keep in mind it >> I don't consider this a problem. This is how Java works, what can we do? >> You can also stick the class into BinaryConfiguration on the client to >> make it explicit and make sure it is loaded. >> >>> it still possible having user bad implementations of AffinityFunction >> that can't be easily instantiated; >> It is also possible to provide a bad implementation of ToIntFunction, no >> difference. >> >>> a question - what we should do in case of class instantiating loading >> fails? >> Currently we don't fail on custom affinity, right? So we should keep this >> behavior. Print a warning. >> >> On Thu, Jul 7, 2022 at 10:27 PM Maxim Muzafarov wrote: >> >>> Pavel, >>> >>> >>> Yes, you're right that AffinityKeyMapper is deprecated, this is sad to >>> say but it still used. >>> >>> Let me describe the cases in more detail. In general, we have >>> customers which are using: >>> >>> 1. an own custom AffinityFunction; >>> 2. the default RendezvousAffinityFunction + an own deprecated >>> AffinityKeyMapper; >>> 3. an own custom AffinityFunction + an own deprecated >>> AffinityKeyMapper (I doubt about this case); >>> >>> I'd like to provide a general solution that solves all the cases >>> mentioned above, thus we can't discuss only AffinityFunction. It >>> doesn't fit the initial goals. >>> >>> Can you please clarify the "tricky" part? >>> >>> Yes, from my point of view the tricky part here is: >>> >>> - managing the classpath, a user should always keep in mind it; >>> - it still possible having user bad implementations of >>> AffinityFunction that can't be easily instantiated; >>> - a question - what we should do in case of class instantiating >>> loading fails? drop the client, print the warn or do nothing. These >>> solutions have a different impact on a production environment and user >>> may have different expectations on that; >>> >>> >>> I'm not saying that solution you suggested is bad, it just has some >>> drawbacks (like other solutions) and doesn't solves all the cases if >>> we're not instantiating a deprecated AffinityKeyMapper (which looks a >>> bit ugly for me too). >>> >>> >>> Actually, we are not limited with setting/instantiating >>> AffinityFunction. We can provide for a user a control on which channel >>> (node) a particular cache request will be executed (this thing also >>> have a drawback - a transactional operation cannot be executed on an >>> arbitrary node, it should be executed on node it's started). >>> >>> On Thu, 7 Jul 2022 at 21:41, Pavel Tupitsyn wrote: > AffinityKeyMapper (it will be required too) It is deprecated. We should not add any functionality on top of >>> deprecated stuff. Let's discuss only AffinityFunction. > this approach requires of these classes to be present on a thin client side and it can be tricky Any of the approaches discussed above requires some additional logic to >>> be present on the client. Can you please clarify the "tricky" part? All you need is to provide AffinityFunction implementation with a proper class name (or even use nameMapper/idMapper to map to a different name), it is no different from the ToIntFunction approach. On Thu, Jul 7, 2022 at 9:23 PM Maxim Muzafarov >>> wrote: > Folks, > > I'd like also to mention since we are talking about a customer's > custom affinity function and affinity mapper implementations we could > face with some issues during these classes instantiation. It could > work for the customer which I've faced on, but I cannoun be sure that > this approach will work for all of the cases. > > I think it is better to avoid such an issues and leave it up to a > user. Nevertheless, the worst scenario for the user
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
Nikolay, > Add ability to sent custom affinity class name. Can you please elaborate? What is sent where? > If `partitionAwarenessEnabled=true` but custom affinity can’t be instantiated on the client - throw an exception Unfortunately, this is a breaking change. Currently this scenario works without errors - uses default socket for custom affinity caches. On Fri, Jul 8, 2022 at 3:23 PM Николай Ижиков wrote: > Hello, Pavel. > > I support your proposal to transparently create custom AffinityMapper > based on server node classname, in general. > Partition Awareness crucial point for a thin client performance so It > should be absolutely clear for a user - PA works correctly or not. > > So, I think, we should implement the following: > > 0. Add ability to sent custom affinity class name. > 1. If `partitionAwarenessEnabled=true` but custom affinity can’t be > instantiated on the client - throw an exception. > > WDYT? > > > 8 июля 2022 г., в 08:37, Pavel Tupitsyn > написал(а): > > > > To clarify: you can use a different AffinityFunction implementation on > the > > client side. It just has to map to the same binary typeId. > > Even if there is a legacy setup with AffinityKeyMapper on servers, you > can > > craft an AffinityFunction for the client that achieves correct behavior. > > So I believe this should cover any use case. > > > > On Thu, Jul 7, 2022 at 10:36 PM Pavel Tupitsyn > wrote: > > > >> AffinityKeyMapper is just a subset of AffinityFunction, isn't it? > >> So by supporting AffinityFunction we cover all AffinityKeyMapper use > cases. > >> > >> > >>> managing the classpath, a user should always keep in mind it > >> I don't consider this a problem. This is how Java works, what can we do? > >> You can also stick the class into BinaryConfiguration on the client to > >> make it explicit and make sure it is loaded. > >> > >>> it still possible having user bad implementations of AffinityFunction > >> that can't be easily instantiated; > >> It is also possible to provide a bad implementation of ToIntFunction, no > >> difference. > >> > >>> a question - what we should do in case of class instantiating loading > >> fails? > >> Currently we don't fail on custom affinity, right? So we should keep > this > >> behavior. Print a warning. > >> > >> On Thu, Jul 7, 2022 at 10:27 PM Maxim Muzafarov > wrote: > >> > >>> Pavel, > >>> > >>> > >>> Yes, you're right that AffinityKeyMapper is deprecated, this is sad to > >>> say but it still used. > >>> > >>> Let me describe the cases in more detail. In general, we have > >>> customers which are using: > >>> > >>> 1. an own custom AffinityFunction; > >>> 2. the default RendezvousAffinityFunction + an own deprecated > >>> AffinityKeyMapper; > >>> 3. an own custom AffinityFunction + an own deprecated > >>> AffinityKeyMapper (I doubt about this case); > >>> > >>> I'd like to provide a general solution that solves all the cases > >>> mentioned above, thus we can't discuss only AffinityFunction. It > >>> doesn't fit the initial goals. > >>> > >>> > Can you please clarify the "tricky" part? > >>> > >>> Yes, from my point of view the tricky part here is: > >>> > >>> - managing the classpath, a user should always keep in mind it; > >>> - it still possible having user bad implementations of > >>> AffinityFunction that can't be easily instantiated; > >>> - a question - what we should do in case of class instantiating > >>> loading fails? drop the client, print the warn or do nothing. These > >>> solutions have a different impact on a production environment and user > >>> may have different expectations on that; > >>> > >>> > >>> I'm not saying that solution you suggested is bad, it just has some > >>> drawbacks (like other solutions) and doesn't solves all the cases if > >>> we're not instantiating a deprecated AffinityKeyMapper (which looks a > >>> bit ugly for me too). > >>> > >>> > >>> Actually, we are not limited with setting/instantiating > >>> AffinityFunction. We can provide for a user a control on which channel > >>> (node) a particular cache request will be executed (this thing also > >>> have a drawback - a transactional operation cannot be executed on an > >>> arbitrary node, it should be executed on node it's started). > >>> > >>> On Thu, 7 Jul 2022 at 21:41, Pavel Tupitsyn > wrote: > > > AffinityKeyMapper (it will be required too) > It is deprecated. We should not add any functionality on top of > >>> deprecated > stuff. > Let's discuss only AffinityFunction. > > > this approach requires of these classes to be present on a thin > client > side and it can be tricky > Any of the approaches discussed above requires some additional logic > to > >>> be > present on the client. > Can you please clarify the "tricky" part? > > All you need is to provide AffinityFunction implementation with a > proper > class name > (or even use nameMapper/idMapper to map to a different name), it is no > differ
[MTCGA]: new failures in builds [6512000] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New test failure in master CacheContinuousQueryBufferLimitTest.testContinuousQueryBatchSwitchOnAck[cacheMode=REPLICATED, atomicityMode=TRANSACTIONAL] https://ci2.ignite.apache.org/test/-1135395322370377756?currentProjectId=IgniteTests24Java8&branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 06:23:20 09-07-2022
