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