Apache Ignite Developers - Legacy Mail Archive

Re: Micronaut/Ignite

Classic

List

Threaded

46 messages Options

123

dmagda

Re: Micronaut/Ignite

Michael, welcome to the community!

Igniters, let me introduce you to Michael, who is working on the Micronaut integration for Ignite. Even though the integration is hosted in the Micronaut repository, I thought it's in our interest to help Michael with the APIs design and support with other Ignite-specific challenges he might hit on the road. @Saikat Maitra, @Ilya Kasnacheev, @Valentin Kulichenko, I would appreciate if you folks get involved, at least, in the API design phase.

Michael, answering your questions

So I already have 2 implemented but I'm not really sure what you mean by autostart for number 1? so at the moment I have the thin-client omitted just for simplicity and I think it could just be added in afterwards. I'm not sure how important it is in the whole scheme of things since this is my first time really looking at ignite. we can start there and figure out those details.

Instead of the autostart, I was intended to say the autoconfigure feature, which is a Spring Boot term. Sorry for the confusion. Anyway, that's when Micronaut automatically starts an Ignite client instance based on configuration settings. As you confirmed below, the integration logic already does this.

When we design new public APIs, we frequently take advantage of Ignite Wiki by creating design documents that comprise an API interface with code samples showing how a developer is supposed to use the API.

You tweak the APIs with code samples until those are settled. This approach helps to assess the APIs from the end-user standpoint and avoid common design mistakes before coding and releasing a feature for public usage. Furthermore, such design pages are an excellent source for a technical documentation that you create regardless. Check the "Key Interfaces" and "Examples" sections of the tracing feature's design page.

So, my suggestion to you would be as follows:

Create the Micronaut Integration page under the Design Documents tree. Sign up on the wiki and tell me your email/id. I'll grant you all the required editing permissions.
On that page, create a section for the autoconfigure feature by listing all possible configuration parameters the user can pass in YAML files and examples of how a client instance can be injected in application logic. Guess, thin and thick clients will be configured differently.
Another section should be related to the Micronaut Caching API. Again, public Ignite-specific APIs we're adding to Micronaut and how the user is supposed to use those.

Once the page is ready, we'll start brainstorming on the APIs together using this discussion thread.

3 is giving me some problems since the SQL generated does not match up. ignite rejected the query when I have auto generated fields in the DDL statement and I've also dropped the scheme from the SQL and used the scheme to resolve the target cache. I'm using SqlFieldsQuery to make the request but there seems to be a few query options:

If you'd like to carry on with this part of the integration, then I would start a separate discussion on the dev list. Or just put it off for a bit until we sort out the clients' configuration and Micronaut Caching APIs.

Denis

On Thu, Aug 13, 2020 at 1:16 PM Michael Pollind <[hidden email]> wrote:

Hello,
Denis Magda

So I already have 2 implemented but I'm not really sure what you mean by autostart for number 1? so at the moment I have the thin-client omitted just for simplicity and I think it could just be added in afterwards. I'm not sure how important it is in the whole scheme of things since this is my first time really looking at ignite. we can start there and figure out those details.

here is the application.yml that i currently have for a basic configuration. I'm using the bean definitions from spring to do this:

ignite:
enabled: true
clients:
default:
path: classpath:standard.cfg

3 is giving me some problems since the SQL generated does not match up. ignite rejected the query when I have auto generated fields in the DDL statement and I've also dropped the scheme from the SQL and used the scheme to resolve the target cache. I'm using SqlFieldsQuery to make the request but there seems to be a few query options:

@IgniteRepository(value = "default", schema = "mydb")

public interface UserRepository extends CrudRepository<User, Long> {

}

so I created an account on the apache ignite forum: http://apache-ignite-developers.2346864.n4.nabble.com/template/NamlServlet.jtp?macro=user_profile

I wouldn't mind starting a thread to start planning out the API.

From,
Michael Pollind

dmagda

Re: Micronaut/Ignite

Michael,

What's your confluence id? For some reason, I can't add you using the email address.

Agree, that it's the right move to split the pull-request. Btw, keep the dev list in the copy, no need to exclude from the recipients' list.

Denis

On Fri, Aug 14, 2020 at 1:10 PM Michael Pollind <[hidden email]> wrote:

I created an account in confluence with [hidden email].

I also took some time yesterday to split my work just for the ignite-core and ignite-cache stuff: https://github.com/micronaut-projects/micronaut-ignite/pull/33

This should be more approachable.

On Fri, Aug 14, 2020 at 9:44 AM Denis Magda <[hidden email]> wrote:
Michael, welcome to the community!

Igniters, let me introduce you to Michael, who is working on the Micronaut integration for Ignite. Even though the integration is hosted in the Micronaut repository, I thought it's in our interest to help Michael with the APIs design and support with other Ignite-specific challenges he might hit on the road. @Saikat Maitra, @Ilya Kasnacheev, @Valentin Kulichenko, I would appreciate if you folks get involved, at least, in the API design phase.

Michael, answering your questions

So I already have 2 implemented but I'm not really sure what you mean by autostart for number 1? so at the moment I have the thin-client omitted just for simplicity and I think it could just be added in afterwards. I'm not sure how important it is in the whole scheme of things since this is my first time really looking at ignite. we can start there and figure out those details.

Instead of the autostart, I was intended to say the autoconfigure feature, which is a Spring Boot term. Sorry for the confusion. Anyway, that's when Micronaut automatically starts an Ignite client instance based on configuration settings. As you confirmed below, the integration logic already does this.

When we design new public APIs, we frequently take advantage of Ignite Wiki by creating design documents that comprise an API interface with code samples showing how a developer is supposed to use the API.
You tweak the APIs with code samples until those are settled. This approach helps to assess the APIs from the end-user standpoint and avoid common design mistakes before coding and releasing a feature for public usage. Furthermore, such design pages are an excellent source for a technical documentation that you create regardless. Check the "Key Interfaces" and "Examples" sections of the tracing feature's design page.

So, my suggestion to you would be as follows:
Create the Micronaut Integration page under the Design Documents tree. Sign up on the wiki and tell me your email/id. I'll grant you all the required editing permissions.
On that page, create a section for the autoconfigure feature by listing all possible configuration parameters the user can pass in YAML files and examples of how a client instance can be injected in application logic. Guess, thin and thick clients will be configured differently.
Another section should be related to the Micronaut Caching API. Again, public Ignite-specific APIs we're adding to Micronaut and how the user is supposed to use those.
Once the page is ready, we'll start brainstorming on the APIs together using this discussion thread.

3 is giving me some problems since the SQL generated does not match up. ignite rejected the query when I have auto generated fields in the DDL statement and I've also dropped the scheme from the SQL and used the scheme to resolve the target cache. I'm using SqlFieldsQuery to make the request but there seems to be a few query options:

If you'd like to carry on with this part of the integration, then I would start a separate discussion on the dev list. Or just put it off for a bit until we sort out the clients' configuration and Micronaut Caching APIs.

-
Denis

On Thu, Aug 13, 2020 at 1:16 PM Michael Pollind <[hidden email]> wrote:
Hello,
Denis Magda

So I already have 2 implemented but I'm not really sure what you mean by autostart for number 1? so at the moment I have the thin-client omitted just for simplicity and I think it could just be added in afterwards. I'm not sure how important it is in the whole scheme of things since this is my first time really looking at ignite. we can start there and figure out those details.

here is the application.yml that i currently have for a basic configuration. I'm using the bean definitions from spring to do this:

ignite:
enabled: true
clients:
default:
path: classpath:standard.cfg

3 is giving me some problems since the SQL generated does not match up. ignite rejected the query when I have auto generated fields in the DDL statement and I've also dropped the scheme from the SQL and used the scheme to resolve the target cache. I'm using SqlFieldsQuery to make the request but there seems to be a few query options:

@IgniteRepository(value = "default", schema = "mydb")

public interface UserRepository extends CrudRepository<User, Long> {

}

so I created an account on the apache ignite forum: http://apache-ignite-developers.2346864.n4.nabble.com/template/NamlServlet.jtp?macro=user_profile

I wouldn't mind starting a thread to start planning out the API.

From,
Michael Pollind

Michael Pollind

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > > 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 <
> [hidden email]>
> > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > > 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 <
> [hidden email]
> > >
> > > > > 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
> > > > > > > > > [hidden email] address. Otherwise, we
> need
> > to
> > > > > > approve
> > > > > > > > > every email you send.
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
> > > > > [hidden email]>
> > > > > > > > > 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/
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Michael Pollind

Re: Micronaut/Ignite

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();

On Tue, Aug 18, 2020 at 11:05 PM Michael Pollind <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > > 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 <[hidden email]>
> > > > 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 <
> > [hidden email]
> > > >
> > > > > 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 <
> > [hidden email]
> > > >
> > > > > > 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 <[hidden email]
> >
> > > > 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
> > > > > > > > [hidden email] address. Otherwise, we need
> to
> > > > > approve
> > > > > > > > every email you send.
> > > > > > > >
> > > > > > > > -
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
> > > > [hidden email]>
> > > > > > > > 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/
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Michael Pollind

Re: Micronaut/Ignite

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 <[hidden email]> 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();
On Tue, Aug 18, 2020 at 11:05 PM Michael Pollind <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > > 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 <[hidden email]>
> > > > 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 <
> > [hidden email]
> > > >
> > > > > 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 <
> > [hidden email]
> > > >
> > > > > > 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 <[hidden email]
> >
> > > > 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
> > > > > > > > [hidden email] address. Otherwise, we need
> to
> > > > > approve
> > > > > > > > every email you send.
> > > > > > > >
> > > > > > > > -
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
> > > > [hidden email]>
> > > > > > > > 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/
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

dmagda

Re: Micronaut/Ignite

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]
>>>> >
>>>> > > 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 <
>>>> [hidden email]
>>>> > >
>>>> > > > 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 <
>>>> [hidden email]>
>>>> > > > > 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 <
>>>> > > [hidden email]
>>>> > > > >
>>>> > > > > > 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 <
>>>> > > [hidden email]
>>>> > > > >
>>>> > > > > > > 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 <
>>>> [hidden email]
>>>> > >
>>>> > > > > 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
>>>> > > > > > > > > [hidden email] address. Otherwise, we
>>>> need
>>>> > to
>>>> > > > > > approve
>>>> > > > > > > > > every email you send.
>>>> > > > > > > > >
>>>> > > > > > > > > -
>>>> > > > > > > > > Denis
>>>> > > > > > > > >
>>>> > > > > > > > >
>>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
>>>> > > > > [hidden email]>
>>>> > > > > > > > > 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/
>>>> > > > > > > > >>
>>>> > > > > > > > >
>>>> > > > > > > >
>>>> > > > > > >
>>>> > > > > >
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>

Michael Pollind

Re: Micronaut/Ignite

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> >> 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 <[hidden email]>
> 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 <[hidden email]>
> >>>> 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 <[hidden email]>
> >>>> 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 <
> [hidden email]
> >>>> >
> >>>> > > 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 <
> >>>> [hidden email]
> >>>> > >
> >>>> > > > 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 <
> >>>> [hidden email]>
> >>>> > > > > 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 <
> >>>> > > [hidden email]
> >>>> > > > >
> >>>> > > > > > 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 <
> >>>> > > [hidden email]
> >>>> > > > >
> >>>> > > > > > > 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 <
> >>>> [hidden email]
> >>>> > >
> >>>> > > > > 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
> >>>> > > > > > > > > [hidden email] address. Otherwise,
> we
> >>>> need
> >>>> > to
> >>>> > > > > > approve
> >>>> > > > > > > > > every email you send.
> >>>> > > > > > > > >
> >>>> > > > > > > > > -
> >>>> > > > > > > > > Denis
> >>>> > > > > > > > >
> >>>> > > > > > > > >
> >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
> >>>> > > > > [hidden email]>
> >>>> > > > > > > > > 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/
> >>>> > > > > > > > >>
> >>>> > > > > > > > >
> >>>> > > > > > > >
> >>>> > > > > > >
> >>>> > > > > >
> >>>> > > > >
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> >>>
>

dmagda

Re: Micronaut/Ignite

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > >> 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > >>>> 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 <[hidden email]>
> > >>>> 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 <
> > [hidden email]
> > >>>> >
> > >>>> > > 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 <
> > >>>> [hidden email]
> > >>>> > >
> > >>>> > > > 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 <
> > >>>> [hidden email]>
> > >>>> > > > > 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 <
> > >>>> > > [hidden email]
> > >>>> > > > >
> > >>>> > > > > > 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 <
> > >>>> > > [hidden email]
> > >>>> > > > >
> > >>>> > > > > > > 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 <
> > >>>> [hidden email]
> > >>>> > >
> > >>>> > > > > 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
> > >>>> > > > > > > > > [hidden email] address. Otherwise,
> > we
> > >>>> need
> > >>>> > to
> > >>>> > > > > > approve
> > >>>> > > > > > > > > every email you send.
> > >>>> > > > > > > > >
> > >>>> > > > > > > > > -
> > >>>> > > > > > > > > Denis
> > >>>> > > > > > > > >
> > >>>> > > > > > > > >
> > >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
> > >>>> > > > > [hidden email]>
> > >>>> > > > > > > > > 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

Michael Pollind

Re: Micronaut/Ignite

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]
> >
> > > > 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 <
> [hidden email]>
> > > >> 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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > >>>> 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 <[hidden email]>
> > > >>>> 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 <
> > > [hidden email]
> > > >>>> >
> > > >>>> > > 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 <
> > > >>>> [hidden email]
> > > >>>> > >
> > > >>>> > > > 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 <
> > > >>>> [hidden email]>
> > > >>>> > > > > 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 <
> > > >>>> > > [hidden email]
> > > >>>> > > > >
> > > >>>> > > > > > 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 <
> > > >>>> > > [hidden email]
> > > >>>> > > > >
> > > >>>> > > > > > > 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 <
> > > >>>> [hidden email]
> > > >>>> > >
> > > >>>> > > > > 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
> > > >>>> > > > > > > > > [hidden email] address.
> Otherwise,
> > > we
> > > >>>> need
> > > >>>> > to
> > > >>>> > > > > > approve
> > > >>>> > > > > > > > > every email you send.
> > > >>>> > > > > > > > >
> > > >>>> > > > > > > > > -
> > > >>>> > > > > > > > > Denis
> > > >>>> > > > > > > > >
> > > >>>> > > > > > > > >
> > > >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind <
> > > >>>> > > > > [hidden email]>
> > > >>>> > > > > > > > > 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
>

Saikat Maitra

Re: Micronaut/Ignite

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]
> >
> > > > 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 <
> [hidden email]
> > >
> > > > > 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 <
> > [hidden email]>
> > > > >> 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 <[hidden email]>
> > > > 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 <
> > [hidden email]
> > > >
> > > > >>>> 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 <
> [hidden email]>
> > > > >>>> 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 <
> > > > [hidden email]
> > > > >>>> >
> > > > >>>> > > 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 <
> > > > >>>> [hidden email]
> > > > >>>> > >
> > > > >>>> > > > 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 <
> > > > >>>> [hidden email]>
> > > > >>>> > > > > 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 <
> > > > >>>> > > [hidden email]
> > > > >>>> > > > >
> > > > >>>> > > > > > 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 <
> > > > >>>> > > [hidden email]
> > > > >>>> > > > >
> > > > >>>> > > > > > > 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 <
> > > > >>>> [hidden email]
> > > > >>>> > >
> > > > >>>> > > > > 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
> > > > >>>> > > > > > > > > [hidden email] address.
> > Otherwise,
> > > > we
> > > > >>>> need
> > > > >>>> > to
> > > > >>>> > > > > > approve
> > > > >>>> > > > > > > > > every email you send.
> > > > >>>> > > > > > > > >
> > > > >>>> > > > > > > > > -
> > > > >>>> > > > > > > > > Denis
> > > > >>>> > > > > > > > >
> > > > >>>> > > > > > > > >
> > > > >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael Pollind
> <
> > > > >>>> > > > > [hidden email]>
> > > > >>>> > > > > > > > > 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
> >
>

123