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

Reply via email to