Thanks, Michael! Congrats :)
> 10 сент. 2020 г., в 19:17, Michael Pollind <mpoll...@gmail.com> написал(а): > > With some help from @Denis Magda <dma...@gridgain.com>, we were able to > rework micronaut-ignite and a release candidate was approved. I'm pretty > happy with this first pass and there is a lot more that can be added but > this is a good initial first step. > > documentation can be bound here: > https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/ > PR: https://github.com/micronaut-projects/micronaut-ignite/pull/33 > > On Thu, Aug 27, 2020 at 5:32 PM Michael Pollind <mpoll...@gmail.com> wrote: > >> Not sure, I would probably bring that up in the PR so the micronaut devs >> are aware of this. Not sure how the CI will work and what can be arranged >> in this case. >> >> On Thu, Aug 27, 2020 at 3:50 PM Denis Magda <dma...@apache.org> wrote: >> >>> Michael, >>> >>> The docs look good enough for the release. Once the integration is >>> released, I'll update and extend my Micronaut tutorial elucidating on how >>> to use the integration in practice for various use cases. >>> >>> Btw, are the ignite-core and ignite-cache Maven artifacts will be released >>> for a specific version of Ignite? Ideally, the version of Ignite needs to >>> be set in a pom.xml and the Micronaut integration should pick them up. >>> >>> Also, what are we doing next - reviewing APIs of the ignite-cache module >>> or >>> going through a review process of the ignite-core and merging it first to >>> the Micronaut repository? >>> >>> - >>> Denis >>> >>> >>> On Wed, Aug 26, 2020 at 3:35 PM Michael Pollind <mpoll...@gmail.com> >>> wrote: >>> >>>> Also you need to sign the CLA since you add a commit to my branch. >>>> >>>> branch: https://github.com/pollend/micronaut-ignite/tree/feature/rework >>>> linked PR: >>> https://github.com/micronaut-projects/micronaut-ignite/pull/33 >>>> >>>> -- >>>> Michael Pollind >>>> >>>> On Wed, Aug 26, 2020 at 3:29 PM Denis Magda <dma...@apache.org> wrote: >>>> >>>>> Could you share the full path to the branch? Don't want to pick a >>> wrong >>>> one >>>>> accidentally. >>>>> >>>>> >>>>> - >>>>> Denis >>>>> >>>>> >>>>> On Wed, Aug 26, 2020 at 2:47 PM Michael Pollind <mpoll...@gmail.com> >>>>> wrote: >>>>> >>>>>> so that clears up the extra flag for micronaut-cache. just need to >>>>>> intercept the default IgniteConfiguration bean and update the >>>>>> configuration. if you pull my latest changes from the rework branch >>> you >>>>> can >>>>>> look at the docs for that micronaut module. `./gradlew docs`. >>>> Finalizing >>>>>> the docs should be the last part of this. The configuration from my >>>>>> perspective seems pretty much there. Is there anything else that is >>>>>> missing? >>>>>> >>>>>> On Wed, Aug 26, 2020 at 1:31 PM Denis Magda <dma...@apache.org> >>> wrote: >>>>>> >>>>>>> 👍 Nice catch! >>>>>>> >>>>>>> - >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 26, 2020 at 12:16 PM Michael Pollind < >>> mpoll...@gmail.com >>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> One thing that just occurred to me for the >>>>> DefaultIgniteConfiguration. >>>>>>> you >>>>>>>> can actually just intercept the bean when it's created. This >>> should >>>>> let >>>>>>> us >>>>>>>> use the enable flag from ignite-core for ignite-cache without >>> the >>>>>>>> additional flag. >>>>>>>> >>>>>>>> @Singleton >>>>>>>> public class IgniteConfigurationFactoryInterceptor implements >>>>>>>> BeanCreatedEventListener<DefaultIgniteConfiguration> { >>>>>>>> @Override >>>>>>>> public IgniteConfiguration >>>>>>>> onCreated(BeanCreatedEvent<DefaultIgniteConfiguration> event) { >>>>>>>> IgniteConfiguration configuration = event.getBean(); >>>>>>>> configuration.setIgniteInstanceName("instance-a"); >>>>>>>> return configuration; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 26, 2020 at 11:31 AM Denis Magda <dma...@apache.org >>>> >>>>>> wrote: >>>>>>>> >>>>>>>>> Michael, >>>>>>>>> >>>>>>>>> Looks terrific! I went ahead and grouped the configuration >>>> samples >>>>>> by a >>>>>>>>> client type: >>>>>>>>> >>>>>>> >>>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration >>>>>>>>> >>>>>>>>> As you see, the "Ignite Thin Client" section is blank for now. >>>>> Would >>>>>>> you >>>>>>>>> mind filling it with configuration options following the >>> format >>>>> taken >>>>>>> for >>>>>>>>> the thick client? >>>>>>>>> >>>>>>>>> Ping me here once you're ready to review the API and >>>> implementation >>>>>> of >>>>>>>> the >>>>>>>>> ignite-caching module. >>>>>>>>> >>>>>>>>> - >>>>>>>>> Denis >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Aug 25, 2020 at 9:16 PM Michael Pollind < >>>>> mpoll...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Here is a sample project I threw together and I've also >>> updated >>>>> the >>>>>>>> wiki >>>>>>>>>> just a bit. working on updating the documentation on the >>>>> micronaut >>>>>>> end. >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration >>>>>>>>>> https://github.com/pollend/micronaut-ignite-sample >>>>>>>>>> >>>>>>>>>> On Mon, Aug 24, 2020 at 6:57 PM Michael Pollind < >>>>>> mpoll...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> yea, I'm not sure about ignite-cache config. splitting it >>>> into >>>>>> two >>>>>>>>>> modules >>>>>>>>>>> seems kind of overly complicated, but I also don't really >>>> like >>>>>> the >>>>>>>>> random >>>>>>>>>>> boolean flag. here is the tweaks from the config your >>>> provider: >>>>>>>>>>> https://github.com/pollend/micronaut-ignite/pull/2 >>>>>>>>>>> >>>>>>>>>>> kind of strange that there are not getters for the >>>>>>>>>>> TcpDiscoveryKubernetesIpFinder but there is enough to >>> verify >>>>> that >>>>>>> the >>>>>>>>>>> correct ipfinder was set from the unit test i've written. >>>>>>>>>>> >>>>>>>>>>> static ip finder >>>>>>>>>>> >>>>>>>>>>> "ignite.enabled" : >>> true, >>>>>>>>>>> "ignite.communication-spi.local-port" : >>>>>>>> "localhost:1800", >>>>>>>>>>> "ignite.discovery-spi.static-ip-finder.enabled" : >>> "true", >>>>>>>>>>> "ignite.discovery-spi.static-ip-finder.addresses[0]": " >>>>>>>> 127.0.0.1:47500 >>>>>>>>> ", >>>>>>>>>>> "ignite.discovery-spi.static-ip-finder.addresses[1]": " >>>>>>>> 127.0.0.1:47501 >>>>>>>>> ", >>>>>>>>>>> >>>>>>>>>>> kubernetties ip finder >>>>>>>>>>> >>>>>>>>>>> "ignite.enabled" : >>> true, >>>>>>>>>>> "ignite.communication-spi.local-port" : >>>>>>>>> "localhost:1800", >>>>>>>>>>> "ignite.discovery-spi.kubernetes-ip-finder.enabled" : >>>> "true", >>>>>>>>>>> "ignite.discovery-spi.kubernetes-ip-finder.namespace": >>>>>> "HelloWorld" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Aug 24, 2020 at 6:16 PM Denis Magda < >>>> dma...@apache.org >>>>>> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Michael, >>>>>>>>>>>> >>>>>>>>>>>> I was thinking over the idea of splitting the >>> ignite-cache >>>>>> module >>>>>>> in >>>>>>>>> two >>>>>>>>>>>> (one for a thick-client based connection and the other >>> for >>>>> thin >>>>>>>> client >>>>>>>>>>>> connections), and would try to avoid this route if >>> possible. >>>>>>>>>>>> >>>>>>>>>>>> With the @CacheConfig annotation, Micronaut developers >>> can >>>>>> create >>>>>>> a >>>>>>>>>>>> generic >>>>>>>>>>>> implementation that is agnostic to the Ignite >>> connectivity >>>>>>> methods, >>>>>>>>>> which >>>>>>>>>>>> is good. While internally, the ignite-cache >>> implementation >>>> can >>>>>>>> decide >>>>>>>>>> what >>>>>>>>>>>> Ignite Cache API to use (the thick or thin client one, >>>> depends >>>>>> on >>>>>>>> the >>>>>>>>>> type >>>>>>>>>>>> of a client you started with our auto-configuration >>>> feature). >>>>>>> Let’s >>>>>>>>>>>> discuss >>>>>>>>>>>> all the existing issues here and jump on another call to >>>>>> finalize >>>>>>> a >>>>>>>>>>>> solution if needed. >>>>>>>>>>>> >>>>>>>>>>>> Denis >>>>>>>>>>>> >>>>>>>>>>>> On Monday, August 24, 2020, Denis Magda < >>> dma...@apache.org> >>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Michael, >>>>>>>>>>>>> >>>>>>>>>>>>> Great progress, thanks for your patience. I went ahead >>> and >>>>>>> pushed >>>>>>>>> some >>>>>>>>>>>>> changes to your working branch. As you'll see, those >>>> changes >>>>>> do >>>>>>>> some >>>>>>>>>>>> minor >>>>>>>>>>>>> tweaks in the DefaultIgniteThinClientConfiguration >>> class >>>> and >>>>>> add >>>>>>>>>> Static >>>>>>>>>>>>> with Kubernetes IP finders to the >>>> DefaultIgniteConfiguration >>>>>>>> class. >>>>>>>>>> The >>>>>>>>>>>>> IgniteConfigurationSpec fails for now, but I think >>> we'll >>>>>> figure >>>>>>>> how >>>>>>>>> to >>>>>>>>>>>>> modify the test on the call today. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, let's decide if we want to configure IgniteCaches >>>> via >>>>>> the >>>>>>>>>>>> Micronaut >>>>>>>>>>>>> configuration. If an application needs to create any >>>> caches, >>>>>> it >>>>>>>> can >>>>>>>>> do >>>>>>>>>>>> this >>>>>>>>>>>>> dynamically after an Ignite instance is started. >>>>>>>>>>>>> >>>>>>>>>>>>> - >>>>>>>>>>>>> Denis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Aug 22, 2020 at 1:15 PM Michael Pollind < >>>>>>>> mpoll...@gmail.com >>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> The way i've gone about providing dependencies is that >>>> these >>>>>> can >>>>>>>> be >>>>>>>>>>>>> provided through a factory. >>>>>>>>>>>>> >>>>>>>>>>>>> @Bean >>>>>>>>>>>>> @Named("default") >>>>>>>>>>>>> @Primary >>>>>>>>>>>>> public IgniteConfiguration >>>>>>>>>>>> igniteConfiguration(DefaultIgniteConfiguration >>>> configuration, >>>>>>>>>>>>> >>>>>>>>>>>> Collection<DefaultCacheConfiguration> >>> cacheConfigurations, >>>>>>>>>>>>> >>>>>>>>>>>> Collection<PluginProvider> providers, >>>>>>>>>>>>> >>>>>>>>>>>> Collection<DefaultExecutorConfiguration> >>>>> executorConfigurations, >>>>>>>>>>>>> >>>>>>>>>>>> Optional<PlatformConfiguration> platformConfigurations, >>>>>>>>>>>>> >>>>>>>>> Optional<CollisionSpi> >>>>>>>>>>>> collisionSpi, >>>>>>>>>>>>> >>>>>>>>>>>> Collection<LoadBalancingSpi> loadBalancingSpis, >>>>>>>>>>>>> >>>>>>>>> Collection<FailoverSpi> >>>>>>>>>>>> failoverSpis, >>>>>>>>>>>>> >>>>> @ConsistencyId >>>>>>>>>>>> Optional<Serializable> consistencyId, >>>>>>>>>>>>> >>>>>> @IgniteLifecycle >>>>>>>>>>>> Collection<LifecycleBean> lifecycleBeans) { >>>>>>>>>>>>> >>>>>>>>>> >>>>>> configuration.setCacheConfiguration(cacheConfigurations.toArray(new >>>>>>>>>>>> CacheConfiguration[0])) >>>>>>>>>>>>> .setPluginProviders(providers.toArray(new >>>>>>>>> PluginProvider[0])) >>>>>>>>>>>>> >>>>>>>> .setExecutorConfiguration(executorConfigurations.toArray(new >>>>>>>>>>>> ExecutorConfiguration[0])) >>>>>>>>>>>>> >>>>>>>>> >>> .setPlatformConfiguration(platformConfigurations.orElse(null)) >>>>>>>>>>>>> .setFailoverSpi(failoverSpis.toArray(new >>>>>>> FailoverSpi[0])) >>>>>>>>>>>>> >>> .setLoadBalancingSpi(loadBalancingSpis.toArray(new >>>>>>>>>>>> LoadBalancingSpi[0])) >>>>>>>>>>>>> .setConsistentId(consistencyId.orElse(null)) >>>>>>>>>>>>> .setLifecycleBeans(lifecycleBeans.toArray(new >>>>>>>>>> LifecycleBean[0])) >>>>>>>>>>>>> .setCollisionSpi(collisionSpi.orElse(null)); >>>>>>>>>>>>> return configuration; >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind < >>>>>>>> mpoll...@gmail.com >>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> here is an updated example what the yaml looks like >>> now. >>>>>>>>>>>>> >>>>>>>>>>>>> ignite: >>>>>>>>>>>>> enabled: true >>>>>>>>>>>>> comunication-spi: >>>>>>>>>>>>> local-port: 5555 >>>>>>>>>>>>> cache-configurations: >>>>>>>>>>>>> - accounts: >>>>>>>>>>>>> table-name: ACCOUNTS >>>>>>>>>>>>> key-type: String >>>>>>>>>>>>> - books: >>>>>>>>>>>>> table-name: BOOKS >>>>>>>>>>>>> key-type: String >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind < >>>>>>>>> mpoll...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> micronaut will only inject into a nested object if its >>>>> static >>>>>>> and >>>>>>>>>> nested >>>>>>>>>>>>> in a class. Its a separate final class so it will not >>> work >>>>> in >>>>>>> this >>>>>>>>>>>> case. So >>>>>>>>>>>>> DataRegionConfiguration will not get set from the >>>>> environment. >>>>>>>> This >>>>>>>>>> is a >>>>>>>>>>>>> working example but this can be adjusted. I guess it >>>> would >>>>>> have >>>>>>>> to >>>>>>>>> be >>>>>>>>>>>>> setup like DefaultIgniteConfiguration. >>>>>>>>> DefaultDataStorageConfiguration >>>>>>>>>>>>> and a nested EachProperty? Lets try have a minimum >>> working >>>>>> setup >>>>>>>> and >>>>>>>>>>>> then >>>>>>>>>>>>> add in the missing configurations as we go? >>>>>>>>>>>>> >>>>>>>>>>>>> @ConfigurationBuilder(value = >>> "dataStorageConfiguration", >>>>>>>> excludes = >>>>>>>>>>>> "dataRegionConfigurations") >>>>>>>>>>>>> final DataStorageConfiguration >>> dataStorageConfiguration = >>>>> new >>>>>>>>>>>> DataStorageConfiguration(); >>>>>>>>>>>>> >>>>>>>>>>>>> @EachProperty("dataRegionConfigurations") >>>>>>>>>>>>> public static class DefaultDataRegionConfiguration { >>>>>>>>>>>>> @ConfigurationBuilder() >>>>>>>>>>>>> DataRegionConfiguration dataRegionConfiguration = >>> new >>>>>>>>>>>> DataRegionConfiguration(); >>>>>>>>>>>>> >>>>>>>>>>>>> public DataRegionConfiguration >>>>>> getDataRegionConfiguration() >>>>>>> { >>>>>>>>>>>>> return dataRegionConfiguration; >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind < >>>>>>>> mpoll...@gmail.com >>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Dennis, >>>>>>>>>>>>> >>>>>>>>>>>>> oh, so I made those adjustments. I must have missed it >>>>> because >>>>>>>> that >>>>>>>>>>>> didn't >>>>>>>>>>>>> occur to me. So DefaultIgniteConfiguration is fine, but >>>>>>>>>>>> ClientConfiguration >>>>>>>>>>>>> is a final class so that can't be extended from. This >>> PR >>>> is >>>>>>>> starting >>>>>>>>>> to >>>>>>>>>>>>> shape up from my perspective, I just need to update the >>>>>>>>> documentation. >>>>>>>>>>>> The >>>>>>>>>>>>> other thing I did was add a flag for the associated >>> cache >>>> to >>>>>> use >>>>>>>>>>>>> micronuat-cache. umm, I'll play with this a bit and see >>>> If I >>>>>> can >>>>>>>>> work >>>>>>>>>>>> out >>>>>>>>>>>>> something better. ignite.enabled can be false but you >>> can >>>>>>> provide >>>>>>>>> your >>>>>>>>>>>> own >>>>>>>>>>>>> bean in place but that doesn't seem quite right. >>>>>>>>>>>>> >>>>>>>>>>>>> [image: image.png] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> https://github.com/micronaut-projects/micronaut-ignite/pull/33 >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Aug 21, 2020 at 6:29 PM Denis Magda < >>>>>> dma...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Michael, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, for verifying. >>>>>>>>>>>>> >>>>>>>>>>>>> I've tried extending ClientConfiguration but couldn't >>> get >>>>> the >>>>>>>>>>>>>> getters/setters working with ConfigurationBuilder. >>>> Instead >>>>>>> they >>>>>>>>> are >>>>>>>>>>>> just >>>>>>>>>>>>>> placed into wrapper classes. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Have a look at how Hazelcast implemented the default >>>>>>> configuration >>>>>>>>> for >>>>>>>>>>>> its >>>>>>>>>>>>> thin client by extending ClientConfig class of >>> Hazelcast >>>>> core: >>>>>>>>>>>>> >>>> https://github.com/micronaut-projects/micronaut-cache/blob/ >>>>>>>>>>>>> >>>>>>> master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/ >>>>>>>>>>>>> HazelcastClientConfiguration.java >>>>>>>>>>>>> >>>>>>>>>>>>> Some observations. After extending ClientConfig, their >>>>>>> Micronaut's >>>>>>>>>>>>> HazelcastClientConfiguration exposes the following >>>>>> configuration >>>>>>>>>>>>> parameteres: >>>>>>>>>>>>> >>>>>>>>>>>>> - Some fields of primitive types that belong to the >>>>> parent >>>>>>>>>>>> ClientConfig >>>>>>>>>>>>> class. They do this by adding this - *includes = >>>>>>> {"properties", >>>>>>>>>>>>> "instanceName", "labels", "userContext", >>>> "clusterName"}* >>>>>>>>>>>>> - ClientNetworkConfig, ConnectionRetryConfig, >>>>> SocketOptions >>>>>>>>>>>> properties >>>>>>>>>>>>> (that exist in the parent ClientConfig class) can >>> not >>>> be >>>>>>>>> inherited >>>>>>>>>> as >>>>>>>>>>>>> above. Thus, they define those with >>>> @ConfigurationBuilder >>>>>>>>> manually. >>>>>>>>>>>>> >>>>>>>>>>>>> As a result, their implementation is simple and >>> compact, >>>> and >>>>>>> here >>>>>>>>> is a >>>>>>>>>>>>> final list of configuration properties: >>>>>>>>>>>>> https://micronaut-projects.github.io/micronaut-cache/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration >>>>>>>>>>>>> >>>>>>>>>>>>> Could you check if we can follow a similar approach? >>> Let's >>>>>> start >>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>>> thin client. It's much simpler. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> yea, will need to >>>>>>>>>>>>>> setup a way for a user to provide their own bean >>> because >>>>>> there >>>>>>>> is >>>>>>>>> no >>>>>>>>>>>> way >>>>>>>>>>>>> a >>>>>>>>>>>>>> full configuration could be covered but I haven't >>> quite >>>>>> worked >>>>>>>>> that >>>>>>>>>>>> out >>>>>>>>>>>>>> yet. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That will be outstanding and fit well the design. Let >>> me >>>>> know >>>>>> if >>>>>>>> you >>>>>>>>>>>> need >>>>>>>>>>>>> me to help to figure out how to do that with Micronaut. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - >>>>>>>>>>>>> Denis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind < >>>>>>>> mpoll...@gmail.com >>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Dennis, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is what I came up with with some of the >>>> suggestions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> https://github.com/micronaut-projects/micronaut-ignite/blob/ >>>>>>>>>>>>> >>> 3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/ >>>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>> main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration. >>>>>>>>>>>>> java >>>>>>>>>>>>>> and >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> https://github.com/micronaut-projects/micronaut-ignite/blob/ >>>>>>>>>>>>> >>> 3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> test cases: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> https://github.com/micronaut-projects/micronaut-ignite/blob/ >>>>>>>>>>>>> >>> 3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/ >>>>>>>>>>>>> >>>>> test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've tried extending ClientConfiguration but couldn't >>>> get >>>>>> the >>>>>>>>>>>>>> getters/setters working with ConfigurationBuilder. >>>> Instead >>>>>>> they >>>>>>>>> are >>>>>>>>>>>> just >>>>>>>>>>>>>> placed into wrapper classes. Anyways, I don't think >>>>>>>>>>>> ConfigurationProperty >>>>>>>>>>>>>> is supposed to work this way. Also note the table in >>> the >>>>>>>>>>>> documentation is >>>>>>>>>>>>>> generated and without a way to exclude things I don't >>>>> think >>>>>>> this >>>>>>>>>> will >>>>>>>>>>>>> work >>>>>>>>>>>>>> cleanly. The other thing I wanted to do was nest >>>>>> @EachProperty >>>>>>>> in >>>>>>>>> a >>>>>>>>>>>>> single >>>>>>>>>>>>>> @ConfigurationProperties but that doesn't work with >>> how >>>>>> stuff >>>>>>>> gets >>>>>>>>>>>>> resolved >>>>>>>>>>>>>> ( >>>>>>>> >>> https://github.com/micronaut-projects/micronaut-core/issues/3938 >>>>>>>>> ). >>>>>>>>>>>> so >>>>>>>>>>>>> the >>>>>>>>>>>>>> cachConfiguration is in another class. This is kind >>> of a >>>>>> first >>>>>>>>>> working >>>>>>>>>>>>>> example so this will need to be adjusted quite a bit. >>>> yea, >>>>>>> will >>>>>>>>> need >>>>>>>>>>>> to >>>>>>>>>>>>>> setup a way for a user to provide their own bean >>> because >>>>>> there >>>>>>>> is >>>>>>>>> no >>>>>>>>>>>> way >>>>>>>>>>>>> a >>>>>>>>>>>>>> full configuration could be covered but I haven't >>> quite >>>>>> worked >>>>>>>>> that >>>>>>>>>>>> out >>>>>>>>>>>>>> yet. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If this is ok then I can do another pass on the >>>>> confluence. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Aug 21, 2020 at 1:55 PM Denis Magda < >>>>>>> dma...@apache.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Michael, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Finally, I figured out Micronaut configuration >>>>>>> specificities. >>>>>>>>> What >>>>>>>>>>>>>> confused >>>>>>>>>>>>>>> me before, is that even though the beans >>> configuration >>>>> in >>>>>>>>>> Micronaut >>>>>>>>>>>>> looks >>>>>>>>>>>>>>> quite similar to the Spring Boot approach, the >>> former >>>>>>>> automates >>>>>>>>> a >>>>>>>>>>>> lot >>>>>>>>>>>>>> with >>>>>>>>>>>>>>> the help of reflection in runtime. That's how our >>>>> default >>>>>>>> Spring >>>>>>>>>>>> Boot >>>>>>>>>>>>>>> configuration looks >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>> https://github.com/apache/ignite-extensions/blob/master/ >>>>>>>>>>>>> modules/spring-boot-thin-client-autoconfigure-ext/src/ >>>>>>>>>>>>> >>>>>> main/java/org/apache/ignite/springframework/boot/autoconfigure/ >>>>>>>>>>>>> IgniteClientConfigurer.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> like. And that's enough to let the users define any >>>>>> possible >>>>>>>>>>>> property >>>>>>>>>>>>> of >>>>>>>>>>>>>> an >>>>>>>>>>>>>>> IgniteConfiguration instance as per this example >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> https://apacheignite-mix.readme.io/docs/spring-boot# >>>>>>>>>>>>> set-ignite-up-via-spring-boot-configuration >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> The upside of the reflection. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyway, let's go back to our world. That's what I >>>> would >>>>>>>> suggest. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Ignite Thin Client* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Let's create DefaultThinClientConfiguration >>> that >>>>>>>> *extends* >>>>>>>>>>>>> Ignite's >>>>>>>>>>>>>>> ClientConfiguration >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> https://github.com/apache/ignite/blob/master/modules/ >>>>>>>>>>>>> core/src/main/java/org/apache/ignite/configuration/ >>>>>>>>>>>>> ClientConfiguration.java >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> Once done, it will be possible to configure >>> most of >>>>>>>>>>>>>> ClientConfiguration >>>>>>>>>>>>>>> settings which are primitive types. (guess >>> that's >>>> how >>>>>> you >>>>>>>>> were >>>>>>>>>>>> doing >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> before I joined the review) >>>>>>>>>>>>>>> - Some fields of the ClientConfiguration class >>> are >>>> of >>>>>>>> custom >>>>>>>>>>>>>>> non-primitive types and should be added into the >>>>>>>>>>>>>>> DefaultThinClientConfiguration explicitly via >>> the >>>>>>>>>>>>>> @ConfigurationBuilder >>>>>>>>>>>>>>> annotation. Those fields are *sslType, >>> sslProtocol, >>>>>>>>>>>>>>> sslCtxFactory, txCfg*. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Apart from the DefaultThinClientConfiguration, can >>> we >>>>>>> support >>>>>>>>>>>> another >>>>>>>>>>>>>>> configuration approach when a ClientConfiguration >>> bean >>>>> is >>>>>>>>> created >>>>>>>>>>>>>>> programmatically in the source code and the >>>> integration >>>>>> uses >>>>>>>>> that >>>>>>>>>>>> bean >>>>>>>>>>>>> to >>>>>>>>>>>>>>> initialize an instance of the thin client (instead >>> of >>>>>>>>>>>>>>> using DefaultThinClientConfiguration that requires >>> to >>>>> set >>>>>>> the >>>>>>>>>>>>> properties >>>>>>>>>>>>>>> via YAML,etc.). For instance, that's how the >>>>>>>> ClientConfiguration >>>>>>>>>>>> bean >>>>>>>>>>>>> is >>>>>>>>>>>>>>> created programmatically in Spring Boot >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up- >>>>>>>>>>>>> programmatically >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> our integration uses it to initialize an Ignite >>>> object. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Ignite Node (server or thick client)* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Obviously, this one is trickier due to the numerous >>>>>>>>> configuration >>>>>>>>>>>>>>> parameters of the IgniteConfiguration class >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> https://github.com/apache/ignite/blob/master/modules/ >>>>>>>>>>>>> core/src/main/java/org/apache/ignite/configuration/ >>>>>>>>>>>>> IgniteConfiguration.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, as you suggested before, we need to select the >>>> most >>>>>>>>> frequently >>>>>>>>>>>> used >>>>>>>>>>>>>>> configuration parameters and add them to the >>>>>>>>>>>> DefaultIgniteConfiguration >>>>>>>>>>>>>>> with @ConfigurationBuilder annotation. However, it >>>> seems >>>>>>>>>> reasonable >>>>>>>>>>>> if >>>>>>>>>>>>>>> DefaultIgniteConfiguration will extend Ignite's >>>>>>>>>> IgniteConfiguration >>>>>>>>>>>> (so >>>>>>>>>>>>>>> that we don't need to list parameters of primitive >>>>> types). >>>>>>>> Based >>>>>>>>>> on >>>>>>>>>>>> my >>>>>>>>>>>>>>> experience, I would add the following settings of >>>> custom >>>>>>>>>>>> non-primitive >>>>>>>>>>>>>>> types: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - TcpDiscoverySpi >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> 1700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ >>>>>>>>>>>>> TcpDiscoverySpi.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> all its fields of primitive types (this should >>> be >>>>> done >>>>>>>>> easily, >>>>>>>>>>>>> right, >>>>>>>>>>>>>>> without copy-paste?) and its ipFinder field. In >>> the >>>>>>>>> beginning, >>>>>>>>>> I >>>>>>>>>>>>> would >>>>>>>>>>>>>>> only >>>>>>>>>>>>>>> support setting TcpDiscoveryVmIpFinder >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17 >>>>>>>>>>>>> >>> 1700a928eb/modules/core/src/main/java/org/apache/ignite/ >>>>>>>>>>>>> >>> spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> KubernetesIpFinder >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17 >>>>>>>>>>>>> 1700a928eb/modules/kubernetes/src/main/java/org/apache/ >>>>>>>>>>>>> ignite/spi/discovery/tcp/ipfinder/kubernetes/ >>>>>>>>>>>>> TcpDiscoveryKubernetesIpFinder.java >>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>> the DefaultIgniteConfiguration. >>>>>>>>>>>>>>> - DataStorageConfiguration >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17 >>>>>>>>>>>>> >>>>>>>>> >>>>>> >>> 1700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/ >>>>>>>>>>>>> DataStorageConfiguration.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> including >>>>>>>>>>>>>>> its DataStorageConfiguration.dataRegions >>> property. >>>>>>>>>>>>>>> - TcpCommunicationSpi >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17 >>>>>>>>>>>>> >>> 1700a928eb/modules/core/src/main/java/org/apache/ignite/ >>>>>>>>>>>>> spi/communication/tcp/TcpCommunicationSpi.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> its fields of primitive types. Again, here is >>> I'm >>>>>>> assuming >>>>>>>>> that >>>>>>>>>>>> we >>>>>>>>>>>>> can >>>>>>>>>>>>>>> do >>>>>>>>>>>>>>> this avoiding copy-pasting. Either through >>>>>>>>>> @ConfigurationBuilder >>>>>>>>>>>>>>> (include) >>>>>>>>>>>>>>> or inheritence. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If the user wants to configure any settings >>>> unsupported >>>>> by >>>>>>>>>>>>>>> DefaultIgniteConfiguration then, there should be a >>> way >>>>> to >>>>>>>> create >>>>>>>>>> an >>>>>>>>>>>>>>> IgniteConfiguration bean programmatically and use >>> it >>>> to >>>>>>>>> initialize >>>>>>>>>>>> an >>>>>>>>>>>>>>> Ignite instance (instead of >>>> DefaultIgniteConfiguration). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What's your thinking? Let me know if I'm still >>> missing >>>>>>>>> something. >>>>>>>>>>>>>>> - >>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra < >>>>>>>>>>>> saikat.mai...@gmail.com >>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Michael, Denis >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I was looking into tiering options for ehcache[1] >>>> and >>>>>>>> network >>>>>>>>>>>> options >>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> Hazelcast[2] and I am thinking we can implement >>>>>> something >>>>>>>>>>>> similar to >>>>>>>>>>>>>>>> configure CommunicationSpi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> https://micronaut-projects.github.io/micronaut-cache/ >>>>>>>>>>>>> snapshot/guide/#ehcache >>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> https://micronaut-projects.github.io/micronaut-cache/ >>>>>>>>>>>>> snapshot/guide/#hazelcast >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let me know what you think. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Saikat >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Aug 19, 2020 at 7:09 PM Michael Pollind < >>>>>>>>>>>> mpoll...@gmail.com> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A lot of this was just figured out through >>>>>>>> experimentation. >>>>>>>>>> You >>>>>>>>>>>> can >>>>>>>>>>>>>> ask >>>>>>>>>>>>>>>>> questions in the micronaut gitter: >>>>>>>>>>>>>>>>> https://gitter.im/micronautfw/questions >>>>>>>>>>>>>>>>> . Micronaut documentation is pretty >>> comprehensive: >>>>>>>>>>>>>>>>> >>> https://docs.micronaut.io/latest/guide/index.html >>>> . >>>>>> look >>>>>>>> for >>>>>>>>>>>>>>> EachProperty >>>>>>>>>>>>>>>>> and ConfigurationProperty. you can also hunt >>>> through >>>>>> the >>>>>>>>>> current >>>>>>>>>>>>>>> existing >>>>>>>>>>>>>>>>> micronaut modules and find how those >>> configuration >>>>>> items >>>>>>>> are >>>>>>>>>>>> setup. >>>>>>>>>>>>>>> There >>>>>>>>>>>>>>>>> is also the unit test cases in micronaut-core >>>> which >>>>>> have >>>>>>>>> been >>>>>>>>>>>>> pretty >>>>>>>>>>>>>>>>> helpful in the past in working out how some of >>>> these >>>>>>>>>> annotations >>>>>>>>>>>>> work >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> practice. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Aug 19, 2020 at 4:50 PM Denis Magda < >>>>>>>>>> dma...@apache.org> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Michael, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Alright, then the question on the possible >>>>> quantity >>>>>> of >>>>>>>>>> Ignite >>>>>>>>>>>>>>> instances >>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> settled - the integration will allow to >>>>>>> auto-configure a >>>>>>>>>>>> single >>>>>>>>>>>>>>>> instance >>>>>>>>>>>>>>>>>> only. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Give me a couple of days to look into the >>>>>>> configuration >>>>>>>>>>>> matters >>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> DefaultIgniteConfiguration and see what I can >>>>>> suggest. >>>>>>>>> Could >>>>>>>>>>>> you >>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>> any materials (or sources) that on Micronaut >>>>>>>> configuration >>>>>>>>>>>>>> specifies >>>>>>>>>>>>>>>>>> (through YAML and programmatically via source >>>>> code)? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wednesday, August 19, 2020, Michael >>> Pollind < >>>>>>>>>>>>> mpoll...@gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't think micronaut will be able to >>> infer >>>>> the >>>>>>>>>>>>>> communicationSpi, >>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>> need to define it separately as follows: >>>>>>>>>>>>>>>>>>> >>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> rework-1/ignite-core/src/main/java/io/micronaut/ignite/configuration/ >>>>>>>>>>>>>>>>>>> DefaultIgniteConfiguration.java#L40-L43. >>>>>>>>>>>>>>>>>>> With this setup the configuration should >>> look >>>>>> pretty >>>>>>>>> much >>>>>>>>>>>> like >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> spring-boot sample you showed me: >>>>>>>>>>>>>>>>>>> >>>>>>> https://apacheignite-mix.readme.io/docs/spring-boot# >>>>>>>>>>>>>>>>>>> >>> set-ignite-up-via-spring-boot-configuration. >>>>>>>>>>>>>>>>>>> I agree it should make the configuration >>>> easier >>>>>> with >>>>>>>>> just >>>>>>>>>>>>>> allowing >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>>> instance and it matches up well with >>>> spring-boot >>>>>>>>>>>> configuration: >>>>>>>>>>>>>>>>>>> >>>>>> https://docs.micronaut.io/latest/api/io/micronaut/ >>>>>>>>>>>>>>>>>>> context/annotation/Requires.html. >>>>>>>>>>>>>>>>>>> Since its mostly a niche usecase then >>> having >>>>> that >>>>>> as >>>>>>>> the >>>>>>>>>>>>> default >>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>>>> seems pretty ideal to me. the definition >>> will >>>>> work >>>>>>> as >>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ignite: >>>>>>>>>>>>>>>>>>> enable true >>>>>>>>>>>>>>>>>>> ignite-instance-name: name >>>>>>>>>>>>>>>>>>> communication-spi: >>>>>>>>>>>>>>>>>>> local-port: 5555 >>>>>>>>>>>>>>>>>>> data-storage-configuration: >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> cache-configurations: >>>>>>>>>>>>>>>>>>> - name: accounts >>>>>>>>>>>>>>>>>>> queryEntities: >>>>>>>>>>>>>>>>>>> - tableName: NAME >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> - ... >>>>>>>>>>>>>>>>>>> ignite-thin: >>>>>>>>>>>>>>>>>>> enable: false >>>>>>>>>>>>>>>>>>> instance-name: name >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Micronaut has some mechanism to enforce the >>>>>> presence >>>>>>>> of >>>>>>>>>>>>> something >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> should suffice for this usecase: >>>>>>>>>>>>>>>>>>> >>>>>> https://docs.micronaut.io/latest/api/io/micronaut/ >>>>>>>>>>>>>>>>>>> context/annotation/Requires.html >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Aug 19, 2020 at 2:45 PM Denis >>> Magda < >>>>>>>>>>>> dma...@apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Michael, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The current way I have it setup is the >>>>> primary >>>>>>>> bean >>>>>>>>> is >>>>>>>>>>>> used >>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>>> you won't be able to use >>> micronaut-cache >>>>> with >>>>>>>>> anything >>>>>>>>>>>> but >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>>> bean. I guess one can override the >>> other >>>> if >>>>>> the >>>>>>>>>>>>> configuration >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>> present. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The more I'm thinking the more I'm >>> convinced >>>>>> that >>>>>>> we >>>>>>>>>>>>> shouldn't >>>>>>>>>>>>>>>> bother >>>>>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>>>>>> the auto-configuration of several Ignite >>>>>>> instances. >>>>>>>>> As I >>>>>>>>>>>> said >>>>>>>>>>>>>>>> before, >>>>>>>>>>>>>>>>>>>> that's an occasional use case. >>> Furthermore, >>>>>>>> Micronout >>>>>>>>> is >>>>>>>>>>>>>> designed >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> micro-services and serverless functions >>> and >>>> I >>>>>> can >>>>>>>>> hardly >>>>>>>>>>>>> think >>>>>>>>>>>>>>> of a >>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>> case when a micro-service or function >>> would >>>>> need >>>>>>> to >>>>>>>>> boot >>>>>>>>>>>> up >>>>>>>>>>>>>>> several >>>>>>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>> clients. What if we let to >>> auto-configure a >>>>>> single >>>>>>>>>> Ignite >>>>>>>>>>>>>>> instance >>>>>>>>>>>>>>>>> per >>>>>>>>>>>>>>>>>>>> application process? What's your view on >>>> this? >>>>>> It >>>>>>>> will >>>>>>>>>>>>>>>> significantly >>>>>>>>>>>>>>>>>>>> simplify the design and implementation of >>>>>>>> integration. >>>>>>>>>> If >>>>>>>>>>>>>> anybody >>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>> several Ignite instances, then he can >>>>>> instantiate >>>>>>>> them >>>>>>>>>>>>>> manually. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> By default the >>>>>>>>>>>>>>>>>>>>> thick client instance will replace the >>>>>>> thin-client >>>>>>>>>>>>>> DynamicCache >>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> would be ok? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If you agree on my proposal above, then I >>>>> would >>>>>>>> simply >>>>>>>>>>>>> disallow >>>>>>>>>>>>>>>>>>>> auto-starting more than one Ignite >>> instance >>>>> (let >>>>>>> it >>>>>>>>> be a >>>>>>>>>>>>> thick >>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>> thin >>>>>>>>>>>>>>>>>>>> client). For example, if a thick client >>> is >>>>>> already >>>>>>>>>>>> started, >>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>> exception on an attempt to initialize a >>> thin >>>>>>> client >>>>>>>>> (and >>>>>>>>>>>> vice >>>>>>>>>>>>>>>> versa). >>>>>>>>>>>>>>>>>> As >>>>>>>>>>>>>>>>>>>> for thick vs. thin client usage in >>> relation >>>> to >>>>>>>>>> Micronaut, >>>>>>>>>>>> I >>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>>>> using the thin client if Micronaut is >>>> deployed >>>>>> in >>>>>>> a >>>>>>>>>>>>> serverless >>>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>>>>>> (the thin client connects to the cluster >>>>>> faster), >>>>>>>>> while >>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> micro-services >>>>>>>>>>>>>>>>>>>> you can use both types of clients. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The main reason why I was using the >>> spring >>>>> bean >>>>>>>>>> definition >>>>>>>>>>>>> was >>>>>>>>>>>>>>>> mainly >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>> convenience and I'm not sure what >>> fields >>>> are >>>>>> the >>>>>>>>> most >>>>>>>>>>>>>> relevant. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ok, seems that I'm missing some important >>>>> point >>>>>>>> about >>>>>>>>>>>>>> Micronaut. >>>>>>>>>>>>>>>> Let >>>>>>>>>>>>>>>>> me >>>>>>>>>>>>>>>>>>>> double-check the following with you. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Assume these are the only fields of the >>>>>>>>>>>>>>> DefaultIgniteConfiguration: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> private final String name; >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> @ConfigurationBuilder() >>>>>>>>>>>>>>>>>>>> private IgniteConfiguration >>>>> igniteConfiguration >>>>>> = >>>>>>>> new >>>>>>>>>>>>>>>>>>>> IgniteConfiguration(); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Will I be able to set up the >>>> communicationSpi >>>>>> bean >>>>>>>>> below >>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>> having >>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>> as a field of the >>>> DefaultIgniteConfiguration? >>>>>> Are >>>>>>>> you >>>>>>>>>>>>> getting a >>>>>>>>>>>>>>>>>>>> NullPointerException? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ignite: >>>>>>>>>>>>>>>>>>>> name: some_name >>>>>>>>>>>>>>>>>>>> igniteConfiguration: >>>>>>>>>>>>>>>>>>>> communicationSpi: >>>>>>>>>>>>>>>>>>>> {redefining some fields of >>> the >>>>> SPI} >>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Aug 19, 2020 at 12:17 AM Michael >>>>>> Pollind < >>>>>>>>>>>>>>>> mpoll...@gmail.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Here is the initial setup that I >>> quickly >>>>> threw >>>>>>>>>> together >>>>>>>>>>>>> along >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>> example test cases. I feel like this >>> might >>>>>> get a >>>>>>>>>> little >>>>>>>>>>>>>>>> complicated >>>>>>>>>>>>>>>>>>> but I >>>>>>>>>>>>>>>>>>>>> think it's doable. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> rework-1/ignite-core/src/main/java/io/micronaut/ignite/configuration/ >>>>>>>>>>>>>>>>>>> DefaultIgniteConfiguration.java >>>>>>>>>>>>>>>>>>>>> along with some relevant test: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>>>> rework-1/ignite-core/src/test/groovy/io/micronaut/ignite/ >>>>>>>>>>>>>>>>>>> IgniteConfigurationSpec.groovy#L55-L73 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, Aug 18, 2020 at 11:49 PM >>> Michael >>>>>>> Pollind < >>>>>>>>>>>>>>>>> mpoll...@gmail.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The main reason why I was using the >>>> spring >>>>>> bean >>>>>>>>>>>> definition >>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>> mainly >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>> convenience and I'm not sure what >>> fields >>>>> are >>>>>>> the >>>>>>>>> most >>>>>>>>>>>>>>> relevant. >>>>>>>>>>>>>>>>> Will >>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>> to be kind of specific since the >>>>>> configuration >>>>>>>>> might >>>>>>>>>>>> get a >>>>>>>>>>>>>>>> little >>>>>>>>>>>>>>>>>>>>>> complicated. The other thing you can >>> do >>>> is >>>>>> use >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> https://docs.micronaut.io/latest/api/io/micronaut/core/ >>>>>>>>>>>>>>>>>>> convert/format/MapFormat.html >>>>>>>>>>>>>>>>>>>>>> which will just map fields and values >>> and >>>>> you >>>>>>> can >>>>>>>>>> pass >>>>>>>>>>>>> that >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> somewhere >>>>>>>>>>>>>>>>>>>>>> else to be manage it. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> so you will need to do something like >>>> this >>>>> as >>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> private final String name; >>>>>>>>>>>>>>>>>>>>>> @ConfigurationBuilder() >>>>>>>>>>>>>>>>>>>>>> private IgniteConfiguration >>>>>>> igniteConfiguration = >>>>>>>>> new >>>>>>>>>>>>>>>>>>>> IgniteConfiguration(); >>>>>>>>>>>>>>>>>>>>>> @ConfigurationBuilder(value = >>>>>>> "communicationSpi") >>>>>>>>>>>>>>>>>>>>>> private TcpCommunicationSpi >>>>> communicationSpi >>>>>> = >>>>>>>> new >>>>>>>>>>>>>>>>>>>> TcpCommunicationSpi(); >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [image: image.png] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 18, 2020 at 11:05 PM >>> Michael >>>>>>> Pollind >>>>>>>> < >>>>>>>>>>>>>>>>>> mpoll...@gmail.com> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Its whatever is setup by default when >>>> the >>>>>>> object >>>>>>>>> is >>>>>>>>>>>>>>> declared. I >>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>> will have to define multiple >>>>>>>> ConfigurationBuilders >>>>>>>>>> If >>>>>>>>>>>> i'm >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> mistaken >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>> the IgniteConfiguration. you don't >>> need >>>>> to >>>>>>>>> provide >>>>>>>>>>>> the >>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>> that is >>>>>>>>>>>>>>>>>>>>>>> provided by the key for each >>>> configuration >>>>>>> under >>>>>>>>>>>>>>> EachProperty. >>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>> name is >>>>>>>>>>>>>>>>>>>>>>> the qualified name that refers to >>> that >>>>> bean >>>>>>> and >>>>>>>>> also >>>>>>>>>>>> the >>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>> qualifier for >>>>>>>>>>>>>>>>>>>>>>> the Ignite instance. For the most >>> part >>>>> will >>>>>>> just >>>>>>>>> use >>>>>>>>>>>> the >>>>>>>>>>>>>>>> primary >>>>>>>>>>>>>>>>>> bean >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>> most part. I think you can only have >>> one >>>>>> cache >>>>>>>>>>>> instance >>>>>>>>>>>>>>> active >>>>>>>>>>>>>>>>> at a >>>>>>>>>>>>>>>>>>>> time. >>>>>>>>>>>>>>>>>>>>>>> The current way I have it setup is >>> the >>>>>> primary >>>>>>>>> bean >>>>>>>>>> is >>>>>>>>>>>>> used >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>>>>> you won't be able to use >>> micronaut-cache >>>>>> with >>>>>>>>>> anything >>>>>>>>>>>>> but >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>>>>> bean. I guess one can override the >>> other >>>>> if >>>>>>> the >>>>>>>>>>>>>> configuration >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> present. >>>>>>>>>>>>>>>>>>>>>>> One problem I see is >>> micronaut-cache. We >>>>> can >>>>>>>> only >>>>>>>>>> use >>>>>>>>>>>> one >>>>>>>>>>>>>>>>> instance >>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>> DynamicCache but I need to verify how >>>> that >>>>>>> works >>>>>>>>>>>> again. >>>>>>>>>>>>> By >>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> thick client instance will replace >>> the >>>>>>>> thin-client >>>>>>>>>>>>>>> DynamicCache >>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>> would be ok? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ignite: >>>>>>>>>>>>>>>>>>>>>>> thick-clients: >>>>>>>>>>>>>>>>>>>>>>> default: <--- primary bean >>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>> second-bean: >>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>> thin-clients: >>>>>>>>>>>>>>>>>>>>>>> default: <--- primary bean >>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>> second-bean: >>>>>>>>>>>>>>>>>>>>>>> .... >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>> https://docs.micronaut.io/latest/api/io/micronaut/ >>>>>>>>>>>>>>>>>>> context/annotation/Requires.html >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 18, 2020 at 10:13 PM >>> Denis >>>>>> Magda < >>>>>>>>>>>>>>>> dma...@apache.org> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> oh, so we probably don't need to >>> work >>>>>> with >>>>>>>>>> multiple >>>>>>>>>>>>>>>> instances. >>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>>>>>> is what >>>>>>>>>>>>>>>>>>>>>>>>> I have in the current master >>> branch. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> In most cases, people start a single >>>>>> instance >>>>>>>> of >>>>>>>>> a >>>>>>>>>>>> thick >>>>>>>>>>>>>> or >>>>>>>>>>>>>>>> thin >>>>>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>>>>>>>> per >>>>>>>>>>>>>>>>>>>>>>>> application. The clients are >>>>> multi-threaded >>>>>>> and >>>>>>>>> can >>>>>>>>>>>>>> utilize >>>>>>>>>>>>>>>> all >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> CPUs >>>>>>>>>>>>>>>>>>>>>>>> effectively. However, it's not >>> harmful >>>> to >>>>>>> have >>>>>>>>> the >>>>>>>>>>>>> ability >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> configure >>>>>>>>>>>>>>>>>>>>>>>> several clients per application. As >>> far >>>>> as >>>>>> I >>>>>>>>>>>> understand, >>>>>>>>>>>>>>>>> Micronaut >>>>>>>>>>>>>>>>>>>>>>>> distinguishes clients per the >>>>>>>>>>>>>>> "IgniteClientConfiguration.name" >>>>>>>>>>>>>>>>>>>> property, >>>>>>>>>>>>>>>>>>>>>>>> right? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So what defaults are set for >>>>>>>> IgniteConfiguration? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Does it matter to Micronaut what >>> those >>>>>>> defaults >>>>>>>>>> are? >>>>>>>>>>>> By >>>>>>>>>>>>>>>> looking >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> IgniteThinClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> https://micronaut-projects.github.io/micronaut-ignite/ >>>>>>>>>>>>>>>>>>> >>>> snapshot/api/io/micronaut/ignite/configuration/ >>>>>>>>>>>>>>>>>>> IgniteThinClientConfiguration.html >>>>>>>>>>>>>>>>>>>>>>>>> , >>>>>>>>>>>>>>>>>>>>>>>> that defines >>>>>>>>>>>>>>>> >>> org.apache.ignite.configuration.ClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>> property >>>>>>>>>>>>>>>>>>>>>>>> (under the name of >>> "configuration"), I >>>>> see >>>>>>> that >>>>>>>>>>>>> Micronaut >>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>>>>>>> introspect >>>>>>>>>>>>>>>>>>>>>>>> all the fields of the >>>> ClientConfiguration >>>>>> and >>>>>>>>>>>> prepared >>>>>>>>>>>>>> these >>>>>>>>>>>>>>>>>>>> properties >>>>>>>>>>>>>>>>>>>>>>>> table >>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> https://micronaut-projects.github.io/micronaut-ignite/ >>>>>>>>>>>>>>>>>>> >>>>> snapshot/guide/#io.micronaut.ignite.configuration. >>>>>>>>>>>>>>>>>>> IgniteThinClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>> For me, it means that whenever I am >>>>>>> configuring >>>>>>>>> the >>>>>>>>>>>> thin >>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>> in a >>>>>>>>>>>>>>>>>>>>>>>> YAML >>>>>>>>>>>>>>>>>>>>>>>> file, Micronaut will create an >>> instance >>>>> of >>>>>>> the >>>>>>>>>>>>>>>>> ClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>> (Ignite >>>>>>>>>>>>>>>>>>>>>>>> sets the defaults), and then I can >>>>> override >>>>>>>> some >>>>>>>>>>>>> settings >>>>>>>>>>>>>>> such >>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>>> "addresses" or >>>>> "enablePartitionAwareness". >>>>>>> Does >>>>>>>>>> this >>>>>>>>>>>>> sound >>>>>>>>>>>>>>>>>> accurate >>>>>>>>>>>>>>>>>>>>>>>> concerning Micronaut? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Jumping back to the >>>> IgniteConfiguration, >>>>> I >>>>>>>> would >>>>>>>>>> just >>>>>>>>>>>>> swap >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> "path" >>>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>> is the String with the "config" >>> that is >>>>>>>>>>>>>> IgniteConfiguration. >>>>>>>>>>>>>>>>> Then >>>>>>>>>>>>>>>>>>> let >>>>>>>>>>>>>>>>>>>>>>>> Ignite take care of the >>>>> IgniteConfiguration >>>>>>>>>> defaults >>>>>>>>>>>> and >>>>>>>>>>>>>>>> allow a >>>>>>>>>>>>>>>>>>>>>>>> developer >>>>>>>>>>>>>>>>>>>>>>>> to override some defaults (such as >>>>>>>>>>>> discoverySPI.ipFinder >>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>> memory >>>>>>>>>>>>>>>>>>>>>>>> settings). Just in case, you can >>> find >>>>>>>>>>>>> IgniteConfiguration >>>>>>>>>>>>>>>>> defaults >>>>>>>>>>>>>>>>>>>> here >>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> https://github.com/apache/ignite/blob/master/modules/ >>>>>>>>>>>>>>>>>>> >>>>>> core/src/main/java/org/apache/ignite/configuration/ >>>>>>>>>>>>>>>>>>> IgniteConfiguration.java >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 18, 2020 at 8:59 PM >>> Michael >>>>>>>> Pollind < >>>>>>>>>>>>>>>>>> mpoll...@gmail.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> oh, so we probably don't need to >>> work >>>>>> with >>>>>>>>>> multiple >>>>>>>>>>>>>>>> instances. >>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>>>>>> is what >>>>>>>>>>>>>>>>>>>>>>>>> I have in the current master >>> branch. >>>> I >>>>>>>> believe >>>>>>>>> I >>>>>>>>>>>> was >>>>>>>>>>>>>>>>> originally >>>>>>>>>>>>>>>>>>>>>>>> trying to >>>>>>>>>>>>>>>>>>>>>>>>> set-up the configuration with the >>>>> default >>>>>>>>> ignite >>>>>>>>>>>>>> instance >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>> found >>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>> couldn't cover enough of the >>>>>> configuration. >>>>>>>> So >>>>>>>>>> what >>>>>>>>>>>>>>> defaults >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> set >>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>> IgniteConfiguration? some of those >>>>>> factory >>>>>>>>> items >>>>>>>>>>>> can't >>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>> covered >>>>>>>>>>>>>>>>>>>>>>>> with how >>>>>>>>>>>>>>>>>>>>>>>>> micronaut sets up configurations. >>>>>>>>>>>>> @ConfigurationProperty >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>> defined on a known factory, there >>> are >>>>>> ways >>>>>>> to >>>>>>>>>> have >>>>>>>>>>>>>>> multiple >>>>>>>>>>>>>>>>>>>> factories >>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>> label them optional but that >>> easily >>>>> gets >>>>>>>>>>>> overwhelming. >>>>>>>>>>>>>> In >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>> situation >>>>>>>>>>>>>>>>>>>>>>>>> providing your own bean would >>>> probably >>>>> be >>>>>>>> more >>>>>>>>>>>> ideal >>>>>>>>>>>>> in >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>> situation when >>>>>>>>>>>>>>>>>>>>>>>>> I think about it. I was worrying >>>> that >>>>> I >>>>>>>>> wouldn't >>>>>>>>>>>> be >>>>>>>>>>>>>> able >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> cover >>>>>>>>>>>>>>>>>>>>>>>> enough >>>>>>>>>>>>>>>>>>>>>>>>> of the configuration with >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ignite: enabled: true >>> thin-clients: >>>>>>>>> default: >>>>>>>>>>>>>>>>> address: >>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>>>> "127.0.0.1:10800" - " >>>>>> 127.0.0.1:10801" >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> thin-client-2: >>>>>>>>>>>>>>>>>>>>>>>>> address: - " >>>> 127.0.0.1:10800 >>>>> " >>>>>>>>> - " >>>>>>>>>>>>>>>>> 127.0.0.1:10801 >>>>>>>>>>>>>>>>>> " >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> you can see it in the current >>>> snapshot >>>>>>>>>>>> documentation: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>> https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 18, 2020 at 4:16 PM >>> Denis >>>>>>> Magda < >>>>>>>>>>>>>>>>> dma...@apache.org> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Michael, thanks for filling out >>> the >>>>>> wiki >>>>>>>>> page. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I'm looking at the >>>> Auto-Configuration >>>>>>> wiki >>>>>>>>>>>> section >>>>>>>>>>>>> and >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>>>>>>>>>>>> of the >>>>>> io.micronaut.ignite.configuration. >>>>>>>>>>>>>>>>>>> IgniteClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> https://github.com/micronaut-projects/micronaut-ignite/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>> blob/master/ignite-core/src/main/java/io/micronaut/ignite/ >>>>>>>>>>>>> configuration/ >>>>>>>>>>>>>>>>>>> IgniteClientConfiguration.java >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> class, >>>>>>>>>>>>>>>>>>>>>>>>>> and wonder if we can perform the >>>>>>> following >>>>>>>>>>>> changes: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Rename the >>>>>>> IgniteClientConfiguration >>>>>>>> to >>>>>>>>>>>>>>>>>>> IgniteConfiguration >>>>>>>>>>>>>>>>>>>>>>>> (or, to >>>>>>>>>>>>>>>>>>>>>>>>>> avoid ambiguity, even to >>>>>>>>>>>>> DefaultIgniteConfiguration >>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> Mongo driver >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> https://micronaut-projects.github.io/micronaut-mongodb/ >>>>>>>>>>>>>>>>>>> >>>>>>> latest/api/io/micronaut/configuration/mongo/reactive/ >>>>>>>>>>>>>>>>>>> DefaultMongoConfiguration.html >>>>>>>>>>>>>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>>>>>>>>>>>> The rationale for this >>> change is >>>>>> that >>>>>>>> the >>>>>>>>>>>>>> developers >>>>>>>>>>>>>>>>> might >>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> start an embedded >>>>>>>>>>>>>>>>>>>>>>>>>> Ignite server node >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://www.gridgain.com/docs/latest/installation-guide/ >>>>>>>>>>>>>>>>>>> deployment-modes#embedded-deployment >>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>> So, I would not limit the >>>>>> integration >>>>>>>>> scope >>>>>>>>>> to >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>> clients >>>>>>>>>>>>>>>>>>>>>>>>> only. >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Presently, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>> io.micronaut.ignite.configuration.IgniteClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>>>> supports two parameters - the >>>>> "name" >>>>>>> and >>>>>>>>>>>> "path". >>>>>>>>>>>>> I >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>> replace >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> "path" >>>>>>>>>>>>>>>>>>>>>>>>>> parameter with the "config" >>> one >>>>> that >>>>>>>>>>>> instantiates >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> org.apache.ignite.IgniteConfiguration. >>>>>>>> If >>>>>>>>> we >>>>>>>>>>>> do >>>>>>>>>>>>>> that, >>>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> developers >>>>>>>>>>>>>>>>>>>>>>>>>> will be able to set any >>> property >>>>> of >>>>>>> the >>>>>>>>>>>>>>>>> IgniteConfiguration >>>>>>>>>>>>>>>>>>>>>>>> straight >>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> main YAML file. See how it's >>>> done >>>>>> for >>>>>>>> the >>>>>>>>>>>> Ignite >>>>>>>>>>>>>>> Spring >>>>>>>>>>>>>>>>>> Boot >>>>>>>>>>>>>>>>>>>>>>>>>> Auto-Configuration >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> https://apacheignite-mix.readme.io/docs/spring-boot# >>>>>>>>>>>>>>>>>>> set-ignite-up-via-spring-boot-configuration >>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>> Guess, we can do the same >>> with >>>>>>>> Micronaut. >>>>>>>>>>>>>>>>>>>>>>>>>> 3. If the previous >>> modification >>>> is >>>>>>>>> feasible, >>>>>>>>>>>>> then I >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>> rework >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> Ignite thin client >>> configuration >>>>>>>>> similarly, >>>>>>>>>>>>> taking >>>>>>>>>>>>>>> our >>>>>>>>>>>>>>>>>> Spring >>>>>>>>>>>>>>>>>>>>>>>> Boot >>>>>>>>>>>>>>>>>>>>>>>>>> integration for the thin >>> client >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> https://apacheignite-mix.readme.io/docs/spring-boot# >>>>>>>>>>>>>>>>>>> >>>> set-thin-client-up-via-spring-boot-configuration >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> as a reference. As I see, the >>>>>> current >>>>>>>>>> version >>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>> IgniteThinClientConfiguration >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> https://github.com/micronaut-projects/micronaut-ignite/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>> blob/master/ignite-core/src/main/java/io/micronaut/ignite/ >>>>>>>>>>>>> configuration/ >>>>>>>>>>>>>>>>>>> IgniteThinClientConfiguration.java >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> already >>>>>>>>>>>>>>>>>>>>>>>>>> adopts this approach. I would >>>> only >>>>>>>> rename >>>>>>>>>>>>>>>> "configuration" >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>> "config", >>>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>> remove the "transaction" >>> field >>>>> since >>>>>>> you >>>>>>>>> can >>>>>>>>>>>> pass >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> transactional >>>>>>>>>>>>>>>>>>>>>>>>>> settings via the YAML >>> following >>>>> the >>>>>>>> format >>>>>>>>>>>> below: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> ignite-thin-client: >>>>>>>>>>>>>>>>>>>>>>>>>> name: >>>>>>>>>>>>>>>>>>>>>>>>>> config: >>>>>>>>>>>>>>>>>>>>>>>>>> addresses: >>> <IP_addresses> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> partitionAwarenessEnabled: >>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>> >>> transactionConfiguration: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> defaultTxConcurrency:... >>>>>>>>>>>>>>>>>>>>>>>>>> defaultTxTimeout >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 17, 2020 at 6:50 PM >>>>> Michael >>>>>>>>>> Pollind < >>>>>>>>>>>>>>>>>>>> mpoll...@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> oh, that makes more sense. so >>>> those >>>>>>>> methods >>>>>>>>>> get >>>>>>>>>>>>>>> wrapped >>>>>>>>>>>>>>>>>> into a >>>>>>>>>>>>>>>>>>>>>>>>>>> micronaut-aop intercept. Below >>>> I've >>>>>>>> listed >>>>>>>>>> the >>>>>>>>>>>>>>> relevant >>>>>>>>>>>>>>>>>>> sections >>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> code >>>>>>>>>>>>>>>>>>>>>>>>>>> that would handle each >>> annotation >>>>>> along >>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>>>>> methods >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> get >>>>>>>>>>>>>>>>>>>>>>>>> called >>>>>>>>>>>>>>>>>>>>>>>>>>> from the ignite branch I'm >>>> working >>>>>>> from. >>>>>>>>>>>> Hopefully >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> helps. >>>>>>>>>>>>>>>>>>>>>>>> The key >>>>>>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>> specified from the CacheConfig >>>>>>> annotation >>>>>>>>> but >>>>>>>>>>>> this >>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>>>>>>>>>>>>> is a better way to represent >>> the >>>>> key. >>>>>>> By >>>>>>>>>>>> default >>>>>>>>>>>>> it >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>>> DefaultCacheKeyGenerator( >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> https://github.com/micronaut-projects/micronaut-cache/blob/ >>>>>>>>>>>>>>>>>>> >>>>>> master/cache-core/src/main/java/io/micronaut/cache/ >>>>>>>>>>>>> interceptor/ >>>>>>>>>>>>>>>>>>> DefaultCacheKeyGenerator.java >>>>>>>>>>>>>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I also finished up this >>> document >>>> on >>>>>>>> sunday: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration >>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>>> Any suggestions with what I >>> could >>>>>>> expand >>>>>>>> on >>>>>>>>>> and >>>>>>>>>>>>> how >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>> adjusted. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Cacheable: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> For Cacheable it will run a >>> get >>>> and >>>>>>>> issue a >>>>>>>>>>>> put if >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> value >>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>> present >>>>>>>>>>>>>>>>>>>>>>>>>>> in the cache. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -> micronaut-cache: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> https://github.com/micronaut-projects/micronaut-cache/blob/ >>>>>>>>>>>>>>>>>>> >>>>>> master/cache-core/src/main/java/io/micronaut/cache/ >>>>>>>>>>>>>>>>>>> interceptor/CacheInterceptor.java#L163-L170 >>>>>>>>>>>>>>>>>>>>>>>>>>> -> ignite-cache: >>>>>>>>>>>>>>>>>>>>>>>>>>> get: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>> rework/ignite-cache/src/main/java/io/micronaut/ignite/ >>>>>>>>>>>>>>>>>>> IgniteSyncCache.java#L60-L70 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> CachePut: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> For cache put it will >>> invalidate >>>> if >>>>>> the >>>>>>>>>> return >>>>>>>>>>>> is >>>>>>>>>>>>>> null >>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>>>>>>> issue a >>>>>>>>>>>>>>>>>>>>>>>>>>> put. I think there might be a >>>>> mistake >>>>>>> in >>>>>>>> my >>>>>>>>>>>> code >>>>>>>>>>>>>>>> because I >>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>> putIfAbsent >>>>>>>>>>>>>>>>>>>>>>>>>>> for both cases. I need to >>>>> investigate >>>>>>>> that >>>>>>>>>>>> closer >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> write >>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>>>>> additional >>>>>>>>>>>>>>>>>>>>>>>>>>> test cases to verify the >>>> behaviour. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --> micronaut-cache: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> https://github.com/micronaut-projects/micronaut-cache/blob/ >>>>>>>>>>>>>>>>>>> >>>>>> master/cache-core/src/main/java/io/micronaut/cache/ >>>>>>>>>>>>>>>>>>> interceptor/CacheInterceptor.java#L510-L525 >>>>>>>>>>>>>>>>>>>>>>>>>>> -> ignite-cache: >>>>>>>>>>>>>>>>>>>>>>>>>>> put: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>> rework/ignite-cache/src/main/java/io/micronaut/ignite/ >>>>>>>>>>>>>>>>>>> IgniteSyncCache.java#L83-L88 >>>>>>>>>>>>>>>>>>>>>>>>>>> invalidate: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>> rework/ignite-cache/src/main/java/io/micronaut/ignite/ >>>>>>>>>>>>>>>>>>> IgniteSyncCache.java#L91-L95 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> CacheInvalidate: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> for cache invalidation it will >>>> just >>>>>> be >>>>>>>>>> removed >>>>>>>>>>>> by >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> key. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --> micronaut-cache: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> https://github.com/micronaut-projects/micronaut-cache/blob/ >>>>>>>>>>>>>>>>>>> >>>>>> master/cache-core/src/main/java/io/micronaut/cache/ >>>>>>>>>>>>>>>>>>> interceptor/CacheInterceptor.java#L590-L596 >>>>>>>>>>>>>>>>>>>>>>>>>>> -> ignite-cache: >>>>>>>>>>>>>>>>>>>>>>>>>>> invalidate: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> https://github.com/pollend/micronaut-ignite/blob/feature/ >>>>>>>>>>>>>>>>>>> >>>>>>> rework/ignite-cache/src/main/java/io/micronaut/ignite/ >>>>>>>>>>>>>>>>>>> IgniteSyncCache.java#L91-L95 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 17, 2020 at 5:23 >>> PM >>>>>> Saikat >>>>>>>>>> Maitra < >>>>>>>>>>>>>>>>>>>>>>>> saikat.mai...@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> In the Example Cacheable >>> Object >>>>> you >>>>>>> are >>>>>>>>>> using >>>>>>>>>>>>>>>> @CachePut, >>>>>>>>>>>>>>>>>>>>>>>> @Cacheable >>>>>>>>>>>>>>>>>>>>>>>>>>>> annotations and >>>> @CacheInvalidate >>>>>>>>>> annotations >>>>>>>>>>>>> and I >>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>>> trying >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>>>>>>>>>>>>> when user use these >>> annotation >>>>> then >>>>>>>> what >>>>>>>>>>>> would >>>>>>>>>>>>> be >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> underlying >>>>>>>>>>>>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>>>>>>>>>> operation that will happen? >>> and >>>>> how >>>>>>>> those >>>>>>>>>>>>>> operations >>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>> performed? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> An example like when user >>> call >>>>> this >>>>>>>> below >>>>>>>>>>>> method >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> result >>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>> getValue is cached? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> @Cacheable >>>>>>>>>>>>>>>>>>>>>>>>>>>> int getValue(String >>> name) { >>>>>>>>>>>>>>>>>>>>>>>>>>>> return >>>>>>>>>>>> counters.computeIfAbsent(name, { >>>>>>>>>>>>> 0 >>>>>>>>>>>>>> }) >>>>>>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Saikat >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, Aug 15, 2020 at >>> 7:21 PM >>>>>>> Michael >>>>>>>>>>>> Pollind >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>> mpoll...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> when you mean these >>>> annotations >>>>>> do >>>>>>>> you >>>>>>>>>> mean >>>>>>>>>>>>> this >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>>>>>>>>>>> implemented in ignite? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The project at the moment >>> is >>>>>> split >>>>>>>> into >>>>>>>>>>>>> multiple >>>>>>>>>>>>>>>>>> modules. >>>>>>>>>>>>>>>>>>>>>>>>>> ignite-core, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ignite-cache, etc ... The >>>> plan >>>>>> was >>>>>>> to >>>>>>>>>> also >>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>> ignite-data >>>>>>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>>>>>>>>>> take a bit of work to get >>>>> working >>>>>>>>>> correctly >>>>>>>>>>>>> but >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> basic >>>>>>>>>>>>>>>>>>>>>>>> config is >>>>>>>>>>>>>>>>>>>>>>>>>>>> mostly >>>>>>>>>>>>>>>>>>>>>>>>>>>>> done. The plan is also to >>>>> verify >>>>>>> the >>>>>>>>> API >>>>>>>>>>>>>> described >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> wiki and >>>>>>>>>>>>>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>>>>>>>>>>>>> sure this is what would >>> work >>>>>> best. >>>>>>> At >>>>>>>>> the >>>>>>>>>>>>> moment >>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>>>>> missing >>>>>>>>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation for the >>>>> thin-cache >>>>>>> and >>>>>>>>> how >>>>>>>>>>>> that >>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>> fit >>>>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>>>> scheme. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've removed it due to the >>>>> added >>>>>>>>>> complexity >>>>>>>>>>>>> but >>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>>> sure >>>>>>>>>>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>>> arranged that would work. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For Ignite-cache, I have >>> it >>>> as >>>>> a >>>>>>>>> separate >>>>>>>>>>>>> module >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>> optionally >>>>>>>>>>>>>>>>>>>>>>>>>>>>> included in a micronaut >>>> project >>>>>>> where >>>>>>>>>> this >>>>>>>>>>>>>> module >>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>> has a >>>>>>>>>>>>>>>>>>>>>>>>>> dependency >>>>>>>>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>>>>>>> micronaut-cache. The >>>> AsyncCache >>>>>> and >>>>>>>>>>>> SyncCache >>>>>>>>>>>>>> are >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>>>>>>>>>> interfaces >>>>>>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> micronaut-cache defines. >>>> There >>>>>> are >>>>>>>> two >>>>>>>>>>>> ways to >>>>>>>>>>>>>>>> define >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> you can either provide >>> beans >>>>> for >>>>>>>>>> AsyncCache >>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> SyncCache >>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>>>>>> define a >>> DynamicCacheManager >>>>> that >>>>>>>> will >>>>>>>>>> use >>>>>>>>>>>> the >>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> instance >>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> refer to the name of the >>>> cache >>>>>>> used. >>>>>>>> In >>>>>>>>>> the >>>>>>>>>>>>>>>>>> documentation >>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>> believe >>>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Teracotta you give a list >>> of >>>>>> caches >>>>>>>> you >>>>>>>>>>>> want >>>>>>>>>>>>> and >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> - >>>>>>>>>>>> Denis >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
