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