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