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 > >> > > >
