đź‘Ť Nice catch!
-
Denis
On Wed, Aug 26, 2020 at 12:16 PM Michael Pollind <mpoll...@gmail.com> wrote:
> One thing that just occurred to me for the DefaultIgniteConfiguration. you
> can actually just intercept the bean when it's created. This should let us
> use the enable flag from ignite-core for ignite-cache without the
> additional flag.
>
> @Singleton
> public class IgniteConfigurationFactoryInterceptor implements
> BeanCreatedEventListener<DefaultIgniteConfiguration> {
> @Override
> public IgniteConfiguration
> onCreated(BeanCreatedEvent<DefaultIgniteConfiguration> event) {
> IgniteConfiguration configuration = event.getBean();
> configuration.setIgniteInstanceName("instance-a");
> return configuration;
> }
> }
>
>
> On Wed, Aug 26, 2020 at 11:31 AM Denis Magda <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
> > > >>
> > > >
> > >
> >
>
