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 <dma...@apache.org> 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 <mpoll...@gmail.com>
> 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 <mpoll...@gmail.com>
> 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 <mpoll...@gmail.com>
> 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 <mpoll...@gmail.com>
> 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 <dma...@apache.org> 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 <mpoll...@gmail.com>
> 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 <dma...@apache.org> 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 <saikat.mai...@gmail.com
> >
> > > 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 <mpoll...@gmail.com>
> > > > 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 <dma...@apache.org>
> > 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 <
> mpoll...@gmail.com
> > >
> > > > > 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 <dma...@apache.org
> >
> > > > 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 <
> > > > mpoll...@gmail.com
> > > > > >
> > > > > > > > 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 <
> > > > > mpoll...@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> The main reason why I was using the spring bean definition
> > was
> > > > > > mainly
> > > > > > > > for
> > > > > > > > >> convenience and I'm not sure what fields are the most
> > > relevant.
> > > > > Will
> > > > > > > > have
> > > > > > > > >> to be kind of specific since the configuration might get a
> > > > little
> > > > > > > > >> complicated. The other thing you can do is use
> > > > > > > > >>
> > > > > > > > https://docs.micronaut.io/latest/api/io/micronaut/core/
> > > > > > > convert/format/MapFormat.html
> > > > > > > > >> which will just map fields and values and you can pass
> that
> > to
> > > > > > > somewhere
> > > > > > > > >> else to be manage it.
> > > > > > > > >>
> > > > > > > > >> so you will need to do something like this as follows:
> > > > > > > > >>
> > > > > > > > >> private final String name;
> > > > > > > > >> @ConfigurationBuilder()
> > > > > > > > >> private IgniteConfiguration igniteConfiguration = new
> > > > > > > > IgniteConfiguration();
> > > > > > > > >> @ConfigurationBuilder(value = "communicationSpi")
> > > > > > > > >> private TcpCommunicationSpi communicationSpi = new
> > > > > > > > TcpCommunicationSpi();
> > > > > > > > >>
> > > > > > > > >> [image: image.png]
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> On Tue, Aug 18, 2020 at 11:05 PM Michael Pollind <
> > > > > > mpoll...@gmail.com>
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >>> Its whatever is setup by default when the object is
> > > declared. I
> > > > > > think
> > > > > > > > we
> > > > > > > > >>> will have to define multiple ConfigurationBuilders If i'm
> > not
> > > > > > > mistaken
> > > > > > > > for
> > > > > > > > >>> the IgniteConfiguration. you don't need to provide the
> > name
> > > > > since
> > > > > > > > that is
> > > > > > > > >>> provided by the key for each configuration under
> > > EachProperty.
> > > > > The
> > > > > > > > name is
> > > > > > > > >>> the qualified name that refers to that bean and also the
> > same
> > > > > > > > qualifier for
> > > > > > > > >>> the Ignite instance. For the most part will just use the
> > > > primary
> > > > > > bean
> > > > > > > > for
> > > > > > > > >>> most part. I think you can only have one cache instance
> > > active
> > > > > at a
> > > > > > > > time.
> > > > > > > > >>> The current way I have it setup is the primary bean is
> used
> > > by
> > > > > > > default
> > > > > > > > so
> > > > > > > > >>> you won't be able to use micronaut-cache with anything
> but
> > > the
> > > > > > > default
> > > > > > > > >>> bean. I guess one can override the other if the
> > configuration
> > > > is
> > > > > > > > present.
> > > > > > > > >>> One problem I see is micronaut-cache. We can only use one
> > > > > instance
> > > > > > of
> > > > > > > > >>> DynamicCache but I need to verify how that works again.
> By
> > > > > default
> > > > > > > the
> > > > > > > > >>> thick client instance will replace the thin-client
> > > DynamicCache
> > > > > if
> > > > > > > that
> > > > > > > > >>> would be ok?
> > > > > > > > >>>
> > > > > > > > >>> ignite:
> > > > > > > > >>> thick-clients:
> > > > > > > > >>> default: <--- primary bean
> > > > > > > > >>> ...
> > > > > > > > >>> second-bean:
> > > > > > > > >>> ...
> > > > > > > > >>> thin-clients:
> > > > > > > > >>> default: <--- primary bean
> > > > > > > > >>> ...
> > > > > > > > >>> second-bean:
> > > > > > > > >>> ....
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > https://docs.micronaut.io/latest/api/io/micronaut/
> > > > > > > context/annotation/Requires.html
> > > > > > > > >>>
> > > > > > > > >>> On Tue, Aug 18, 2020 at 10:13 PM Denis Magda <
> > > > dma...@apache.org>
> > > > > > > > wrote:
> > > > > > > > >>>
> > > > > > > > >>>> >
> > > > > > > > >>>> > oh, so we probably don't need to work with multiple
> > > > instances.
> > > > > > > This
> > > > > > > > >>>> is what
> > > > > > > > >>>> > I have in the current master branch.
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> In most cases, people start a single instance of a thick
> > or
> > > > thin
> > > > > > > > client
> > > > > > > > >>>> per
> > > > > > > > >>>> application. The clients are multi-threaded and can
> > utilize
> > > > all
> > > > > > the
> > > > > > > > CPUs
> > > > > > > > >>>> effectively. However, it's not harmful to have the
> ability
> > > to
> > > > > > > > configure
> > > > > > > > >>>> several clients per application. As far as I understand,
> > > > > Micronaut
> > > > > > > > >>>> distinguishes clients per the
> > > "IgniteClientConfiguration.name"
> > > > > > > > property,
> > > > > > > > >>>> right?
> > > > > > > > >>>>
> > > > > > > > >>>> So what defaults are set for IgniteConfiguration?
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> Does it matter to Micronaut what those defaults are? By
> > > > looking
> > > > > at
> > > > > > > the
> > > > > > > > >>>> IgniteThinClientConfiguration
> > > > > > > > >>>> <
> > > > > > > > >>>>
> > > > > > > > https://micronaut-projects.github.io/micronaut-ignite/
> > > > > > > snapshot/api/io/micronaut/ignite/configuration/
> > > > > > > IgniteThinClientConfiguration.html
> > > > > > > > >>>> >,
> > > > > > > > >>>> that defines
> > > > org.apache.ignite.configuration.ClientConfiguration
> > > > > > > > >>>> property
> > > > > > > > >>>> (under the name of "configuration"), I see that
> Micronaut
> > > > could
> > > > > > > > >>>> introspect
> > > > > > > > >>>> all the fields of the ClientConfiguration and prepared
> > these
> > > > > > > > properties
> > > > > > > > >>>> table
> > > > > > > > >>>> <
> > > > > > > > >>>>
> > > > > > > > https://micronaut-projects.github.io/micronaut-ignite/
> > > > > > > snapshot/guide/#io.micronaut.ignite.configuration.
> > > > > > > IgniteThinClientConfiguration
> > > > > > > > >>>> >.
> > > > > > > > >>>> For me, it means that whenever I am configuring the thin
> > > > client
> > > > > > in a
> > > > > > > > >>>> YAML
> > > > > > > > >>>> file, Micronaut will create an instance of the
> > > > > ClientConfiguration
> > > > > > > > >>>> (Ignite
> > > > > > > > >>>> sets the defaults), and then I can override some
> settings
> > > such
> > > > > as
> > > > > > > > >>>> "addresses" or "enablePartitionAwareness". Does this
> sound
> > > > > > accurate
> > > > > > > > >>>> concerning Micronaut?
> > > > > > > > >>>>
> > > > > > > > >>>> Jumping back to the IgniteConfiguration, I would just
> swap
> > > the
> > > > > > > "path"
> > > > > > > > >>>> that
> > > > > > > > >>>> is the String with the "config" that is
> > IgniteConfiguration.
> > > > > Then
> > > > > > > let
> > > > > > > > >>>> Ignite take care of the IgniteConfiguration defaults and
> > > > allow a
> > > > > > > > >>>> developer
> > > > > > > > >>>> to override some defaults (such as discoverySPI.ipFinder
> > or
> > > > > memory
> > > > > > > > >>>> settings). Just in case, you can find
> IgniteConfiguration
> > > > > defaults
> > > > > > > > here
> > > > > > > > >>>> <
> > > > > > > > >>>>
> > > > > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > > core/src/main/java/org/apache/ignite/configuration/
> > > > > > > IgniteConfiguration.java
> > > > > > > > >>>> >
> > > > > > > > >>>> .
> > > > > > > > >>>>
> > > > > > > > >>>> -
> > > > > > > > >>>> Denis
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> On Tue, Aug 18, 2020 at 8:59 PM Michael Pollind <
> > > > > > mpoll...@gmail.com
> > > > > > > >
> > > > > > > > >>>> wrote:
> > > > > > > > >>>>
> > > > > > > > >>>> > oh, so we probably don't need to work with multiple
> > > > instances.
> > > > > > > This
> > > > > > > > >>>> is what
> > > > > > > > >>>> > I have in the current master branch. I believe I was
> > > > > originally
> > > > > > > > >>>> trying to
> > > > > > > > >>>> > set-up the configuration with the default ignite
> > instance
> > > > but
> > > > > > > found
> > > > > > > > I
> > > > > > > > >>>> > couldn't cover enough of the configuration. So what
> > > defaults
> > > > > are
> > > > > > > set
> > > > > > > > >>>> for
> > > > > > > > >>>> > IgniteConfiguration? some of those factory items can't
> > be
> > > > > > covered
> > > > > > > > >>>> with how
> > > > > > > > >>>> > micronaut sets up configurations.
> @ConfigurationProperty
> > > can
> > > > > > only
> > > > > > > be
> > > > > > > > >>>> > defined on a known factory, there are ways to have
> > > multiple
> > > > > > > > factories
> > > > > > > > >>>> and
> > > > > > > > >>>> > label them optional but that easily gets overwhelming.
> > In
> > > > > this
> > > > > > > > >>>> situation
> > > > > > > > >>>> > providing your own bean would probably be more ideal
> in
> > > this
> > > > > > > > >>>> situation when
> > > > > > > > >>>> > I think about it. I was worrying that I wouldn't be
> > able
> > > to
> > > > > > cover
> > > > > > > > >>>> enough
> > > > > > > > >>>> > of the configuration with
> > > > > > > > >>>> >
> > > > > > > > >>>> > ignite: enabled: true thin-clients: default:
> > > > > address:
> > > > > > > > -
> > > > > > > > >>>> > "127.0.0.1:10800" - "127.0.0.1:10801"
> > > > > > > > >>>> >
> > > > > > > > >>>> > thin-client-2:
> > > > > > > > >>>> > address: - "127.0.0.1:10800" - "
> > > > > 127.0.0.1:10801
> > > > > > "
> > > > > > > > >>>> >
> > > > > > > > >>>> >
> > > > > > > > >>>> > you can see it in the current snapshot documentation:
> > > > > > > > >>>> >
> > > > > > > >
> > > > >
> > https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/
> > > > > > > > >>>> >
> > > > > > > > >>>> > On Tue, Aug 18, 2020 at 4:16 PM Denis Magda <
> > > > > dma...@apache.org>
> > > > > > > > >>>> wrote:
> > > > > > > > >>>> >
> > > > > > > > >>>> > > Michael, thanks for filling out the wiki page.
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > I'm looking at the Auto-Configuration wiki section
> and
> > > the
> > > > > > > current
> > > > > > > > >>>> > version
> > > > > > > > >>>> > > of the io.micronaut.ignite.configuration.
> > > > > > > IgniteClientConfiguration
> > > > > > > > >>>> > > <
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/micronaut-projects/micronaut-ignite/
> > > > > > >
> > > > >
> > > blob/master/ignite-core/src/main/java/io/micronaut/ignite/
> configuration/
> > > > > > > IgniteClientConfiguration.java
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > class,
> > > > > > > > >>>> > > and wonder if we can perform the following changes:
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > 1. Rename the IgniteClientConfiguration to
> > > > > > > IgniteConfiguration
> > > > > > > > >>>> (or, to
> > > > > > > > >>>> > > avoid ambiguity, even to
> DefaultIgniteConfiguration
> > > as
> > > > > it's
> > > > > > > > done
> > > > > > > > >>>> for
> > > > > > > > >>>> > the
> > > > > > > > >>>> > > Mongo driver
> > > > > > > > >>>> > > <
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://micronaut-projects.github.io/micronaut-mongodb/
> > > > > > > latest/api/io/micronaut/configuration/mongo/reactive/
> > > > > > > DefaultMongoConfiguration.html
> > > > > > > > >>>> > > >).
> > > > > > > > >>>> > > The rationale for this change is that the
> > developers
> > > > > might
> > > > > > > need
> > > > > > > > >>>> to
> > > > > > > > >>>> > > start an embedded
> > > > > > > > >>>> > > Ignite server node
> > > > > > > > >>>> > > <
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://www.gridgain.com/docs/latest/installation-guide/
> > > > > > > deployment-modes#embedded-deployment
> > > > > > > > >>>> > > >.
> > > > > > > > >>>> > > So, I would not limit the integration scope to
> the
> > > > Ignite
> > > > > > > > clients
> > > > > > > > >>>> > only.
> > > > > > > > >>>> > > 2. Presently,
> > > > > > > > >>>> > >
> > > > io.micronaut.ignite.configuration.IgniteClientConfiguration
> > > > > > > > >>>> > > supports two parameters - the "name" and "path".
> I
> > > > would
> > > > > > > > replace
> > > > > > > > >>>> the
> > > > > > > > >>>> > > "path"
> > > > > > > > >>>> > > parameter with the "config" one that instantiates
> > > > > > > > >>>> > > org.apache.ignite.IgniteConfiguration. If we do
> > that,
> > > > > then
> > > > > > > the
> > > > > > > > >>>> > > developers
> > > > > > > > >>>> > > will be able to set any property of the
> > > > > IgniteConfiguration
> > > > > > > > >>>> straight
> > > > > > > > >>>> > in
> > > > > > > > >>>> > > the
> > > > > > > > >>>> > > main YAML file. See how it's done for the Ignite
> > > Spring
> > > > > > Boot
> > > > > > > > >>>> > > Auto-Configuration
> > > > > > > > >>>> > > <
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://apacheignite-mix.readme.io/docs/spring-boot#
> > > > > > > set-ignite-up-via-spring-boot-configuration
> > > > > > > > >>>> > > >.
> > > > > > > > >>>> > > Guess, we can do the same with Micronaut.
> > > > > > > > >>>> > > 3. If the previous modification is feasible,
> then I
> > > > would
> > > > > > > > rework
> > > > > > > > >>>> the
> > > > > > > > >>>> > > Ignite thin client configuration similarly,
> taking
> > > our
> > > > > > Spring
> > > > > > > > >>>> Boot
> > > > > > > > >>>> > > integration for the thin client
> > > > > > > > >>>> > > <
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://apacheignite-mix.readme.io/docs/spring-boot#
> > > > > > > set-thin-client-up-via-spring-boot-configuration
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > as a reference. As I see, the current version of
> > > > > > > > >>>> > > IgniteThinClientConfiguration
> > > > > > > > >>>> > > <
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/micronaut-projects/micronaut-ignite/
> > > > > > >
> > > > >
> > > blob/master/ignite-core/src/main/java/io/micronaut/ignite/
> configuration/
> > > > > > > IgniteThinClientConfiguration.java
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > already
> > > > > > > > >>>> > > adopts this approach. I would only rename
> > > > "configuration"
> > > > > > to
> > > > > > > > >>>> "config",
> > > > > > > > >>>> > > and
> > > > > > > > >>>> > > remove the "transaction" field since you can pass
> > the
> > > > > > > > >>>> transactional
> > > > > > > > >>>> > > settings via the YAML following the format below:
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > ignite-thin-client:
> > > > > > > > >>>> > > name:
> > > > > > > > >>>> > > config:
> > > > > > > > >>>> > > addresses: <IP_addresses>
> > > > > > > > >>>> > > partitionAwarenessEnabled: true
> > > > > > > > >>>> > > transactionConfiguration:
> > > > > > > > >>>> > > defaultTxConcurrency:...
> > > > > > > > >>>> > > defaultTxTimeout
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > -
> > > > > > > > >>>> > > Denis
> > > > > > > > >>>> > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > On Mon, Aug 17, 2020 at 6:50 PM Michael Pollind <
> > > > > > > > mpoll...@gmail.com
> > > > > > > > >>>> >
> > > > > > > > >>>> > > wrote:
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > > oh, that makes more sense. so those methods get
> > > wrapped
> > > > > > into a
> > > > > > > > >>>> > > > micronaut-aop intercept. Below I've listed the
> > > relevant
> > > > > > > sections
> > > > > > > > >>>> of
> > > > > > > > >>>> > code
> > > > > > > > >>>> > > > that would handle each annotation along with the
> > > methods
> > > > > > that
> > > > > > > > get
> > > > > > > > >>>> > called
> > > > > > > > >>>> > > > from the ignite branch I'm working from. Hopefully
> > > this
> > > > > > helps.
> > > > > > > > >>>> The key
> > > > > > > > >>>> > is
> > > > > > > > >>>> > > > specified from the CacheConfig annotation but this
> > can
> > > > be
> > > > > > > > changed
> > > > > > > > >>>> if
> > > > > > > > >>>> > > there
> > > > > > > > >>>> > > > is a better way to represent the key. By default
> it
> > > uses
> > > > > > this
> > > > > > > > >>>> > > > DefaultCacheKeyGenerator(
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/
> > > > > > > master/cache-core/src/main/java/io/micronaut/cache/
> interceptor/
> > > > > > > DefaultCacheKeyGenerator.java
> > > > > > > > >>>> > > > ).
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > I also finished up this document on sunday:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > >
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration
> > > > > > > > >>>> > > .
> > > > > > > > >>>> > > > Any suggestions with what I could expand on and
> how
> > > this
> > > > > > could
> > > > > > > > be
> > > > > > > > >>>> > > adjusted.
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > Cacheable:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > For Cacheable it will run a get and issue a put if
> > the
> > > > > value
> > > > > > > is
> > > > > > > > >>>> not
> > > > > > > > >>>> > > present
> > > > > > > > >>>> > > > in the cache.
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > -> micronaut-cache:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/
> > > > > > > master/cache-core/src/main/java/io/micronaut/cache/
> > > > > > > interceptor/CacheInterceptor.java#L163-L170
> > > > > > > > >>>> > > > -> ignite-cache:
> > > > > > > > >>>> > > > get:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/
> > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/
> > > > > > > IgniteSyncCache.java#L60-L70
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > CachePut:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > For cache put it will invalidate if the return is
> > null
> > > > > else
> > > > > > it
> > > > > > > > >>>> will
> > > > > > > > >>>> > > issue a
> > > > > > > > >>>> > > > put. I think there might be a mistake in my code
> > > > because I
> > > > > > use
> > > > > > > > >>>> > > putIfAbsent
> > > > > > > > >>>> > > > for both cases. I need to investigate that closer
> > and
> > > > > write
> > > > > > > some
> > > > > > > > >>>> > > additional
> > > > > > > > >>>> > > > test cases to verify the behaviour.
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > --> micronaut-cache:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/
> > > > > > > master/cache-core/src/main/java/io/micronaut/cache/
> > > > > > > interceptor/CacheInterceptor.java#L510-L525
> > > > > > > > >>>> > > > -> ignite-cache:
> > > > > > > > >>>> > > > put:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/
> > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/
> > > > > > > IgniteSyncCache.java#L83-L88
> > > > > > > > >>>> > > > invalidate:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/
> > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/
> > > > > > > IgniteSyncCache.java#L91-L95
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > CacheInvalidate:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > for cache invalidation it will just be removed by
> > the
> > > > key.
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > --> micronaut-cache:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/
> > > > > > > master/cache-core/src/main/java/io/micronaut/cache/
> > > > > > > interceptor/CacheInterceptor.java#L590-L596
> > > > > > > > >>>> > > > -> ignite-cache:
> > > > > > > > >>>> > > > invalidate:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > >
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/
> > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/
> > > > > > > IgniteSyncCache.java#L91-L95
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > On Mon, Aug 17, 2020 at 5:23 PM Saikat Maitra <
> > > > > > > > >>>> saikat.mai...@gmail.com
> > > > > > > > >>>> > >
> > > > > > > > >>>> > > > wrote:
> > > > > > > > >>>> > > >
> > > > > > > > >>>> > > > > Hi Michael,
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > > In the Example Cacheable Object you are using
> > > > @CachePut,
> > > > > > > > >>>> @Cacheable
> > > > > > > > >>>> > > > > annotations and @CacheInvalidate annotations
> and I
> > > was
> > > > > > > trying
> > > > > > > > to
> > > > > > > > >>>> > > > understand
> > > > > > > > >>>> > > > > when user use these annotation then what would
> be
> > > the
> > > > > > > > underlying
> > > > > > > > >>>> > Ignite
> > > > > > > > >>>> > > > > operation that will happen? and how those
> > operations
> > > > are
> > > > > > > > >>>> performed?
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > > An example like when user call this below method
> > > then
> > > > > how
> > > > > > > the
> > > > > > > > >>>> result
> > > > > > > > >>>> > of
> > > > > > > > >>>> > > > > getValue is cached?
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > > @Cacheable
> > > > > > > > >>>> > > > > int getValue(String name) {
> > > > > > > > >>>> > > > > return counters.computeIfAbsent(name, {
> 0
> > })
> > > > > > > > >>>> > > > > }
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > > Regards,
> > > > > > > > >>>> > > > > Saikat
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > > On Sat, Aug 15, 2020 at 7:21 PM Michael Pollind
> <
> > > > > > > > >>>> mpoll...@gmail.com>
> > > > > > > > >>>> > > > > wrote:
> > > > > > > > >>>> > > > >
> > > > > > > > >>>> > > > > > when you mean these annotations do you mean
> this
> > > > would
> > > > > > > need
> > > > > > > > >>>> to be
> > > > > > > > >>>> > > > > > implemented in ignite?
> > > > > > > > >>>> > > > > >
> > > > > > > > >>>> > > > > > The project at the moment is split into
> multiple
> > > > > > modules.
> > > > > > > > >>>> > > ignite-core,
> > > > > > > > >>>> > > > > > ignite-cache, etc ... The plan was to also
> have
> > > > > > > ignite-data
> > > > > > > > >>>> but
> > > > > > > > >>>> > that
> > > > > > > > >>>> > > > will
> > > > > > > > >>>> > > > > > take a bit of work to get working correctly
> but
> > > the
> > > > > > basic
> > > > > > > > >>>> config is
> > > > > > > > >>>> > > > > mostly
> > > > > > > > >>>> > > > > > done. The plan is also to verify the API
> > described
> > > > in
> > > > > > the
> > > > > > > > >>>> wiki and
> > > > > > > > >>>> > > make
> > > > > > > > >>>> > > > > > sure this is what would work best. At the
> moment
> > > I'm
> > > > > > > missing
> > > > > > > > >>>> an
> > > > > > > > >>>> > > > > > implementation for the thin-cache and how that
> > > would
> > > > > fit
> > > > > > > > into
> > > > > > > > >>>> this
> > > > > > > > >>>> > > > > scheme.
> > > > > > > > >>>> > > > > > I've removed it due to the added complexity
> but
> > > I'm
> > > > > sure
> > > > > > > > >>>> something
> > > > > > > > >>>> > > > could
> > > > > > > > >>>> > > > > be
> > > > > > > > >>>> > > > > > arranged that would work.
> > > > > > > > >>>> > > > > >
> > > > > > > > >>>> > > > > > For Ignite-cache, I have it as a separate
> module
> > > > that
> > > > > > can
> > > > > > > be
> > > > > > > > >>>> > > optionally
> > > > > > > > >>>> > > > > > included in a micronaut project where this
> > module
> > > > also
> > > > > > > has a
> > > > > > > > >>>> > > dependency
> > > > > > > > >>>> > > > > on
> > > > > > > > >>>> > > > > > micronaut-cache. The AsyncCache and SyncCache
> > are
> > > > the
> > > > > > two
> > > > > > > > >>>> > interfaces
> > > > > > > > >>>> > > > that
> > > > > > > > >>>> > > > > > micronaut-cache defines. There are two ways to
> > > > define
> > > > > > the
> > > > > > > > >>>> > > > implementation,
> > > > > > > > >>>> > > > > > you can either provide beans for AsyncCache
> and
> > > > > > SyncCache
> > > > > > > > but
> > > > > > > > >>>> they
> > > > > > > > >>>> > > also
> > > > > > > > >>>> > > > > > define a DynamicCacheManager that will use the
> > > name
> > > > of
> > > > > > the
> > > > > > > > >>>> instance
> > > > > > > > >>>> > > to
> > > > > > > > >>>> > > > > > refer to the name of the cache used. In the
> > > > > > documentation
> > > > > > > I
> > > > > > > > >>>> believe
> > > > > > > > >>>> > > for
> > > > > > > > >>>> > > > > > Teracotta you give a list of caches you want
> and
> > >
>
>
--
-
Denis
