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 <dma...@apache.org> 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 <mpoll...@gmail.com>
> 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 <mpoll...@gmail.com>
> > 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 <dma...@apache.org> 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 <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
> > >>
> > >
> >
>
