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 Hazelcast > > >>>> > implements > > >>>> > > > the > > >>>> > > > > > DynamicCacheManager. you can see that in the yaml > > >>>> configuration in > > >>>> > > > > > micronaut documentation where a list of cache names are > > >>>> provided > > >>>> > > along > > >>>> > > > > with > > >>>> > > > > > a configuration. Something similar can also be setup > where a > > >>>> list > > >>>> > of > > >>>> > > > > > implementations from the yaml can be mapped to a > > >>>> configuration if > > >>>> > > that > > >>>> > > > > > would be more ideal. > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > >>>> > > > > > >>>> > > > > >>>> > > > >>>> > > https://github.com/pollend/micronaut-ignite/tree/feature/ > rework/ignite-cache/src/main/java/io/micronaut/ignite > > >>>> > > > > > > > >>>> > > > > > On Sat, Aug 15, 2020 at 4:10 PM Saikat Maitra < > > >>>> > > saikat.mai...@gmail.com > > >>>> > > > > > > >>>> > > > > > wrote: > > >>>> > > > > > > > >>>> > > > > > > Hi Michael, > > >>>> > > > > > > > > >>>> > > > > > > Welcome to the Ignite community!!! > > >>>> > > > > > > > > >>>> > > > > > > Please feel free to reach out if you have any questions > > with > > >>>> > > respect > > >>>> > > > to > > >>>> > > > > > > Ignite Integration. > > >>>> > > > > > > > > >>>> > > > > > > I had a question specific to integration and wanted to > ask > > >>>> if > > >>>> > these > > >>>> > > > > > > annotations also need to be implemented for the > > >>>> micronaut-ignite > > >>>> > > > > > > integration. > > >>>> > > > > > > > > >>>> > > > > > > @Cacheable - Indicates a method is cacheable within the > > >>>> given > > >>>> > cache > > >>>> > > > > name > > >>>> > > > > > > @CachePut - Indicates that the return value of a method > > >>>> > invocation > > >>>> > > > > should > > >>>> > > > > > > be cached. Unlike @Cacheable the original operation is > > never > > >>>> > > skipped. > > >>>> > > > > > > @CacheInvalidate - Indicates the invocation of a method > > >>>> should > > >>>> > > cause > > >>>> > > > > the > > >>>> > > > > > > invalidation of one or many caches. > > >>>> > > > > > > > > >>>> > > > > > > Denis - Thank you for sharing the details in dev list, > it > > >>>> great > > >>>> > to > > >>>> > > > > learn > > >>>> > > > > > > about micronaut-ignite module. > > >>>> > > > > > > > > >>>> > > > > > > Regards, > > >>>> > > > > > > Saikat > > >>>> > > > > > > > > >>>> > > > > > > On Sat, Aug 15, 2020 at 12:35 AM Michael Pollind < > > >>>> > > mpoll...@gmail.com > > >>>> > > > > > > >>>> > > > > > > wrote: > > >>>> > > > > > > > > >>>> > > > > > > > Here is the page that i've stubbed out: > > >>>> > > > > > > > > > >>>> > > > > > > > >>>> > > > > > >>>> > > > >>>> > > https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration > > >>>> > > > > > > > > > >>>> > > > > > > > I'll start trying to fill out some of the details over > > >>>> the next > > >>>> > > few > > >>>> > > > > > days > > >>>> > > > > > > > and we can go from there. > > >>>> > > > > > > > > > >>>> > > > > > > > On Fri, Aug 14, 2020 at 2:47 PM Denis Magda < > > >>>> dma...@apache.org > > >>>> > > > > >>>> > > > > wrote: > > >>>> > > > > > > > > > >>>> > > > > > > > > You're in, now you can create wiki pages in the > Ignite > > >>>> > > namespace. > > >>>> > > > > > > > > > > >>>> > > > > > > > > Also, please subscribe to the list by sending a note > > to > > >>>> the > > >>>> > > > > > > > > dev-subscr...@ignite.apache.org address. Otherwise, > > we > > >>>> need > > >>>> > to > > >>>> > > > > > approve > > >>>> > > > > > > > > every email you send. > > >>>> > > > > > > > > > > >>>> > > > > > > > > - > > >>>> > > > > > > > > Denis > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind < > > >>>> > > > > mpoll...@gmail.com> > > >>>> > > > > > > > > wrote: > > >>>> > > > > > > > > > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> here is the link: > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > >>>> > > > > > > >>>> > > > > > >>>> > > > > >>>> > > > >>>> > > https://cwiki.apache.org/confluence/users/viewuserprofile.action? > username=mpollind > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> Here is the work in progress pull request that I've > > put > > >>>> > > > together: > > >>>> > > > > > > > >> > > >>>> > > https://github.com/micronaut-projects/micronaut-ignite/pull/33 > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> > > >>>> > > > > > > > >> -- > > >>>> > > > > > > > >> Sent from: > > >>>> > > > http://apache-ignite-developers.2346864.n4.nabble.com/ > > >>>> > > > > > > > >> > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > >>>> > > > > > > >>>> > > > > > >>>> > > > > >>>> > > > >>>> > > >>> > > > -- - Denis
