[MTCGA]: new failures in builds [6515126] 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 IgniteLogicalRecoveryTest.testRecoveryWithMvccCaches https://ci2.ignite.apache.org/test/-9058612810595483215?currentProjectId=IgniteTests24Java8=%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 02:53:22 11-07-2022
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
> providing simple function Object -> int32 in cache configuration is wrong decision Because it is error-prone and does not work for all cases: - You have to set it explicitly on the client for every cache. - No way to do that if you get an existing cache by name. > still being unable to solve the problem I believe the proposed solution covers all use cases. > cryptic logic It is not cryptic, it is very straightforward and builds on existing binary type mechanism. > feature flags What's bad about feature flags? > how an ability to obtain a classname of java class can help my python or C++ client map key to partition Not a java class name, but type id. You can set up type id mapping properly and use this in any thin client. This will work for .NET client, not sure about Python and C++. On Sun, Jul 10, 2022 at 9:33 PM Ivan Daschinsky wrote: > Guys, I simply cant understand why providing simple function Object -> > int32 in cache configuration is wrong decision, but implementing cryptic > logic with class names, feature flags and still being unable to solve the > probem is ok. I don't understand how an ability to obtain a classname of > java class can help my python or C++ client map key to partition. > > Max's proposal seems to be a good variant, just change naming a little bit, > maybe > > пт, 8 июл. 2022 г., 15:35 Pavel Tupitsyn : > > > 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
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
Guys, I simply cant understand why providing simple function Object -> int32 in cache configuration is wrong decision, but implementing cryptic logic with class names, feature flags and still being unable to solve the probem is ok. I don't understand how an ability to obtain a classname of java class can help my python or C++ client map key to partition. Max's proposal seems to be a good variant, just change naming a little bit, maybe пт, 8 июл. 2022 г., 15:35 Pavel Tupitsyn : > 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,
