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/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java
>>>>> > > >
>>>>> > > with
>>>>> > > all its fields of primitive types (this should be done easily,
>>>>> right,
>>>>> > > without copy-paste?) and its ipFinder field. In the beginning,
>>>>> I would
>>>>> > > only
>>>>> > > support setting TcpDiscoveryVmIpFinder
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java
>>>>> > > >
>>>>> > > and
>>>>> > > KubernetesIpFinder
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java
>>>>> > > >via
>>>>> > > the DefaultIgniteConfiguration.
>>>>> > > - DataStorageConfiguration
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java
>>>>> > > >
>>>>> > > including
>>>>> > > its DataStorageConfiguration.dataRegions property.
>>>>> > > - TcpCommunicationSpi
>>>>> > > <
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
>>>>> > > >
>>>>> > > with
>>>>> > > its fields of primitive types. Again, here is I'm assuming that
>>>>> we can
>>>>> > > do
>>>>> > > this avoiding copy-pasting. Either through @ConfigurationBuilder
>>>>> > > (include)
>>>>> > > or inheritence.
>>>>> > >
>>>>> > > If the user wants to configure any settings unsupported by
>>>>> > > DefaultIgniteConfiguration then, there should be a way to create an
>>>>> > > IgniteConfiguration bean programmatically and use it to initialize
>>>>> an
>>>>> > > Ignite instance (instead of DefaultIgniteConfiguration).
>>>>> > >
>>>>> > > What's your thinking? Let me know if I'm still missing something.
>>>>> > > -
>>>>> > > Denis
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <
>>>>> 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
>>>>> > > > > > Hazelcast
>>>>> > > > > > > > >>>> > implements
>>>>> > > > > > > > >>>> > > > the
>>>>> > > > > > > > >>>> > > > > > DynamicCacheManager. you can see that in
>>>>> the
>>>>> > yaml
>>>>> > > > > > > > >>>> configuration in
>>>>> > > > > > > > >>>> > > > > > micronaut documentation where a list of
>>>>> cache
>>>>> > > names
>>>>> > > > > are
>>>>> > > > > > > > >>>> provided
>>>>> > > > > > > > >>>> > > along
>>>>> > > > > > > > >>>> > > > > with
>>>>> > > > > > > > >>>> > > > > > a configuration. Something similar can
>>>>> also be
>>>>> > > setup
>>>>> > > > > > > where a
>>>>> > > > > > > > >>>> list
>>>>> > > > > > > > >>>> > of
>>>>> > > > > > > > >>>> > > > > > implementations from the yaml can be
>>>>> mapped to a
>>>>> > > > > > > > >>>> configuration if
>>>>> > > > > > > > >>>> > > that
>>>>> > > > > > > > >>>> > > > > > would be more ideal.
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > >
>>>>> > > > > > > > >>>> > > >
>>>>> > > > > > > > >>>> > >
>>>>> > > > > > > > >>>> >
>>>>> > > > > > > > >>>>
>>>>> > > > > > > >
>>>>> https://github.com/pollend/micronaut-ignite/tree/feature/
>>>>> > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > > > On Sat, Aug 15, 2020 at 4:10 PM Saikat
>>>>> Maitra <
>>>>> > > > > > > > >>>> > > saikat.mai...@gmail.com
>>>>> > > > > > > > >>>> > > > >
>>>>> > > > > > > > >>>> > > > > > wrote:
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > > > > Hi Michael,
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > Welcome to the Ignite community!!!
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > Please feel free to reach out if you
>>>>> have any
>>>>> > > > > > questions
>>>>> > > > > > > > with
>>>>> > > > > > > > >>>> > > respect
>>>>> > > > > > > > >>>> > > > to
>>>>> > > > > > > > >>>> > > > > > > Ignite Integration.
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > I had a question specific to
>>>>> integration and
>>>>> > > > wanted
>>>>> > > > > to
>>>>> > > > > > > ask
>>>>> > > > > > > > >>>> if
>>>>> > > > > > > > >>>> > these
>>>>> > > > > > > > >>>> > > > > > > annotations also need to be implemented
>>>>> for
>>>>> > the
>>>>> > > > > > > > >>>> micronaut-ignite
>>>>> > > > > > > > >>>> > > > > > > integration.
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > @Cacheable - Indicates a method is
>>>>> cacheable
>>>>> > > > within
>>>>> > > > > > the
>>>>> > > > > > > > >>>> given
>>>>> > > > > > > > >>>> > cache
>>>>> > > > > > > > >>>> > > > > name
>>>>> > > > > > > > >>>> > > > > > > @CachePut - Indicates that the return
>>>>> value
>>>>> > of a
>>>>> > > > > > method
>>>>> > > > > > > > >>>> > invocation
>>>>> > > > > > > > >>>> > > > > should
>>>>> > > > > > > > >>>> > > > > > > be cached. Unlike @Cacheable the
>>>>> original
>>>>> > > > operation
>>>>> > > > > is
>>>>> > > > > > > > never
>>>>> > > > > > > > >>>> > > skipped.
>>>>> > > > > > > > >>>> > > > > > > @CacheInvalidate - Indicates the
>>>>> invocation
>>>>> > of a
>>>>> > > > > > method
>>>>> > > > > > > > >>>> should
>>>>> > > > > > > > >>>> > > cause
>>>>> > > > > > > > >>>> > > > > the
>>>>> > > > > > > > >>>> > > > > > > invalidation of one or many caches.
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > Denis - Thank you for sharing the
>>>>> details in
>>>>> > dev
>>>>> > > > > list,
>>>>> > > > > > > it
>>>>> > > > > > > > >>>> great
>>>>> > > > > > > > >>>> > to
>>>>> > > > > > > > >>>> > > > > learn
>>>>> > > > > > > > >>>> > > > > > > about micronaut-ignite module.
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > Regards,
>>>>> > > > > > > > >>>> > > > > > > Saikat
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > On Sat, Aug 15, 2020 at 12:35 AM Michael
>>>>> > > Pollind <
>>>>> > > > > > > > >>>> > > mpoll...@gmail.com
>>>>> > > > > > > > >>>> > > > >
>>>>> > > > > > > > >>>> > > > > > > wrote:
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > Here is the page that i've stubbed
>>>>> out:
>>>>> > > > > > > > >>>> > > > > > > >
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > >
>>>>> > > > > > > > >>>> >
>>>>> > > > > > > > >>>>
>>>>> > > > > > > >
>>>>> > > > > >
>>>>> > > >
>>>>> >
>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration
>>>>> > > > > > > > >>>> > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > I'll start trying to fill out some of
>>>>> the
>>>>> > > > details
>>>>> > > > > > over
>>>>> > > > > > > > >>>> the next
>>>>> > > > > > > > >>>> > > few
>>>>> > > > > > > > >>>> > > > > > days
>>>>> > > > > > > > >>>> > > > > > > > and we can go from there.
>>>>> > > > > > > > >>>> > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > On Fri, Aug 14, 2020 at 2:47 PM Denis
>>>>> Magda
>>>>> > <
>>>>> > > > > > > > >>>> dma...@apache.org
>>>>> > > > > > > > >>>> > >
>>>>> > > > > > > > >>>> > > > > wrote:
>>>>> > > > > > > > >>>> > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > > You're in, now you can create wiki
>>>>> pages
>>>>> > in
>>>>> > > > the
>>>>> > > > > > > Ignite
>>>>> > > > > > > > >>>> > > namespace.
>>>>> > > > > > > > >>>> > > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > > Also, please subscribe to the list
>>>>> by
>>>>> > > sending
>>>>> > > > a
>>>>> > > > > > note
>>>>> > > > > > > > to
>>>>> > > > > > > > >>>> the
>>>>> > > > > > > > >>>> > > > > > > > > dev-subscr...@ignite.apache.org
>>>>> address.
>>>>> > > > > > Otherwise,
>>>>> > > > > > > > we
>>>>> > > > > > > > >>>> need
>>>>> > > > > > > > >>>> > to
>>>>> > > > > > > > >>>> > > > > > approve
>>>>> > > > > > > > >>>> > > > > > > > > every email you send.
>>>>> > > > > > > > >>>> > > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > > -
>>>>> > > > > > > > >>>> > > > > > > > > Denis
>>>>> > > > > > > > >>>> > > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM
>>>>> Michael
>>>>> > > > Pollind
>>>>> > > > > <
>>>>> > > > > > > > >>>> > > > > mpoll...@gmail.com>
>>>>> > > > > > > > >>>> > > > > > > > > wrote:
>>>>> > > > > > > > >>>> > > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >> here is the link:
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > >
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > >
>>>>> > > > > > > > >>>> > > >
>>>>> > > > > > > > >>>> > >
>>>>> > > > > > > > >>>> >
>>>>> > > > > > > > >>>>
>>>>> > > > > > > >
>>>>> > https://cwiki.apache.org/confluence/users/viewuserprofile.action
>>>>> > > ?
>>>>> > > > > > > username=mpollind
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >> Here is the work in progress pull
>>>>> request
>>>>> > > > that
>>>>> > > > > > I've
>>>>> > > > > > > > put
>>>>> > > > > > > > >>>> > > > together:
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > >
>>>>> > > > > >
>>>>> https://github.com/micronaut-projects/micronaut-ignite/pull/33
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >> --
>>>>> > > > > > > > >>>> > > > > > > > >> Sent from:
>>>>> > > > > > > > >>>> > > >
>>>>> > > http://apache-ignite-developers.2346864.n4.nabble.com/
>>>>> > > > > > > > >>>> > > > > > > > >>
>>>>> > > > > > > > >>>> > > > > > > > >
>>>>> > > > > > > > >>>> > > > > > > >
>>>>> > > > > > > > >>>> > > > > > >
>>>>> > > > > > > > >>>> > > > > >
>>>>> > > > > > > > >>>> > > > >
>>>>> > > > > > > > >>>> > > >
>>>>> > > > > > > > >>>> > >
>>>>> > > > > > > > >>>> >
>>>>> > > > > > > > >>>>
>>>>> > > > > > > > >>>
>>>>> > > > > > > >
>>>>> > > > > > >
>>>>> > > > > >
>>>>> > > > > >
>>>>> > > > > > --
>>>>> > > > > > -
>>>>> > > > > > Denis
>>>>> > > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
