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