Apache Ignite Developers - Legacy Mail Archive

Re: Micronaut/Ignite

Classic

List

Threaded

46 messages Options

123

Michael Pollind

Re: Micronaut/Ignite

Hi Saikat,

What fields in TcpCommunicationSPI are you referring to?

On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
wrote:

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

dmagda

Re: Micronaut/Ignite

In reply to this post by Saikat Maitra

Michael,

Finally, I figured out Micronaut configuration specificities. What confused
me before, is that even though the beans configuration in Micronaut looks
quite similar to the Spring Boot approach, the former automates a lot with
the help of reflection in runtime. That's how our default Spring Boot
configuration looks
<https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java>
like. And that's enough to let the users define any possible property of an
IgniteConfiguration instance as per this example
<https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration>.
The upside of the reflection.

Anyway, let's go back to our world. That's what I would suggest.

*Ignite Thin Client*

- Let's create DefaultThinClientConfiguration that *extends* Ignite's
ClientConfiguration
<https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java>.
Once done, it will be possible to configure most of ClientConfiguration
settings which are primitive types. (guess that's how you were doing that
before I joined the review)
- Some fields of the ClientConfiguration class are of custom
non-primitive types and should be added into the
DefaultThinClientConfiguration explicitly via the @ConfigurationBuilder
annotation. Those fields are *sslType, sslProtocol,
sslCtxFactory, txCfg*.

Apart from the DefaultThinClientConfiguration, can we support another
configuration approach when a ClientConfiguration bean is created
programmatically in the source code and the integration uses that bean to
initialize an instance of the thin client (instead of
using DefaultThinClientConfiguration that requires to set the properties
via YAML,etc.). For instance, that's how the ClientConfiguration bean is
created programmatically in Spring Boot
<https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically>and
our integration uses it to initialize an Ignite object.

*Ignite Node (server or thick client)*

Obviously, this one is trickier due to the numerous configuration
parameters of the IgniteConfiguration class
<https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java>
.

So, as you suggested before, we need to select the most frequently used
configuration parameters and add them to the DefaultIgniteConfiguration
with @ConfigurationBuilder annotation. However, it seems reasonable if
DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
that we don't need to list parameters of primitive types). Based on my
experience, I would add the following settings of custom non-primitive
types:

- TcpDiscoverySpi
<https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java>
with
all its fields of primitive types (this should be done easily, right,
without copy-paste?) and its ipFinder field. In the beginning, I would only
support setting TcpDiscoveryVmIpFinder
<https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java>
and
KubernetesIpFinder
<https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java>via
the DefaultIgniteConfiguration.
- DataStorageConfiguration
<https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java>
including
its DataStorageConfiguration.dataRegions property.
- TcpCommunicationSpi
<https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java>
with
its fields of primitive types. Again, here is I'm assuming that we can do
this avoiding copy-pasting. Either through @ConfigurationBuilder (include)
or inheritence.

If the user wants to configure any settings unsupported by
DefaultIgniteConfiguration then, there should be a way to create an
IgniteConfiguration bean programmatically and use it to initialize an
Ignite instance (instead of DefaultIgniteConfiguration).

What's your thinking? Let me know if I'm still missing something.
-
Denis

On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
wrote:

Michael Pollind

Re: Micronaut/Ignite

Dennis,

This is what I came up with with some of the suggestions:
https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
and
https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java

test cases:
https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy

I've tried extending ClientConfiguration but couldn't get the
getters/setters working with ConfigurationBuilder. Instead they are just
placed into wrapper classes. Anyways, I don't think ConfigurationProperty
is supposed to work this way. Also note the table in the documentation is
generated and without a way to exclude things I don't think this will work
cleanly. The other thing I wanted to do was nest @EachProperty in a single
@ConfigurationProperties but that doesn't work with how stuff gets resolved
(https://github.com/micronaut-projects/micronaut-core/issues/3938). so the
cachConfiguration is in another class. This is kind of a first working
example so this will need to be adjusted quite a bit. yea, will need to
setup a way for a user to provide their own bean because there is no way a
full configuration could be covered but I haven't quite worked that out
yet.

If this is ok then I can do another pass on the confluence.

On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]> wrote:

> Michael,
>
> Finally, I figured out Micronaut configuration specificities. What confused
> me before, is that even though the beans configuration in Micronaut looks
> quite similar to the Spring Boot approach, the former automates a lot with
> the help of reflection in runtime. That's how our default Spring Boot
> configuration looks
> <
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
> >
> like. And that's enough to let the users define any possible property of an
> IgniteConfiguration instance as per this example
> <
> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
> >.
> The upside of the reflection.
>
> Anyway, let's go back to our world. That's what I would suggest.
>
> *Ignite Thin Client*
>
>
> - Let's create DefaultThinClientConfiguration that *extends* Ignite's
> ClientConfiguration
> <
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
> >.
> Once done, it will be possible to configure most of ClientConfiguration
> settings which are primitive types. (guess that's how you were doing
> that
> before I joined the review)
> - Some fields of the ClientConfiguration class are of custom
> non-primitive types and should be added into the
> DefaultThinClientConfiguration explicitly via the @ConfigurationBuilder
> annotation. Those fields are *sslType, sslProtocol,
> sslCtxFactory, txCfg*.
>
> Apart from the DefaultThinClientConfiguration, can we support another
> configuration approach when a ClientConfiguration bean is created
> programmatically in the source code and the integration uses that bean to
> initialize an instance of the thin client (instead of
> using DefaultThinClientConfiguration that requires to set the properties
> via YAML,etc.). For instance, that's how the ClientConfiguration bean is
> created programmatically in Spring Boot
> <
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
> >and
> our integration uses it to initialize an Ignite object.
>
> *Ignite Node (server or thick client)*
>
> Obviously, this one is trickier due to the numerous configuration
> parameters of the IgniteConfiguration class
> <
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
> >
> .
>
> So, as you suggested before, we need to select the most frequently used
> configuration parameters and add them to the DefaultIgniteConfiguration
> with @ConfigurationBuilder annotation. However, it seems reasonable if
> DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
> that we don't need to list parameters of primitive types). Based on my
> experience, I would add the following settings of custom non-primitive
> types:
>
> - TcpDiscoverySpi
> <
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
> >
> with
> all its fields of primitive types (this should be done easily, right,
> without copy-paste?) and its ipFinder field. In the beginning, I would
> only
> support setting TcpDiscoveryVmIpFinder
> <
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> >
> and
> KubernetesIpFinder
> <
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
> >via
> the DefaultIgniteConfiguration.
> - DataStorageConfiguration
> <
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
> >
> including
> its DataStorageConfiguration.dataRegions property.
> - TcpCommunicationSpi
> <
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
> >
> with
> its fields of primitive types. Again, here is I'm assuming that we can
> do
> this avoiding copy-pasting. Either through @ConfigurationBuilder
> (include)
> or inheritence.
>
> If the user wants to configure any settings unsupported by
> DefaultIgniteConfiguration then, there should be a way to create an
> IgniteConfiguration bean programmatically and use it to initialize an
> Ignite instance (instead of DefaultIgniteConfiguration).
>
> What's your thinking? Let me know if I'm still missing something.
> -
> Denis
>
>
> On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
> wrote:
>
> > 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
> > > >
> > >
> >
>

dmagda

Re: Micronaut/Ignite

Michael,

Thanks, for verifying.

I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes.

Have a look at how Hazelcast implemented the default configuration for its
thin client by extending ClientConfig class of Hazelcast core:
https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java

Some observations. After extending ClientConfig, their Micronaut's
HazelcastClientConfiguration exposes the following configuration
parameteres:

- Some fields of primitive types that belong to the parent ClientConfig
class. They do this by adding this - *includes = {"properties",
"instanceName", "labels", "userContext", "clusterName"}*
- ClientNetworkConfig, ConnectionRetryConfig, SocketOptions properties
(that exist in the parent ClientConfig class) can not be inherited as
above. Thus, they define those with @ConfigurationBuilder manually.

As a result, their implementation is simple and compact, and here is a
final list of configuration properties:
https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration

Could you check if we can follow a similar approach? Let's start with the
thin client. It's much simpler.

> yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.

That will be outstanding and fit well the design. Let me know if you need
me to help to figure out how to do that with Micronaut.

-
Denis

On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <[hidden email]> wrote:

> Dennis,
>
> This is what I came up with with some of the suggestions:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
> and
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
>
> test cases:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
>
> I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes. Anyways, I don't think ConfigurationProperty
> is supposed to work this way. Also note the table in the documentation is
> generated and without a way to exclude things I don't think this will work
> cleanly. The other thing I wanted to do was nest @EachProperty in a single
> @ConfigurationProperties but that doesn't work with how stuff gets resolved
> (https://github.com/micronaut-projects/micronaut-core/issues/3938). so the
> cachConfiguration is in another class. This is kind of a first working
> example so this will need to be adjusted quite a bit. yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.
>
> If this is ok then I can do another pass on the confluence.
>
> On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]> wrote:
>
> > Michael,
> >
> > Finally, I figured out Micronaut configuration specificities. What
> confused
> > me before, is that even though the beans configuration in Micronaut looks
> > quite similar to the Spring Boot approach, the former automates a lot
> with
> > the help of reflection in runtime. That's how our default Spring Boot
> > configuration looks
> > <
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
> > >
> > like. And that's enough to let the users define any possible property of
> an
> > IgniteConfiguration instance as per this example
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
> > >.
> > The upside of the reflection.
> >
> > Anyway, let's go back to our world. That's what I would suggest.
> >
> > *Ignite Thin Client*
> >
> >
> > - Let's create DefaultThinClientConfiguration that *extends* Ignite's
> > ClientConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
> > >.
> > Once done, it will be possible to configure most of
> ClientConfiguration
> > settings which are primitive types. (guess that's how you were doing
> > that
> > before I joined the review)
> > - Some fields of the ClientConfiguration class are of custom
> > non-primitive types and should be added into the
> > DefaultThinClientConfiguration explicitly via the
> @ConfigurationBuilder
> > annotation. Those fields are *sslType, sslProtocol,
> > sslCtxFactory, txCfg*.
> >
> > Apart from the DefaultThinClientConfiguration, can we support another
> > configuration approach when a ClientConfiguration bean is created
> > programmatically in the source code and the integration uses that bean to
> > initialize an instance of the thin client (instead of
> > using DefaultThinClientConfiguration that requires to set the properties
> > via YAML,etc.). For instance, that's how the ClientConfiguration bean is
> > created programmatically in Spring Boot
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
> > >and
> > our integration uses it to initialize an Ignite object.
> >
> > *Ignite Node (server or thick client)*
> >
> > Obviously, this one is trickier due to the numerous configuration
> > parameters of the IgniteConfiguration class
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
> > >
> > .
> >
> > So, as you suggested before, we need to select the most frequently used
> > configuration parameters and add them to the DefaultIgniteConfiguration
> > with @ConfigurationBuilder annotation. However, it seems reasonable if
> > DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
> > that we don't need to list parameters of primitive types). Based on my
> > experience, I would add the following settings of custom non-primitive
> > types:
> >
> > - TcpDiscoverySpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
> > >
> > with
> > all its fields of primitive types (this should be done easily, right,
> > without copy-paste?) and its ipFinder field. In the beginning, I would
> > only
> > support setting TcpDiscoveryVmIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> > >
> > and
> > KubernetesIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
> > >via
> > the DefaultIgniteConfiguration.
> > - DataStorageConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
> > >
> > including
> > its DataStorageConfiguration.dataRegions property.
> > - TcpCommunicationSpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
> > >
> > with
> > its fields of primitive types. Again, here is I'm assuming that we can
> > do
> > this avoiding copy-pasting. Either through @ConfigurationBuilder
> > (include)
> > or inheritence.
> >
> > If the user wants to configure any settings unsupported by
> > DefaultIgniteConfiguration then, there should be a way to create an
> > IgniteConfiguration bean programmatically and use it to initialize an
> > Ignite instance (instead of DefaultIgniteConfiguration).
> >
> > What's your thinking? Let me know if I'm still missing something.
> > -
> > Denis
> >
> >
> > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
> > wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >
>

Michael Pollind

Re: Micronaut/Ignite

Dennis,

oh, so I made those adjustments. I must have missed it because that didn't occur to me. So DefaultIgniteConfiguration is fine, but ClientConfiguration is a final class so that can't be extended from. This PR is starting to shape up from my perspective, I just need to update the documentation. The other thing I did was add a flag for the associated cache to use micronuat-cache. umm, I'll play with this a bit and see If I can work out something better. ignite.enabled can be false but you can provide your own bean in place but that doesn't seem quite right.

https://github.com/micronaut-projects/micronaut-ignite/pull/33

On Fri, Aug 21, 2020 at 6:29 PM Denis Magda <[hidden email]> wrote:

Michael,

Thanks, for verifying.

I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes.

Have a look at how Hazelcast implemented the default configuration for its
thin client by extending ClientConfig class of Hazelcast core:
https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java

Some observations. After extending ClientConfig, their Micronaut's
HazelcastClientConfiguration exposes the following configuration
parameteres:

- Some fields of primitive types that belong to the parent ClientConfig
class. They do this by adding this - *includes = {"properties",
"instanceName", "labels", "userContext", "clusterName"}*
- ClientNetworkConfig, ConnectionRetryConfig, SocketOptions properties
(that exist in the parent ClientConfig class) can not be inherited as
above. Thus, they define those with @ConfigurationBuilder manually.

As a result, their implementation is simple and compact, and here is a
final list of configuration properties:
https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration

Could you check if we can follow a similar approach? Let's start with the
thin client. It's much simpler.

> yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.

That will be outstanding and fit well the design. Let me know if you need
me to help to figure out how to do that with Micronaut.

-
Denis

On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <[hidden email]> wrote:

> Dennis,
>
> This is what I came up with with some of the suggestions:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
> and
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
>
> test cases:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
>
> I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes. Anyways, I don't think ConfigurationProperty
> is supposed to work this way. Also note the table in the documentation is
> generated and without a way to exclude things I don't think this will work
> cleanly. The other thing I wanted to do was nest @EachProperty in a single
> @ConfigurationProperties but that doesn't work with how stuff gets resolved
> (https://github.com/micronaut-projects/micronaut-core/issues/3938). so the
> cachConfiguration is in another class. This is kind of a first working
> example so this will need to be adjusted quite a bit. yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.
>
> If this is ok then I can do another pass on the confluence.
>
> On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]> wrote:
>
> > Michael,
> >
> > Finally, I figured out Micronaut configuration specificities. What
> confused
> > me before, is that even though the beans configuration in Micronaut looks
> > quite similar to the Spring Boot approach, the former automates a lot
> with
> > the help of reflection in runtime. That's how our default Spring Boot
> > configuration looks
> > <
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
> > >
> > like. And that's enough to let the users define any possible property of
> an
> > IgniteConfiguration instance as per this example
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
> > >.
> > The upside of the reflection.
> >
> > Anyway, let's go back to our world. That's what I would suggest.
> >
> > *Ignite Thin Client*
> >
> >
> > - Let's create DefaultThinClientConfiguration that *extends* Ignite's
> > ClientConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
> > >.
> > Once done, it will be possible to configure most of
> ClientConfiguration
> > settings which are primitive types. (guess that's how you were doing
> > that
> > before I joined the review)
> > - Some fields of the ClientConfiguration class are of custom
> > non-primitive types and should be added into the
> > DefaultThinClientConfiguration explicitly via the
> @ConfigurationBuilder
> > annotation. Those fields are *sslType, sslProtocol,
> > sslCtxFactory, txCfg*.
> >
> > Apart from the DefaultThinClientConfiguration, can we support another
> > configuration approach when a ClientConfiguration bean is created
> > programmatically in the source code and the integration uses that bean to
> > initialize an instance of the thin client (instead of
> > using DefaultThinClientConfiguration that requires to set the properties
> > via YAML,etc.). For instance, that's how the ClientConfiguration bean is
> > created programmatically in Spring Boot
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
> > >and
> > our integration uses it to initialize an Ignite object.
> >
> > *Ignite Node (server or thick client)*
> >
> > Obviously, this one is trickier due to the numerous configuration
> > parameters of the IgniteConfiguration class
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
> > >
> > .
> >
> > So, as you suggested before, we need to select the most frequently used
> > configuration parameters and add them to the DefaultIgniteConfiguration
> > with @ConfigurationBuilder annotation. However, it seems reasonable if
> > DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
> > that we don't need to list parameters of primitive types). Based on my
> > experience, I would add the following settings of custom non-primitive
> > types:
> >
> > - TcpDiscoverySpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
> > >
> > with
> > all its fields of primitive types (this should be done easily, right,
> > without copy-paste?) and its ipFinder field. In the beginning, I would
> > only
> > support setting TcpDiscoveryVmIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> > >
> > and
> > KubernetesIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
> > >via
> > the DefaultIgniteConfiguration.
> > - DataStorageConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
> > >
> > including
> > its DataStorageConfiguration.dataRegions property.
> > - TcpCommunicationSpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
> > >
> > with
> > its fields of primitive types. Again, here is I'm assuming that we can
> > do
> > this avoiding copy-pasting. Either through @ConfigurationBuilder
> > (include)
> > or inheritence.
> >
> > If the user wants to configure any settings unsupported by
> > DefaultIgniteConfiguration then, there should be a way to create an
> > IgniteConfiguration bean programmatically and use it to initialize an
> > Ignite instance (instead of DefaultIgniteConfiguration).
> >
> > What's your thinking? Let me know if I'm still missing something.
> > -
> > Denis
> >
> >
> > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
> > wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >
>

Michael Pollind

Re: Micronaut/Ignite

micronaut will only inject into a nested object if its static and nested in a class. Its a separate final class so it will not work in this case. So DataRegionConfiguration will not get set from the environment. This is a working example but this can be adjusted. I guess it would have to be setup like DefaultIgniteConfiguration. DefaultDataStorageConfiguration and a nested EachProperty? Lets try have a minimum working setup and then add in the missing configurations as we go?

@ConfigurationBuilder(value = "dataStorageConfiguration", excludes = "dataRegionConfigurations")
final DataStorageConfiguration dataStorageConfiguration = new DataStorageConfiguration();

@EachProperty("dataRegionConfigurations")
public static class DefaultDataRegionConfiguration {
    @ConfigurationBuilder()
    DataRegionConfiguration dataRegionConfiguration = new DataRegionConfiguration();

    public DataRegionConfiguration getDataRegionConfiguration() {
        return dataRegionConfiguration;
    }
}

On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind <[hidden email]> wrote:

Dennis,

oh, so I made those adjustments. I must have missed it because that didn't occur to me. So DefaultIgniteConfiguration is fine, but ClientConfiguration is a final class so that can't be extended from. This PR is starting to shape up from my perspective, I just need to update the documentation. The other thing I did was add a flag for the associated cache to use micronuat-cache. umm, I'll play with this a bit and see If I can work out something better. ignite.enabled can be false but you can provide your own bean in place but that doesn't seem quite right.

https://github.com/micronaut-projects/micronaut-ignite/pull/33

On Fri, Aug 21, 2020 at 6:29 PM Denis Magda <[hidden email]> wrote:
Michael,

Thanks, for verifying.

I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes.

Have a look at how Hazelcast implemented the default configuration for its
thin client by extending ClientConfig class of Hazelcast core:
https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java

Some observations. After extending ClientConfig, their Micronaut's
HazelcastClientConfiguration exposes the following configuration
parameteres:

- Some fields of primitive types that belong to the parent ClientConfig
class. They do this by adding this - *includes = {"properties",
"instanceName", "labels", "userContext", "clusterName"}*
- ClientNetworkConfig, ConnectionRetryConfig, SocketOptions properties
(that exist in the parent ClientConfig class) can not be inherited as
above. Thus, they define those with @ConfigurationBuilder manually.

As a result, their implementation is simple and compact, and here is a
final list of configuration properties:
https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration

Could you check if we can follow a similar approach? Let's start with the
thin client. It's much simpler.

> yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.

That will be outstanding and fit well the design. Let me know if you need
me to help to figure out how to do that with Micronaut.

-
Denis

On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <[hidden email]> wrote:

> Dennis,
>
> This is what I came up with with some of the suggestions:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
> and
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
>
> test cases:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
>
> I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes. Anyways, I don't think ConfigurationProperty
> is supposed to work this way. Also note the table in the documentation is
> generated and without a way to exclude things I don't think this will work
> cleanly. The other thing I wanted to do was nest @EachProperty in a single
> @ConfigurationProperties but that doesn't work with how stuff gets resolved
> (https://github.com/micronaut-projects/micronaut-core/issues/3938). so the
> cachConfiguration is in another class. This is kind of a first working
> example so this will need to be adjusted quite a bit. yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.
>
> If this is ok then I can do another pass on the confluence.
>
> On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]> wrote:
>
> > Michael,
> >
> > Finally, I figured out Micronaut configuration specificities. What
> confused
> > me before, is that even though the beans configuration in Micronaut looks
> > quite similar to the Spring Boot approach, the former automates a lot
> with
> > the help of reflection in runtime. That's how our default Spring Boot
> > configuration looks
> > <
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
> > >
> > like. And that's enough to let the users define any possible property of
> an
> > IgniteConfiguration instance as per this example
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
> > >.
> > The upside of the reflection.
> >
> > Anyway, let's go back to our world. That's what I would suggest.
> >
> > *Ignite Thin Client*
> >
> >
> > - Let's create DefaultThinClientConfiguration that *extends* Ignite's
> > ClientConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
> > >.
> > Once done, it will be possible to configure most of
> ClientConfiguration
> > settings which are primitive types. (guess that's how you were doing
> > that
> > before I joined the review)
> > - Some fields of the ClientConfiguration class are of custom
> > non-primitive types and should be added into the
> > DefaultThinClientConfiguration explicitly via the
> @ConfigurationBuilder
> > annotation. Those fields are *sslType, sslProtocol,
> > sslCtxFactory, txCfg*.
> >
> > Apart from the DefaultThinClientConfiguration, can we support another
> > configuration approach when a ClientConfiguration bean is created
> > programmatically in the source code and the integration uses that bean to
> > initialize an instance of the thin client (instead of
> > using DefaultThinClientConfiguration that requires to set the properties
> > via YAML,etc.). For instance, that's how the ClientConfiguration bean is
> > created programmatically in Spring Boot
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
> > >and
> > our integration uses it to initialize an Ignite object.
> >
> > *Ignite Node (server or thick client)*
> >
> > Obviously, this one is trickier due to the numerous configuration
> > parameters of the IgniteConfiguration class
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
> > >
> > .
> >
> > So, as you suggested before, we need to select the most frequently used
> > configuration parameters and add them to the DefaultIgniteConfiguration
> > with @ConfigurationBuilder annotation. However, it seems reasonable if
> > DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
> > that we don't need to list parameters of primitive types). Based on my
> > experience, I would add the following settings of custom non-primitive
> > types:
> >
> > - TcpDiscoverySpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
> > >
> > with
> > all its fields of primitive types (this should be done easily, right,
> > without copy-paste?) and its ipFinder field. In the beginning, I would
> > only
> > support setting TcpDiscoveryVmIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> > >
> > and
> > KubernetesIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
> > >via
> > the DefaultIgniteConfiguration.
> > - DataStorageConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
> > >
> > including
> > its DataStorageConfiguration.dataRegions property.
> > - TcpCommunicationSpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
> > >
> > with
> > its fields of primitive types. Again, here is I'm assuming that we can
> > do
> > this avoiding copy-pasting. Either through @ConfigurationBuilder
> > (include)
> > or inheritence.
> >
> > If the user wants to configure any settings unsupported by
> > DefaultIgniteConfiguration then, there should be a way to create an
> > IgniteConfiguration bean programmatically and use it to initialize an
> > Ignite instance (instead of DefaultIgniteConfiguration).
> >
> > What's your thinking? Let me know if I'm still missing something.
> > -
> > Denis
> >
> >
> > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
> > wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >
>

Michael Pollind

Re: Micronaut/Ignite

here is an updated example what the yaml looks like now.

ignite:

enabled: true

comunication-spi:

local-port: 5555

cache-configurations:

- accounts:

table-name: ACCOUNTS

key-type: String

- books:

table-name: BOOKS

key-type: String

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

micronaut will only inject into a nested object if its static and nested in a class. Its a separate final class so it will not work in this case. So DataRegionConfiguration will not get set from the environment. This is a working example but this can be adjusted. I guess it would have to be setup like DefaultIgniteConfiguration. DefaultDataStorageConfiguration and a nested EachProperty? Lets try have a minimum working setup and then add in the missing configurations as we go?
@ConfigurationBuilder(value = "dataStorageConfiguration", excludes = "dataRegionConfigurations")
final DataStorageConfiguration dataStorageConfiguration = new DataStorageConfiguration();

@EachProperty("dataRegionConfigurations")
public static class DefaultDataRegionConfiguration {
    @ConfigurationBuilder()
    DataRegionConfiguration dataRegionConfiguration = new DataRegionConfiguration();

    public DataRegionConfiguration getDataRegionConfiguration() {
        return dataRegionConfiguration;
    }
}
On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind <[hidden email]> wrote:
Dennis,

oh, so I made those adjustments. I must have missed it because that didn't occur to me. So DefaultIgniteConfiguration is fine, but ClientConfiguration is a final class so that can't be extended from. This PR is starting to shape up from my perspective, I just need to update the documentation. The other thing I did was add a flag for the associated cache to use micronuat-cache. umm, I'll play with this a bit and see If I can work out something better. ignite.enabled can be false but you can provide your own bean in place but that doesn't seem quite right.

https://github.com/micronaut-projects/micronaut-ignite/pull/33

On Fri, Aug 21, 2020 at 6:29 PM Denis Magda <[hidden email]> wrote:
Michael,

Thanks, for verifying.

I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes.

Have a look at how Hazelcast implemented the default configuration for its
thin client by extending ClientConfig class of Hazelcast core:
https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java

Some observations. After extending ClientConfig, their Micronaut's
HazelcastClientConfiguration exposes the following configuration
parameteres:

- Some fields of primitive types that belong to the parent ClientConfig
class. They do this by adding this - *includes = {"properties",
"instanceName", "labels", "userContext", "clusterName"}*
- ClientNetworkConfig, ConnectionRetryConfig, SocketOptions properties
(that exist in the parent ClientConfig class) can not be inherited as
above. Thus, they define those with @ConfigurationBuilder manually.

As a result, their implementation is simple and compact, and here is a
final list of configuration properties:
https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration

Could you check if we can follow a similar approach? Let's start with the
thin client. It's much simpler.

> yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.

That will be outstanding and fit well the design. Let me know if you need
me to help to figure out how to do that with Micronaut.

-
Denis

On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <[hidden email]> wrote:

> Dennis,
>
> This is what I came up with with some of the suggestions:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
> and
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
>
> test cases:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
>
> I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes. Anyways, I don't think ConfigurationProperty
> is supposed to work this way. Also note the table in the documentation is
> generated and without a way to exclude things I don't think this will work
> cleanly. The other thing I wanted to do was nest @EachProperty in a single
> @ConfigurationProperties but that doesn't work with how stuff gets resolved
> (https://github.com/micronaut-projects/micronaut-core/issues/3938). so the
> cachConfiguration is in another class. This is kind of a first working
> example so this will need to be adjusted quite a bit. yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.
>
> If this is ok then I can do another pass on the confluence.
>
> On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]> wrote:
>
> > Michael,
> >
> > Finally, I figured out Micronaut configuration specificities. What
> confused
> > me before, is that even though the beans configuration in Micronaut looks
> > quite similar to the Spring Boot approach, the former automates a lot
> with
> > the help of reflection in runtime. That's how our default Spring Boot
> > configuration looks
> > <
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
> > >
> > like. And that's enough to let the users define any possible property of
> an
> > IgniteConfiguration instance as per this example
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
> > >.
> > The upside of the reflection.
> >
> > Anyway, let's go back to our world. That's what I would suggest.
> >
> > *Ignite Thin Client*
> >
> >
> > - Let's create DefaultThinClientConfiguration that *extends* Ignite's
> > ClientConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
> > >.
> > Once done, it will be possible to configure most of
> ClientConfiguration
> > settings which are primitive types. (guess that's how you were doing
> > that
> > before I joined the review)
> > - Some fields of the ClientConfiguration class are of custom
> > non-primitive types and should be added into the
> > DefaultThinClientConfiguration explicitly via the
> @ConfigurationBuilder
> > annotation. Those fields are *sslType, sslProtocol,
> > sslCtxFactory, txCfg*.
> >
> > Apart from the DefaultThinClientConfiguration, can we support another
> > configuration approach when a ClientConfiguration bean is created
> > programmatically in the source code and the integration uses that bean to
> > initialize an instance of the thin client (instead of
> > using DefaultThinClientConfiguration that requires to set the properties
> > via YAML,etc.). For instance, that's how the ClientConfiguration bean is
> > created programmatically in Spring Boot
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
> > >and
> > our integration uses it to initialize an Ignite object.
> >
> > *Ignite Node (server or thick client)*
> >
> > Obviously, this one is trickier due to the numerous configuration
> > parameters of the IgniteConfiguration class
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
> > >
> > .
> >
> > So, as you suggested before, we need to select the most frequently used
> > configuration parameters and add them to the DefaultIgniteConfiguration
> > with @ConfigurationBuilder annotation. However, it seems reasonable if
> > DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
> > that we don't need to list parameters of primitive types). Based on my
> > experience, I would add the following settings of custom non-primitive
> > types:
> >
> > - TcpDiscoverySpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
> > >
> > with
> > all its fields of primitive types (this should be done easily, right,
> > without copy-paste?) and its ipFinder field. In the beginning, I would
> > only
> > support setting TcpDiscoveryVmIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> > >
> > and
> > KubernetesIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
> > >via
> > the DefaultIgniteConfiguration.
> > - DataStorageConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
> > >
> > including
> > its DataStorageConfiguration.dataRegions property.
> > - TcpCommunicationSpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
> > >
> > with
> > its fields of primitive types. Again, here is I'm assuming that we can
> > do
> > this avoiding copy-pasting. Either through @ConfigurationBuilder
> > (include)
> > or inheritence.
> >
> > If the user wants to configure any settings unsupported by
> > DefaultIgniteConfiguration then, there should be a way to create an
> > IgniteConfiguration bean programmatically and use it to initialize an
> > Ignite instance (instead of DefaultIgniteConfiguration).
> >
> > What's your thinking? Let me know if I'm still missing something.
> > -
> > Denis
> >
> >
> > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
> > wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >
>

Michael Pollind

Re: Micronaut/Ignite

The way i've gone about providing dependencies is that these can be provided through a factory.

@Bean
@Named("default")
@Primary
public IgniteConfiguration igniteConfiguration(DefaultIgniteConfiguration configuration,
                                               Collection<DefaultCacheConfiguration> cacheConfigurations,
                                               Collection<PluginProvider> providers,
                                               Collection<DefaultExecutorConfiguration> executorConfigurations,
                                               Optional<PlatformConfiguration> platformConfigurations,
                                               Optional<CollisionSpi> collisionSpi,
                                               Collection<LoadBalancingSpi> loadBalancingSpis,
                                               Collection<FailoverSpi> failoverSpis,
                                               @ConsistencyId Optional<Serializable> consistencyId,
                                               @IgniteLifecycle Collection<LifecycleBean> lifecycleBeans) {
    configuration.setCacheConfiguration(cacheConfigurations.toArray(new CacheConfiguration[0]))
        .setPluginProviders(providers.toArray(new PluginProvider[0]))
        .setExecutorConfiguration(executorConfigurations.toArray(new ExecutorConfiguration[0]))
        .setPlatformConfiguration(platformConfigurations.orElse(null))
        .setFailoverSpi(failoverSpis.toArray(new FailoverSpi[0]))
        .setLoadBalancingSpi(loadBalancingSpis.toArray(new LoadBalancingSpi[0]))
        .setConsistentId(consistencyId.orElse(null))
        .setLifecycleBeans(lifecycleBeans.toArray(new LifecycleBean[0]))
        .setCollisionSpi(collisionSpi.orElse(null));
    return configuration;
}

On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind <[hidden email]> wrote:

here is an updated example what the yaml looks like now.

ignite:
    enabled: true
    comunication-spi:
        local-port: 5555
    cache-configurations:
    - accounts:
        table-name: ACCOUNTS
        key-type: String
    - books:
        table-name: BOOKS
        key-type: String
On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind <[hidden email]> wrote:
micronaut will only inject into a nested object if its static and nested in a class. Its a separate final class so it will not work in this case. So DataRegionConfiguration will not get set from the environment. This is a working example but this can be adjusted. I guess it would have to be setup like DefaultIgniteConfiguration. DefaultDataStorageConfiguration and a nested EachProperty? Lets try have a minimum working setup and then add in the missing configurations as we go?
@ConfigurationBuilder(value = "dataStorageConfiguration", excludes = "dataRegionConfigurations")
final DataStorageConfiguration dataStorageConfiguration = new DataStorageConfiguration();

@EachProperty("dataRegionConfigurations")
public static class DefaultDataRegionConfiguration {
    @ConfigurationBuilder()
    DataRegionConfiguration dataRegionConfiguration = new DataRegionConfiguration();

    public DataRegionConfiguration getDataRegionConfiguration() {
        return dataRegionConfiguration;
    }
}
On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind <[hidden email]> wrote:
Dennis,

oh, so I made those adjustments. I must have missed it because that didn't occur to me. So DefaultIgniteConfiguration is fine, but ClientConfiguration is a final class so that can't be extended from. This PR is starting to shape up from my perspective, I just need to update the documentation. The other thing I did was add a flag for the associated cache to use micronuat-cache. umm, I'll play with this a bit and see If I can work out something better. ignite.enabled can be false but you can provide your own bean in place but that doesn't seem quite right.

https://github.com/micronaut-projects/micronaut-ignite/pull/33

On Fri, Aug 21, 2020 at 6:29 PM Denis Magda <[hidden email]> wrote:
Michael,

Thanks, for verifying.

I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes.

Have a look at how Hazelcast implemented the default configuration for its
thin client by extending ClientConfig class of Hazelcast core:
https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java

Some observations. After extending ClientConfig, their Micronaut's
HazelcastClientConfiguration exposes the following configuration
parameteres:

- Some fields of primitive types that belong to the parent ClientConfig
class. They do this by adding this - *includes = {"properties",
"instanceName", "labels", "userContext", "clusterName"}*
- ClientNetworkConfig, ConnectionRetryConfig, SocketOptions properties
(that exist in the parent ClientConfig class) can not be inherited as
above. Thus, they define those with @ConfigurationBuilder manually.

As a result, their implementation is simple and compact, and here is a
final list of configuration properties:
https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration

Could you check if we can follow a similar approach? Let's start with the
thin client. It's much simpler.

> yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.

That will be outstanding and fit well the design. Let me know if you need
me to help to figure out how to do that with Micronaut.

-
Denis

On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <[hidden email]> wrote:

> Dennis,
>
> This is what I came up with with some of the suggestions:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
> and
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
>
> test cases:
>
> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
>
> I've tried extending ClientConfiguration but couldn't get the
> getters/setters working with ConfigurationBuilder. Instead they are just
> placed into wrapper classes. Anyways, I don't think ConfigurationProperty
> is supposed to work this way. Also note the table in the documentation is
> generated and without a way to exclude things I don't think this will work
> cleanly. The other thing I wanted to do was nest @EachProperty in a single
> @ConfigurationProperties but that doesn't work with how stuff gets resolved
> (https://github.com/micronaut-projects/micronaut-core/issues/3938). so the
> cachConfiguration is in another class. This is kind of a first working
> example so this will need to be adjusted quite a bit. yea, will need to
> setup a way for a user to provide their own bean because there is no way a
> full configuration could be covered but I haven't quite worked that out
> yet.
>
> If this is ok then I can do another pass on the confluence.
>
> On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]> wrote:
>
> > Michael,
> >
> > Finally, I figured out Micronaut configuration specificities. What
> confused
> > me before, is that even though the beans configuration in Micronaut looks
> > quite similar to the Spring Boot approach, the former automates a lot
> with
> > the help of reflection in runtime. That's how our default Spring Boot
> > configuration looks
> > <
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
> > >
> > like. And that's enough to let the users define any possible property of
> an
> > IgniteConfiguration instance as per this example
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
> > >.
> > The upside of the reflection.
> >
> > Anyway, let's go back to our world. That's what I would suggest.
> >
> > *Ignite Thin Client*
> >
> >
> > - Let's create DefaultThinClientConfiguration that *extends* Ignite's
> > ClientConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
> > >.
> > Once done, it will be possible to configure most of
> ClientConfiguration
> > settings which are primitive types. (guess that's how you were doing
> > that
> > before I joined the review)
> > - Some fields of the ClientConfiguration class are of custom
> > non-primitive types and should be added into the
> > DefaultThinClientConfiguration explicitly via the
> @ConfigurationBuilder
> > annotation. Those fields are *sslType, sslProtocol,
> > sslCtxFactory, txCfg*.
> >
> > Apart from the DefaultThinClientConfiguration, can we support another
> > configuration approach when a ClientConfiguration bean is created
> > programmatically in the source code and the integration uses that bean to
> > initialize an instance of the thin client (instead of
> > using DefaultThinClientConfiguration that requires to set the properties
> > via YAML,etc.). For instance, that's how the ClientConfiguration bean is
> > created programmatically in Spring Boot
> > <
> >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
> > >and
> > our integration uses it to initialize an Ignite object.
> >
> > *Ignite Node (server or thick client)*
> >
> > Obviously, this one is trickier due to the numerous configuration
> > parameters of the IgniteConfiguration class
> > <
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
> > >
> > .
> >
> > So, as you suggested before, we need to select the most frequently used
> > configuration parameters and add them to the DefaultIgniteConfiguration
> > with @ConfigurationBuilder annotation. However, it seems reasonable if
> > DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so
> > that we don't need to list parameters of primitive types). Based on my
> > experience, I would add the following settings of custom non-primitive
> > types:
> >
> > - TcpDiscoverySpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
> > >
> > with
> > all its fields of primitive types (this should be done easily, right,
> > without copy-paste?) and its ipFinder field. In the beginning, I would
> > only
> > support setting TcpDiscoveryVmIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> > >
> > and
> > KubernetesIpFinder
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
> > >via
> > the DefaultIgniteConfiguration.
> > - DataStorageConfiguration
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
> > >
> > including
> > its DataStorageConfiguration.dataRegions property.
> > - TcpCommunicationSpi
> > <
> >
> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
> > >
> > with
> > its fields of primitive types. Again, here is I'm assuming that we can
> > do
> > this avoiding copy-pasting. Either through @ConfigurationBuilder
> > (include)
> > or inheritence.
> >
> > If the user wants to configure any settings unsupported by
> > DefaultIgniteConfiguration then, there should be a way to create an
> > IgniteConfiguration bean programmatically and use it to initialize an
> > Ignite instance (instead of DefaultIgniteConfiguration).
> >
> > What's your thinking? Let me know if I'm still missing something.
> > -
> > Denis
> >
> >
> > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <[hidden email]>
> > wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >
>

dmagda

Re: Micronaut/Ignite

Michael,

Great progress, thanks for your patience. I went ahead and pushed some
changes to your working branch. As you'll see, those changes do some minor
tweaks in the DefaultIgniteThinClientConfiguration class and add Static
with Kubernetes IP finders to the DefaultIgniteConfiguration class. The
IgniteConfigurationSpec fails for now, but I think we'll figure how to
modify the test on the call today.

Also, let's decide if we want to configure IgniteCaches via the Micronaut
configuration. If an application needs to create any caches, it can do this
dynamically after an Ignite instance is started.

-
Denis

On Sat, Aug 22, 2020 at 1:15 PM Michael Pollind <[hidden email]> wrote:

> The way i've gone about providing dependencies is that these can be
> provided through a factory.
>
> @Bean
> @Named("default")
> @Primary
> public IgniteConfiguration igniteConfiguration(DefaultIgniteConfiguration configuration,
> Collection<DefaultCacheConfiguration> cacheConfigurations,
> Collection<PluginProvider> providers,
> Collection<DefaultExecutorConfiguration> executorConfigurations,
> Optional<PlatformConfiguration> platformConfigurations,
> Optional<CollisionSpi> collisionSpi,
> Collection<LoadBalancingSpi> loadBalancingSpis,
> Collection<FailoverSpi> failoverSpis,
> @ConsistencyId Optional<Serializable> consistencyId,
> @IgniteLifecycle Collection<LifecycleBean> lifecycleBeans) {
> configuration.setCacheConfiguration(cacheConfigurations.toArray(new CacheConfiguration[0]))
> .setPluginProviders(providers.toArray(new PluginProvider[0]))
> .setExecutorConfiguration(executorConfigurations.toArray(new ExecutorConfiguration[0]))
> .setPlatformConfiguration(platformConfigurations.orElse(null))
> .setFailoverSpi(failoverSpis.toArray(new FailoverSpi[0]))
> .setLoadBalancingSpi(loadBalancingSpis.toArray(new LoadBalancingSpi[0]))
> .setConsistentId(consistencyId.orElse(null))
> .setLifecycleBeans(lifecycleBeans.toArray(new LifecycleBean[0]))
> .setCollisionSpi(collisionSpi.orElse(null));
> return configuration;
> }
>
>
> On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind <[hidden email]>
> wrote:
>
>> here is an updated example what the yaml looks like now.
>>
>> ignite:
>> enabled: true
>> comunication-spi:
>> local-port: 5555
>> cache-configurations:
>> - accounts:
>> table-name: ACCOUNTS
>> key-type: String
>> - books:
>> table-name: BOOKS
>> key-type: String
>>
>> On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind <[hidden email]>
>> wrote:
>>
>>> micronaut will only inject into a nested object if its static and nested
>>> in a class. Its a separate final class so it will not work in this case. So
>>> DataRegionConfiguration will not get set from the environment. This is a
>>> working example but this can be adjusted. I guess it would have to be
>>> setup like DefaultIgniteConfiguration. DefaultDataStorageConfiguration and
>>> a nested EachProperty? Lets try have a minimum working setup and then add
>>> in the missing configurations as we go?
>>>
>>> @ConfigurationBuilder(value = "dataStorageConfiguration", excludes = "dataRegionConfigurations")
>>> final DataStorageConfiguration dataStorageConfiguration = new DataStorageConfiguration();
>>>
>>> @EachProperty("dataRegionConfigurations")
>>> public static class DefaultDataRegionConfiguration {
>>> @ConfigurationBuilder()
>>> DataRegionConfiguration dataRegionConfiguration = new DataRegionConfiguration();
>>>
>>> public DataRegionConfiguration getDataRegionConfiguration() {
>>> return dataRegionConfiguration;
>>> }
>>> }
>>>
>>>
>>>
>>>
>>> On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind <[hidden email]>
>>> wrote:
>>>
>>>> Dennis,
>>>>
>>>> oh, so I made those adjustments. I must have missed it because that
>>>> didn't occur to me. So DefaultIgniteConfiguration is fine, but
>>>> ClientConfiguration is a final class so that can't be extended from. This
>>>> PR is starting to shape up from my perspective, I just need to update the
>>>> documentation. The other thing I did was add a flag for the associated
>>>> cache to use micronuat-cache. umm, I'll play with this a bit and see If I
>>>> can work out something better. ignite.enabled can be false but you can
>>>> provide your own bean in place but that doesn't seem quite right.
>>>>
>>>> [image: image.png]
>>>>
>>>>
>>>> https://github.com/micronaut-projects/micronaut-ignite/pull/33
>>>>
>>>> On Fri, Aug 21, 2020 at 6:29 PM Denis Magda <[hidden email]> wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> Thanks, for verifying.
>>>>>
>>>>> I've tried extending ClientConfiguration but couldn't get the
>>>>> > getters/setters working with ConfigurationBuilder. Instead they are
>>>>> just
>>>>> > placed into wrapper classes.
>>>>>
>>>>>
>>>>> Have a look at how Hazelcast implemented the default configuration for
>>>>> its
>>>>> thin client by extending ClientConfig class of Hazelcast core:
>>>>>
>>>>> https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java
>>>>>
>>>>> Some observations. After extending ClientConfig, their Micronaut's
>>>>> HazelcastClientConfiguration exposes the following configuration
>>>>> parameteres:
>>>>>
>>>>> - Some fields of primitive types that belong to the parent
>>>>> ClientConfig
>>>>> class. They do this by adding this - *includes = {"properties",
>>>>> "instanceName", "labels", "userContext", "clusterName"}*
>>>>> - ClientNetworkConfig, ConnectionRetryConfig, SocketOptions
>>>>> properties
>>>>> (that exist in the parent ClientConfig class) can not be inherited
>>>>> as
>>>>> above. Thus, they define those with @ConfigurationBuilder manually.
>>>>>
>>>>> As a result, their implementation is simple and compact, and here is a
>>>>> final list of configuration properties:
>>>>>
>>>>> https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration
>>>>>
>>>>> Could you check if we can follow a similar approach? Let's start with
>>>>> the
>>>>> thin client. It's much simpler.
>>>>>
>>>>>
>>>>> > yea, will need to
>>>>> > setup a way for a user to provide their own bean because there is no
>>>>> way a
>>>>> > full configuration could be covered but I haven't quite worked that
>>>>> out
>>>>> > yet.
>>>>>
>>>>>
>>>>> That will be outstanding and fit well the design. Let me know if you
>>>>> need
>>>>> me to help to figure out how to do that with Micronaut.
>>>>>
>>>>>
>>>>> -
>>>>> Denis
>>>>>
>>>>>
>>>>> On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> > Dennis,
>>>>> >
>>>>> > This is what I came up with with some of the suggestions:
>>>>> >
>>>>> >
>>>>> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
>>>>> > and
>>>>> >
>>>>> >
>>>>> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
>>>>> >
>>>>> > test cases:
>>>>> >
>>>>> >
>>>>> https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
>>>>> >
>>>>> > I've tried extending ClientConfiguration but couldn't get the
>>>>> > getters/setters working with ConfigurationBuilder. Instead they are
>>>>> just
>>>>> > placed into wrapper classes. Anyways, I don't think
>>>>> ConfigurationProperty
>>>>> > is supposed to work this way. Also note the table in the
>>>>> documentation is
>>>>> > generated and without a way to exclude things I don't think this
>>>>> will work
>>>>> > cleanly. The other thing I wanted to do was nest @EachProperty in a
>>>>> single
>>>>> > @ConfigurationProperties but that doesn't work with how stuff gets
>>>>> resolved
>>>>> > (https://github.com/micronaut-projects/micronaut-core/issues/3938).
>>>>> so the
>>>>> > cachConfiguration is in another class. This is kind of a first
>>>>> working
>>>>> > example so this will need to be adjusted quite a bit. yea, will need
>>>>> to
>>>>> > setup a way for a user to provide their own bean because there is no
>>>>> way a
>>>>> > full configuration could be covered but I haven't quite worked that
>>>>> out
>>>>> > yet.
>>>>> >
>>>>> > If this is ok then I can do another pass on the confluence.
>>>>> >
>>>>> > On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <[hidden email]>
>>>>> wrote:
>>>>> >
>>>>> > > Michael,
>>>>> > >
>>>>> > > Finally, I figured out Micronaut configuration specificities. What
>>>>> > confused
>>>>> > > me before, is that even though the beans configuration in
>>>>> Micronaut looks
>>>>> > > quite similar to the Spring Boot approach, the former automates a
>>>>> lot
>>>>> > with
>>>>> > > the help of reflection in runtime. That's how our default Spring
>>>>> Boot
>>>>> > > configuration looks
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java
>>>>> > > >
>>>>> > > like. And that's enough to let the users define any possible
>>>>> property of
>>>>> > an
>>>>> > > IgniteConfiguration instance as per this example
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration
>>>>> > > >.
>>>>> > > The upside of the reflection.
>>>>> > >
>>>>> > > Anyway, let's go back to our world. That's what I would suggest.
>>>>> > >
>>>>> > > *Ignite Thin Client*
>>>>> > >
>>>>> > >
>>>>> > > - Let's create DefaultThinClientConfiguration that *extends*
>>>>> Ignite's
>>>>> > > ClientConfiguration
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java
>>>>> > > >.
>>>>> > > Once done, it will be possible to configure most of
>>>>> > ClientConfiguration
>>>>> > > settings which are primitive types. (guess that's how you were
>>>>> doing
>>>>> > > that
>>>>> > > before I joined the review)
>>>>> > > - Some fields of the ClientConfiguration class are of custom
>>>>> > > non-primitive types and should be added into the
>>>>> > > DefaultThinClientConfiguration explicitly via the
>>>>> > @ConfigurationBuilder
>>>>> > > annotation. Those fields are *sslType, sslProtocol,
>>>>> > > sslCtxFactory, txCfg*.
>>>>> > >
>>>>> > > Apart from the DefaultThinClientConfiguration, can we support
>>>>> another
>>>>> > > configuration approach when a ClientConfiguration bean is created
>>>>> > > programmatically in the source code and the integration uses that
>>>>> bean to
>>>>> > > initialize an instance of the thin client (instead of
>>>>> > > using DefaultThinClientConfiguration that requires to set the
>>>>> properties
>>>>> > > via YAML,etc.). For instance, that's how the ClientConfiguration
>>>>> bean is
>>>>> > > created programmatically in Spring Boot
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically
>>>>> > > >and
>>>>> > > our integration uses it to initialize an Ignite object.
>>>>> > >
>>>>> > > *Ignite Node (server or thick client)*
>>>>> > >
>>>>> > > Obviously, this one is trickier due to the numerous configuration
>>>>> > > parameters of the IgniteConfiguration class
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
>>>>> > > >
>>>>> > > .
>>>>> > >
>>>>> > > So, as you suggested before, we need to select the most frequently
>>>>> used
>>>>> > > configuration parameters and add them to the
>>>>> DefaultIgniteConfiguration
>>>>> > > with @ConfigurationBuilder annotation. However, it seems
>>>>> reasonable if
>>>>> > > DefaultIgniteConfiguration will extend Ignite's
>>>>> IgniteConfiguration (so
>>>>> > > that we don't need to list parameters of primitive types). Based
>>>>> on my
>>>>> > > experience, I would add the following settings of custom
>>>>> non-primitive
>>>>> > > types:
>>>>> > >
>>>>> > > - TcpDiscoverySpi
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
>>>>> > > >
>>>>> > > with
>>>>> > > all its fields of primitive types (this should be done easily,
>>>>> right,
>>>>> > > without copy-paste?) and its ipFinder field. In the beginning,
>>>>> I would
>>>>> > > only
>>>>> > > support setting TcpDiscoveryVmIpFinder
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
>>>>> > > >
>>>>> > > and
>>>>> > > KubernetesIpFinder
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
>>>>> > > >via
>>>>> > > the DefaultIgniteConfiguration.
>>>>> > > - DataStorageConfiguration
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
>>>>> > > >
>>>>> > > including
>>>>> > > its DataStorageConfiguration.dataRegions property.
>>>>> > > - TcpCommunicationSpi
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
>>>>> > > >
>>>>> > > with
>>>>> > > its fields of primitive types. Again, here is I'm assuming that
>>>>> we can
>>>>> > > do
>>>>> > > this avoiding copy-pasting. Either through @ConfigurationBuilder
>>>>> > > (include)
>>>>> > > or inheritence.
>>>>> > >
>>>>> > > If the user wants to configure any settings unsupported by
>>>>> > > DefaultIgniteConfiguration then, there should be a way to create an
>>>>> > > IgniteConfiguration bean programmatically and use it to initialize
>>>>> an
>>>>> > > Ignite instance (instead of DefaultIgniteConfiguration).
>>>>> > >
>>>>> > > What's your thinking? Let me know if I'm still missing something.
>>>>> > > -
>>>>> > > Denis
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <
>>>>> [hidden email]>
>>>>> > > wrote:
>>>>> > >
>>>>> > > > 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
>>>>> > > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>

dmagda

Re: Micronaut/Ignite

Michael,

I was thinking over the idea of splitting the ignite-cache module in two
(one for a thick-client based connection and the other for thin client
connections), and would try to avoid this route if possible.

With the @CacheConfig annotation, Micronaut developers can create a generic
implementation that is agnostic to the Ignite connectivity methods, which
is good. While internally, the ignite-cache implementation can decide what
Ignite Cache API to use (the thick or thin client one, depends on the type
of a client you started with our auto-configuration feature). Let’s discuss
all the existing issues here and jump on another call to finalize a
solution if needed.

Denis

On Monday, August 24, 2020, Denis Magda <[hidden email]> wrote:

Not sure, I would probably bring that up in the PR so the micronaut devs
are aware of this. Not sure how the CI will work and what can be arranged
in this case.

On Thu, Aug 27, 2020 at 3:50 PM Denis Magda <[hidden email]> wrote:

> Michael,
>
> The docs look good enough for the release. Once the integration is
> released, I'll update and extend my Micronaut tutorial elucidating on how
> to use the integration in practice for various use cases.
>
> Btw, are the ignite-core and ignite-cache Maven artifacts will be released
> for a specific version of Ignite? Ideally, the version of Ignite needs to
> be set in a pom.xml and the Micronaut integration should pick them up.
>
> Also, what are we doing next - reviewing APIs of the ignite-cache module or
> going through a review process of the ignite-core and merging it first to
> the Micronaut repository?
>
> -
> Denis
>
>
> On Wed, Aug 26, 2020 at 3:35 PM Michael Pollind <[hidden email]>
> wrote:
>
> > Also you need to sign the CLA since you add a commit to my branch.
> >
> > branch: https://github.com/pollend/micronaut-ignite/tree/feature/rework
> > linked PR:
> https://github.com/micronaut-projects/micronaut-ignite/pull/33
> >
> > --
> > Michael Pollind
> >
> > On Wed, Aug 26, 2020 at 3:29 PM Denis Magda <[hidden email]> wrote:
> >
> > > Could you share the full path to the branch? Don't want to pick a wrong
> > one
> > > accidentally.
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Aug 26, 2020 at 2:47 PM Michael Pollind <[hidden email]>
> > > wrote:
> > >
> > > > so that clears up the extra flag for micronaut-cache. just need to
> > > > intercept the default IgniteConfiguration bean and update the
> > > > configuration. if you pull my latest changes from the rework branch
> you
> > > can
> > > > look at the docs for that micronaut module. `./gradlew docs`.
> > Finalizing
> > > > the docs should be the last part of this. The configuration from my
> > > > perspective seems pretty much there. Is there anything else that is
> > > > missing?
> > > >
> > > > On Wed, Aug 26, 2020 at 1:31 PM Denis Magda <[hidden email]>
> wrote:
> > > >
> > > > > 👍 Nice catch!
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Wed, Aug 26, 2020 at 12:16 PM Michael Pollind <
> [hidden email]
> > >
> > > > > wrote:
> > > > >
> > > > > > One thing that just occurred to me for the
> > > DefaultIgniteConfiguration.
> > > > > you
> > > > > > can actually just intercept the bean when it's created. This
> should
> > > let
> > > > > us
> > > > > > use the enable flag from ignite-core for ignite-cache without the
> > > > > > additional flag.
> > > > > >
> > > > > > @Singleton
> > > > > > public class IgniteConfigurationFactoryInterceptor implements
> > > > > > BeanCreatedEventListener<DefaultIgniteConfiguration> {
> > > > > > @Override
> > > > > > public IgniteConfiguration
> > > > > > onCreated(BeanCreatedEvent<DefaultIgniteConfiguration> event) {
> > > > > > IgniteConfiguration configuration = event.getBean();
> > > > > > configuration.setIgniteInstanceName("instance-a");
> > > > > > return configuration;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 26, 2020 at 11:31 AM Denis Magda <[hidden email]>
> > > > wrote:
> > > > > >
> > > > > > > Michael,
> > > > > > >
> > > > > > > Looks terrific! I went ahead and grouped the configuration
> > samples
> > > > by a
> > > > > > > client type:
> > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration
> > > > > > >
> > > > > > > As you see, the "Ignite Thin Client" section is blank for now.
> > > Would
> > > > > you
> > > > > > > mind filling it with configuration options following the format
> > > taken
> > > > > for
> > > > > > > the thick client?
> > > > > > >
> > > > > > > Ping me here once you're ready to review the API and
> > implementation
> > > > of
> > > > > > the
> > > > > > > ignite-caching module.
> > > > > > >
> > > > > > > -
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 25, 2020 at 9:16 PM Michael Pollind <
> > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Here is a sample project I threw together and I've also
> updated
> > > the
> > > > > > wiki
> > > > > > > > just a bit. working on updating the documentation on the
> > > micronaut
> > > > > end.
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration
> > > > > > > > https://github.com/pollend/micronaut-ignite-sample
> > > > > > > >
> > > > > > > > On Mon, Aug 24, 2020 at 6:57 PM Michael Pollind <
> > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > yea, I'm not sure about ignite-cache config. splitting it
> > into
> > > > two
> > > > > > > > modules
> > > > > > > > > seems kind of overly complicated, but I also don't really
> > like
> > > > the
> > > > > > > random
> > > > > > > > > boolean flag. here is the tweaks from the config your
> > provider:
> > > > > > > > > https://github.com/pollend/micronaut-ignite/pull/2
> > > > > > > > >
> > > > > > > > > kind of strange that there are not getters for the
> > > > > > > > > TcpDiscoveryKubernetesIpFinder but there is enough to
> verify
> > > that
> > > > > the
> > > > > > > > > correct ipfinder was set from the unit test i've written.
> > > > > > > > >
> > > > > > > > > static ip finder
> > > > > > > > >
> > > > > > > > > "ignite.enabled" : true,
> > > > > > > > > "ignite.communication-spi.local-port" :
> > > > > > "localhost:1800",
> > > > > > > > > "ignite.discovery-spi.static-ip-finder.enabled" :
> "true",
> > > > > > > > > "ignite.discovery-spi.static-ip-finder.addresses[0]": "
> > > > > > 127.0.0.1:47500
> > > > > > > ",
> > > > > > > > > "ignite.discovery-spi.static-ip-finder.addresses[1]": "
> > > > > > 127.0.0.1:47501
> > > > > > > ",
> > > > > > > > >
> > > > > > > > > kubernetties ip finder
> > > > > > > > >
> > > > > > > > > "ignite.enabled" :
> true,
> > > > > > > > > "ignite.communication-spi.local-port" :
> > > > > > > "localhost:1800",
> > > > > > > > > "ignite.discovery-spi.kubernetes-ip-finder.enabled" :
> > "true",
> > > > > > > > > "ignite.discovery-spi.kubernetes-ip-finder.namespace":
> > > > "HelloWorld"
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Aug 24, 2020 at 6:16 PM Denis Magda <
> > [hidden email]
> > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> Michael,
> > > > > > > > >>
> > > > > > > > >> I was thinking over the idea of splitting the ignite-cache
> > > > module
> > > > > in
> > > > > > > two
> > > > > > > > >> (one for a thick-client based connection and the other for
> > > thin
> > > > > > client
> > > > > > > > >> connections), and would try to avoid this route if
> possible.
> > > > > > > > >>
> > > > > > > > >> With the @CacheConfig annotation, Micronaut developers can
> > > > create
> > > > > a
> > > > > > > > >> generic
> > > > > > > > >> implementation that is agnostic to the Ignite connectivity
> > > > > methods,
> > > > > > > > which
> > > > > > > > >> is good. While internally, the ignite-cache implementation
> > can
> > > > > > decide
> > > > > > > > what
> > > > > > > > >> Ignite Cache API to use (the thick or thin client one,
> > depends
> > > > on
> > > > > > the
> > > > > > > > type
> > > > > > > > >> of a client you started with our auto-configuration
> > feature).
> > > > > Let’s
> > > > > > > > >> discuss
> > > > > > > > >> all the existing issues here and jump on another call to
> > > > finalize
> > > > > a
> > > > > > > > >> solution if needed.
> > > > > > > > >>
> > > > > > > > >> Denis
> > > > > > > > >>
> > > > > > > > >> On Monday, August 24, 2020, Denis Magda <
> [hidden email]>
> > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> > Michael,
> > > > > > > > >> >
> > > > > > > > >> > Great progress, thanks for your patience. I went ahead
> and
> > > > > pushed
> > > > > > > some
> > > > > > > > >> > changes to your working branch. As you'll see, those
> > changes
> > > > do
> > > > > > some
> > > > > > > > >> minor
> > > > > > > > >> > tweaks in the DefaultIgniteThinClientConfiguration class
> > and
> > > > add
> > > > > > > > Static
> > > > > > > > >> > with Kubernetes IP finders to the
> > DefaultIgniteConfiguration
> > > > > > class.
> > > > > > > > The
> > > > > > > > >> > IgniteConfigurationSpec fails for now, but I think we'll
> > > > figure
> > > > > > how
> > > > > > > to
> > > > > > > > >> > modify the test on the call today.
> > > > > > > > >> >
> > > > > > > > >> > Also, let's decide if we want to configure IgniteCaches
> > via
> > > > the
> > > > > > > > >> Micronaut
> > > > > > > > >> > configuration. If an application needs to create any
> > caches,
> > > > it
> > > > > > can
> > > > > > > do
> > > > > > > > >> this
> > > > > > > > >> > dynamically after an Ignite instance is started.
> > > > > > > > >> >
> > > > > > > > >> > -
> > > > > > > > >> > Denis
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > On Sat, Aug 22, 2020 at 1:15 PM Michael Pollind <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > The way i've gone about providing dependencies is that
> > these
> > > > can
> > > > > > be
> > > > > > > > >> > provided through a factory.
> > > > > > > > >> >
> > > > > > > > >> > @Bean
> > > > > > > > >> > @Named("default")
> > > > > > > > >> > @Primary
> > > > > > > > >> > public IgniteConfiguration
> > > > > > > > >> igniteConfiguration(DefaultIgniteConfiguration
> > configuration,
> > > > > > > > >> >
> > > > > > > > >> Collection<DefaultCacheConfiguration> cacheConfigurations,
> > > > > > > > >> >
> > > > > > > > >> Collection<PluginProvider> providers,
> > > > > > > > >> >
> > > > > > > > >> Collection<DefaultExecutorConfiguration>
> > > executorConfigurations,
> > > > > > > > >> >
> > > > > > > > >> Optional<PlatformConfiguration> platformConfigurations,
> > > > > > > > >> >
> > > > > > > Optional<CollisionSpi>
> > > > > > > > >> collisionSpi,
> > > > > > > > >> >
> > > > > > > > >> Collection<LoadBalancingSpi> loadBalancingSpis,
> > > > > > > > >> >
> > > > > > > Collection<FailoverSpi>
> > > > > > > > >> failoverSpis,
> > > > > > > > >> >
> > > @ConsistencyId
> > > > > > > > >> Optional<Serializable> consistencyId,
> > > > > > > > >> >
> > > > @IgniteLifecycle
> > > > > > > > >> Collection<LifecycleBean> lifecycleBeans) {
> > > > > > > > >> >
> > > > > > > >
> > > > configuration.setCacheConfiguration(cacheConfigurations.toArray(new
> > > > > > > > >> CacheConfiguration[0]))
> > > > > > > > >> > .setPluginProviders(providers.toArray(new
> > > > > > > PluginProvider[0]))
> > > > > > > > >> >
> > > > > > .setExecutorConfiguration(executorConfigurations.toArray(new
> > > > > > > > >> ExecutorConfiguration[0]))
> > > > > > > > >> >
> > > > > > > .setPlatformConfiguration(platformConfigurations.orElse(null))
> > > > > > > > >> > .setFailoverSpi(failoverSpis.toArray(new
> > > > > FailoverSpi[0]))
> > > > > > > > >> >
> .setLoadBalancingSpi(loadBalancingSpis.toArray(new
> > > > > > > > >> LoadBalancingSpi[0]))
> > > > > > > > >> > .setConsistentId(consistencyId.orElse(null))
> > > > > > > > >> > .setLifecycleBeans(lifecycleBeans.toArray(new
> > > > > > > > LifecycleBean[0]))
> > > > > > > > >> > .setCollisionSpi(collisionSpi.orElse(null));
> > > > > > > > >> > return configuration;
> > > > > > > > >> > }
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > here is an updated example what the yaml looks like now.
> > > > > > > > >> >
> > > > > > > > >> > ignite:
> > > > > > > > >> > enabled: true
> > > > > > > > >> > comunication-spi:
> > > > > > > > >> > local-port: 5555
> > > > > > > > >> > cache-configurations:
> > > > > > > > >> > - accounts:
> > > > > > > > >> > table-name: ACCOUNTS
> > > > > > > > >> > key-type: String
> > > > > > > > >> > - books:
> > > > > > > > >> > table-name: BOOKS
> > > > > > > > >> > key-type: String
> > > > > > > > >> >
> > > > > > > > >> > On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind <
> > > > > > > [hidden email]>
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > micronaut will only inject into a nested object if its
> > > static
> > > > > and
> > > > > > > > nested
> > > > > > > > >> > in a class. Its a separate final class so it will not
> work
> > > in
> > > > > this
> > > > > > > > >> case. So
> > > > > > > > >> > DataRegionConfiguration will not get set from the
> > > environment.
> > > > > > This
> > > > > > > > is a
> > > > > > > > >> > working example but this can be adjusted. I guess it
> > would
> > > > have
> > > > > > to
> > > > > > > be
> > > > > > > > >> > setup like DefaultIgniteConfiguration.
> > > > > > > DefaultDataStorageConfiguration
> > > > > > > > >> > and a nested EachProperty? Lets try have a minimum
> working
> > > > setup
> > > > > > and
> > > > > > > > >> then
> > > > > > > > >> > add in the missing configurations as we go?
> > > > > > > > >> >
> > > > > > > > >> > @ConfigurationBuilder(value =
> "dataStorageConfiguration",
> > > > > > excludes =
> > > > > > > > >> "dataRegionConfigurations")
> > > > > > > > >> > final DataStorageConfiguration dataStorageConfiguration
> =
> > > new
> > > > > > > > >> DataStorageConfiguration();
> > > > > > > > >> >
> > > > > > > > >> > @EachProperty("dataRegionConfigurations")
> > > > > > > > >> > public static class DefaultDataRegionConfiguration {
> > > > > > > > >> > @ConfigurationBuilder()
> > > > > > > > >> > DataRegionConfiguration dataRegionConfiguration =
> new
> > > > > > > > >> DataRegionConfiguration();
> > > > > > > > >> >
> > > > > > > > >> > public DataRegionConfiguration
> > > > getDataRegionConfiguration()
> > > > > {
> > > > > > > > >> > return dataRegionConfiguration;
> > > > > > > > >> > }
> > > > > > > > >> > }
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > Dennis,
> > > > > > > > >> >
> > > > > > > > >> > oh, so I made those adjustments. I must have missed it
> > > because
> > > > > > that
> > > > > > > > >> didn't
> > > > > > > > >> > occur to me. So DefaultIgniteConfiguration is fine, but
> > > > > > > > >> ClientConfiguration
> > > > > > > > >> > is a final class so that can't be extended from. This PR
> > is
> > > > > > starting
> > > > > > > > to
> > > > > > > > >> > shape up from my perspective, I just need to update the
> > > > > > > documentation.
> > > > > > > > >> The
> > > > > > > > >> > other thing I did was add a flag for the associated
> cache
> > to
> > > > use
> > > > > > > > >> > micronuat-cache. umm, I'll play with this a bit and see
> > If I
> > > > can
> > > > > > > work
> > > > > > > > >> out
> > > > > > > > >> > something better. ignite.enabled can be false but you
> can
> > > > > provide
> > > > > > > your
> > > > > > > > >> own
> > > > > > > > >> > bean in place but that doesn't seem quite right.
> > > > > > > > >> >
> > > > > > > > >> > [image: image.png]
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > https://github.com/micronaut-projects/micronaut-ignite/pull/33
> > > > > > > > >> >
> > > > > > > > >> > On Fri, Aug 21, 2020 at 6:29 PM Denis Magda <
> > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > Michael,
> > > > > > > > >> >
> > > > > > > > >> > Thanks, for verifying.
> > > > > > > > >> >
> > > > > > > > >> > I've tried extending ClientConfiguration but couldn't
> get
> > > the
> > > > > > > > >> > > getters/setters working with ConfigurationBuilder.
> > Instead
> > > > > they
> > > > > > > are
> > > > > > > > >> just
> > > > > > > > >> > > placed into wrapper classes.
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > Have a look at how Hazelcast implemented the default
> > > > > configuration
> > > > > > > for
> > > > > > > > >> its
> > > > > > > > >> > thin client by extending ClientConfig class of Hazelcast
> > > core:
> > > > > > > > >> >
> > https://github.com/micronaut-projects/micronaut-cache/blob/
> > > > > > > > >> >
> > > > > master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/
> > > > > > > > >> > HazelcastClientConfiguration.java
> > > > > > > > >> >
> > > > > > > > >> > Some observations. After extending ClientConfig, their
> > > > > Micronaut's
> > > > > > > > >> > HazelcastClientConfiguration exposes the following
> > > > configuration
> > > > > > > > >> > parameteres:
> > > > > > > > >> >
> > > > > > > > >> > - Some fields of primitive types that belong to the
> > > parent
> > > > > > > > >> ClientConfig
> > > > > > > > >> > class. They do this by adding this - *includes =
> > > > > {"properties",
> > > > > > > > >> > "instanceName", "labels", "userContext",
> > "clusterName"}*
> > > > > > > > >> > - ClientNetworkConfig, ConnectionRetryConfig,
> > > SocketOptions
> > > > > > > > >> properties
> > > > > > > > >> > (that exist in the parent ClientConfig class) can not
> > be
> > > > > > > inherited
> > > > > > > > as
> > > > > > > > >> > above. Thus, they define those with
> > @ConfigurationBuilder
> > > > > > > manually.
> > > > > > > > >> >
> > > > > > > > >> > As a result, their implementation is simple and compact,
> > and
> > > > > here
> > > > > > > is a
> > > > > > > > >> > final list of configuration properties:
> > > > > > > > >> > https://micronaut-projects.github.io/micronaut-cache/
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > >
> > > >
> > snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration
> > > > > > > > >> >
> > > > > > > > >> > Could you check if we can follow a similar approach?
> Let's
> > > > start
> > > > > > > with
> > > > > > > > >> the
> > > > > > > > >> > thin client. It's much simpler.
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > > yea, will need to
> > > > > > > > >> > > setup a way for a user to provide their own bean
> because
> > > > there
> > > > > > is
> > > > > > > no
> > > > > > > > >> way
> > > > > > > > >> > a
> > > > > > > > >> > > full configuration could be covered but I haven't
> quite
> > > > worked
> > > > > > > that
> > > > > > > > >> out
> > > > > > > > >> > > yet.
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > That will be outstanding and fit well the design. Let me
> > > know
> > > > if
> > > > > > you
> > > > > > > > >> need
> > > > > > > > >> > me to help to figure out how to do that with Micronaut.
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > -
> > > > > > > > >> > Denis
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Dennis,
> > > > > > > > >> > >
> > > > > > > > >> > > This is what I came up with with some of the
> > suggestions:
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > https://github.com/micronaut-projects/micronaut-ignite/blob/
> > > > > > > > >> >
> 3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/
> > > > > > > > >> >
> > > > > > > >
> > > > >
> > main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.
> > > > > > > > >> > java
> > > > > > > > >> > > and
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > https://github.com/micronaut-projects/micronaut-ignite/blob/
> > > > > > > > >> >
> 3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java
> > > > > > > > >> > >
> > > > > > > > >> > > test cases:
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > https://github.com/micronaut-projects/micronaut-ignite/blob/
> > > > > > > > >> >
> 3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/
> > > > > > > > >> >
> > > test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy
> > > > > > > > >> > >
> > > > > > > > >> > > I've tried extending ClientConfiguration but couldn't
> > get
> > > > the
> > > > > > > > >> > > getters/setters working with ConfigurationBuilder.
> > Instead
> > > > > they
> > > > > > > are
> > > > > > > > >> just
> > > > > > > > >> > > placed into wrapper classes. Anyways, I don't think
> > > > > > > > >> ConfigurationProperty
> > > > > > > > >> > > is supposed to work this way. Also note the table in
> the
> > > > > > > > >> documentation is
> > > > > > > > >> > > generated and without a way to exclude things I don't
> > > think
> > > > > this
> > > > > > > > will
> > > > > > > > >> > work
> > > > > > > > >> > > cleanly. The other thing I wanted to do was nest
> > > > @EachProperty
> > > > > > in
> > > > > > > a
> > > > > > > > >> > single
> > > > > > > > >> > > @ConfigurationProperties but that doesn't work with
> how
> > > > stuff
> > > > > > gets
> > > > > > > > >> > resolved
> > > > > > > > >> > > (
> > > > > > https://github.com/micronaut-projects/micronaut-core/issues/3938
> > > > > > > ).
> > > > > > > > >> so
> > > > > > > > >> > the
> > > > > > > > >> > > cachConfiguration is in another class. This is kind
> of a
> > > > first
> > > > > > > > working
> > > > > > > > >> > > example so this will need to be adjusted quite a bit.
> > yea,
> > > > > will
> > > > > > > need
> > > > > > > > >> to
> > > > > > > > >> > > setup a way for a user to provide their own bean
> because
> > > > there
> > > > > > is
> > > > > > > no
> > > > > > > > >> way
> > > > > > > > >> > a
> > > > > > > > >> > > full configuration could be covered but I haven't
> quite
> > > > worked
> > > > > > > that
> > > > > > > > >> out
> > > > > > > > >> > > yet.
> > > > > > > > >> > >
> > > > > > > > >> > > If this is ok then I can do another pass on the
> > > confluence.
> > > > > > > > >> > >
> > > > > > > > >> > > On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <
> > > > > [hidden email]>
> > > > > > > > >> wrote:
> > > > > > > > >> > >
> > > > > > > > >> > > > Michael,
> > > > > > > > >> > > >
> > > > > > > > >> > > > Finally, I figured out Micronaut configuration
> > > > > specificities.
> > > > > > > What
> > > > > > > > >> > > confused
> > > > > > > > >> > > > me before, is that even though the beans
> configuration
> > > in
> > > > > > > > Micronaut
> > > > > > > > >> > looks
> > > > > > > > >> > > > quite similar to the Spring Boot approach, the
> former
> > > > > > automates
> > > > > > > a
> > > > > > > > >> lot
> > > > > > > > >> > > with
> > > > > > > > >> > > > the help of reflection in runtime. That's how our
> > > default
> > > > > > Spring
> > > > > > > > >> Boot
> > > > > > > > >> > > > configuration looks
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > https://github.com/apache/ignite-extensions/blob/master/
> > > > > > > > >> > modules/spring-boot-thin-client-autoconfigure-ext/src/
> > > > > > > > >> >
> > > > main/java/org/apache/ignite/springframework/boot/autoconfigure/
> > > > > > > > >> > IgniteClientConfigurer.java
> > > > > > > > >> > > > >
> > > > > > > > >> > > > like. And that's enough to let the users define any
> > > > possible
> > > > > > > > >> property
> > > > > > > > >> > of
> > > > > > > > >> > > an
> > > > > > > > >> > > > IgniteConfiguration instance as per this example
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > > https://apacheignite-mix.readme.io/docs/spring-boot#
> > > > > > > > >> > set-ignite-up-via-spring-boot-configuration
> > > > > > > > >> > > > >.
> > > > > > > > >> > > > The upside of the reflection.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Anyway, let's go back to our world. That's what I
> > would
> > > > > > suggest.
> > > > > > > > >> > > >
> > > > > > > > >> > > > *Ignite Thin Client*
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > - Let's create DefaultThinClientConfiguration
> that
> > > > > > *extends*
> > > > > > > > >> > Ignite's
> > > > > > > > >> > > > ClientConfiguration
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > > > >> > core/src/main/java/org/apache/ignite/configuration/
> > > > > > > > >> > ClientConfiguration.java
> > > > > > > > >> > > > >.
> > > > > > > > >> > > > Once done, it will be possible to configure most
> of
> > > > > > > > >> > > ClientConfiguration
> > > > > > > > >> > > > settings which are primitive types. (guess that's
> > how
> > > > you
> > > > > > > were
> > > > > > > > >> doing
> > > > > > > > >> > > > that
> > > > > > > > >> > > > before I joined the review)
> > > > > > > > >> > > > - Some fields of the ClientConfiguration class
> are
> > of
> > > > > > custom
> > > > > > > > >> > > > non-primitive types and should be added into the
> > > > > > > > >> > > > DefaultThinClientConfiguration explicitly via the
> > > > > > > > >> > > @ConfigurationBuilder
> > > > > > > > >> > > > annotation. Those fields are *sslType,
> sslProtocol,
> > > > > > > > >> > > > sslCtxFactory, txCfg*.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Apart from the DefaultThinClientConfiguration, can
> we
> > > > > support
> > > > > > > > >> another
> > > > > > > > >> > > > configuration approach when a ClientConfiguration
> bean
> > > is
> > > > > > > created
> > > > > > > > >> > > > programmatically in the source code and the
> > integration
> > > > uses
> > > > > > > that
> > > > > > > > >> bean
> > > > > > > > >> > to
> > > > > > > > >> > > > initialize an instance of the thin client (instead
> of
> > > > > > > > >> > > > using DefaultThinClientConfiguration that requires
> to
> > > set
> > > > > the
> > > > > > > > >> > properties
> > > > > > > > >> > > > via YAML,etc.). For instance, that's how the
> > > > > > ClientConfiguration
> > > > > > > > >> bean
> > > > > > > > >> > is
> > > > > > > > >> > > > created programmatically in Spring Boot
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >>
> > > > > > >
> > > > >
> > >
> https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-
> > > > > > > > >> > programmatically
> > > > > > > > >> > > > >and
> > > > > > > > >> > > > our integration uses it to initialize an Ignite
> > object.
> > > > > > > > >> > > >
> > > > > > > > >> > > > *Ignite Node (server or thick client)*
> > > > > > > > >> > > >
> > > > > > > > >> > > > Obviously, this one is trickier due to the numerous
> > > > > > > configuration
> > > > > > > > >> > > > parameters of the IgniteConfiguration class
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > > > >> > core/src/main/java/org/apache/ignite/configuration/
> > > > > > > > >> > IgniteConfiguration.java
> > > > > > > > >> > > > >
> > > > > > > > >> > > > .
> > > > > > > > >> > > >
> > > > > > > > >> > > > So, as you suggested before, we need to select the
> > most
> > > > > > > frequently
> > > > > > > > >> used
> > > > > > > > >> > > > configuration parameters and add them to the
> > > > > > > > >> DefaultIgniteConfiguration
> > > > > > > > >> > > > with @ConfigurationBuilder annotation. However, it
> > seems
> > > > > > > > reasonable
> > > > > > > > >> if
> > > > > > > > >> > > > DefaultIgniteConfiguration will extend Ignite's
> > > > > > > > IgniteConfiguration
> > > > > > > > >> (so
> > > > > > > > >> > > > that we don't need to list parameters of primitive
> > > types).
> > > > > > Based
> > > > > > > > on
> > > > > > > > >> my
> > > > > > > > >> > > > experience, I would add the following settings of
> > custom
> > > > > > > > >> non-primitive
> > > > > > > > >> > > > types:
> > > > > > > > >> > > >
> > > > > > > > >> > > > - TcpDiscoverySpi
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > >
> > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 1700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/
> > > > > > > > >> > TcpDiscoverySpi.java
> > > > > > > > >> > > > >
> > > > > > > > >> > > > with
> > > > > > > > >> > > > all its fields of primitive types (this should be
> > > done
> > > > > > > easily,
> > > > > > > > >> > right,
> > > > > > > > >> > > > without copy-paste?) and its ipFinder field. In
> the
> > > > > > > beginning,
> > > > > > > > I
> > > > > > > > >> > would
> > > > > > > > >> > > > only
> > > > > > > > >> > > > support setting TcpDiscoveryVmIpFinder
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > >
> > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17
> > > > > > > > >> > 1700a928eb/modules/core/src/main/java/org/apache/ignite/
> > > > > > > > >> >
> spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
> > > > > > > > >> > > > >
> > > > > > > > >> > > > and
> > > > > > > > >> > > > KubernetesIpFinder
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > >
> > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17
> > > > > > > > >> > 1700a928eb/modules/kubernetes/src/main/java/org/apache/
> > > > > > > > >> > ignite/spi/discovery/tcp/ipfinder/kubernetes/
> > > > > > > > >> > TcpDiscoveryKubernetesIpFinder.java
> > > > > > > > >> > > > >via
> > > > > > > > >> > > > the DefaultIgniteConfiguration.
> > > > > > > > >> > > > - DataStorageConfiguration
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > >
> > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17
> > > > > > > > >> >
> > > > > > >
> > > >
> 1700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/
> > > > > > > > >> > DataStorageConfiguration.java
> > > > > > > > >> > > > >
> > > > > > > > >> > > > including
> > > > > > > > >> > > > its DataStorageConfiguration.dataRegions
> property.
> > > > > > > > >> > > > - TcpCommunicationSpi
> > > > > > > > >> > > > <
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > >
> > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa17
> > > > > > > > >> > 1700a928eb/modules/core/src/main/java/org/apache/ignite/
> > > > > > > > >> > spi/communication/tcp/TcpCommunicationSpi.java
> > > > > > > > >> > > > >
> > > > > > > > >> > > > with
> > > > > > > > >> > > > its fields of primitive types. Again, here is I'm
> > > > > assuming
> > > > > > > that
> > > > > > > > >> we
> > > > > > > > >> > can
> > > > > > > > >> > > > do
> > > > > > > > >> > > > this avoiding copy-pasting. Either through
> > > > > > > > @ConfigurationBuilder
> > > > > > > > >> > > > (include)
> > > > > > > > >> > > > or inheritence.
> > > > > > > > >> > > >
> > > > > > > > >> > > > If the user wants to configure any settings
> > unsupported
> > > by
> > > > > > > > >> > > > DefaultIgniteConfiguration then, there should be a
> way
> > > to
> > > > > > create
> > > > > > > > an
> > > > > > > > >> > > > IgniteConfiguration bean programmatically and use it
> > to
> > > > > > > initialize
> > > > > > > > >> an
> > > > > > > > >> > > > Ignite instance (instead of
> > DefaultIgniteConfiguration).
> > > > > > > > >> > > >
> > > > > > > > >> > > > What's your thinking? Let me know if I'm still
> missing
> > > > > > > something.
> > > > > > > > >> > > > -
> > > > > > > > >> > > > Denis
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <
> > > > > > > > >> [hidden email]
> > > > > > > > >> > >
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > 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
> > > > > > > > >> > > >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> -
> > > > > > > > >> Denis
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

123