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