Re: [Micronaut] pubsub support
I'm looking at this data stream api and I'm having a hard time working out
how this scheme fits into the pub sub model that micronaut uses. Here is
what I've kind of come up with and wonder if this would work.
@PubSubClientpublic interface MultipleMessage {
@Topic("animals")
public void send(@key() String key, Animal o);
@Topic("my_topic")
public void send2(@key() Long key, Object o);
}
@PubSubListener
public class SimpleSub {
@Subscription("animals")
public class Listener(@key() String key, Animal o) {
}
}
On Tue, Oct 27, 2020 at 7:15 PM Saikat Maitra
wrote:
> Hi Michael, Denis
>
> I did an initial review of the PR and wanted to share my thoughts. I
> observed that currently the implementation is using Ignite messaging apis
> and I am thinking if we should change the implementation to use Ignite data
> streaming apis. The reason for change is to ensure that it will be better
> aligned to Ignite 3.0 release as we are planning to deprecate Ignite
> Messaging apis in Ignite 3.0 [1]
>
> My recommendation to use Ignite data streaming apis is also due to the
> fact that we have multiple integration like Google Pub/Sub[2] and Kafka
> Streamer[3] that uses Data streaming apis for integration and it will keep
> micronaut implementation consistent with other extensions.
>
> Here is an example[4] of how Kafka Streamer can be used to stream data
> into Ignite nodes.
>
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
> [2]
> https://github.com/apache/ignite-extensions/blob/master/modules/pub-sub-ext/src/main/java/org/apache/ignite/stream/pubsub/PubSubStreamer.java
> [3]
> https://github.com/apache/ignite-extensions/blob/master/modules/kafka-ext/src/main/java/org/apache/ignite/stream/kafka/KafkaStreamer.java
> [4]
> https://github.com/samaitra/streamersk-extensions/blob/main/src/main/kotlin/com/example/streamerskextensions/kafka/KafkaStreamer.kt
>
> Please let me know your feedback.
>
> Regards,
> Saikat
>
> On Tue, Oct 27, 2020 at 12:48 PM Denis Magda wrote:
>
>> Michael, glad to see you back!
>>
>> Could you please explain in a few words what this integration does and
>> what
>> it enables for Ignite and Micronaout? So that we are as a community are on
>> the same page.
>>
>> -
>> Denis
>>
>>
>> On Sun, Oct 25, 2020 at 3:05 PM Michael Pollind
>> wrote:
>>
>> > I've started to work on adding some basic pubsub support for
>> > Micronaut-ignite. I only have a draft PR in progress. There are a couple
>> > modules that already implement pub-sub so those modules would be a good
>> > start for reference:
>> > https://github.com/micronaut-projects/micronaut-gcp
>> > https://github.com/micronaut-projects/micronaut-kafka
>> > https://github.com/micronaut-projects/micronaut-mqtt
>> >
>> > https://github.com/micronaut-projects/micronaut-ignite/pull/62
>> >
>> >
>> >
>>
>
[Micronaut] pubsub support
I've started to work on adding some basic pubsub support for Micronaut-ignite. I only have a draft PR in progress. There are a couple modules that already implement pub-sub so those modules would be a good start for reference: https://github.com/micronaut-projects/micronaut-gcp https://github.com/micronaut-projects/micronaut-kafka https://github.com/micronaut-projects/micronaut-mqtt https://github.com/micronaut-projects/micronaut-ignite/pull/62
Re: Micronaut/Ignite
here is the release: https://search.maven.org/artifact/io.micronaut.ignite/micronaut-ignite-core/1.0.0.RC1/jar On Fri, Sep 11, 2020 at 10:16 AM Michael Pollind wrote: > looks like I was wrong, will have to wait till this PR get merged and a > release is made in the repo. > > https://github.com/micronaut-projects/micronaut-core/pull/4070 > > On Fri, Sep 11, 2020 at 10:01 AM Michael Pollind > wrote: > >> The caching is setup in the branch and the release candidate is already >> out I think. can't think of anything off the top of my head with tweaking >> the ignite cache module but i'm sure a few adjustments can be made. >> >> On Thu, Sep 10, 2020 at 10:41 AM Denis Magda wrote: >> >>> Michael, congrats, it was a pleasure working with you! >>> >>> Let us know once the release candidate is published. I'll go ahead and >>> update my tutorial, and would probably create a separate blog post for >>> DZone or Dev.to: >>> >>> https://www.gridgain.com/docs/tutorials/micronaut/getting-started/ignite-micronaut-getting-started >>> >>> Are you planning to work on the Micronaut Caching module? Or is it >>> already enabled and we just need to prepare examples on how to use Ignite >>> as a Micronaut cache? >>> >>> - >>> Denis >>> >>> >>> On Thu, Sep 10, 2020 at 9:17 AM Michael Pollind >>> wrote: >>> >>>> With some help from @Denis Magda , we were able >>>> to rework micronaut-ignite and a release candidate was approved. I'm >>>> pretty happy with this first pass and there is a lot more that can be added >>>> but this is a good initial first step. >>>> >>>> documentation can be bound here: >>>> https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/ >>>> PR: https://github.com/micronaut-projects/micronaut-ignite/pull/33 >>>> >>>> On Thu, Aug 27, 2020 at 5:32 PM Michael Pollind >>>> wrote: >>>> >>>>> Not sure, I would probably bring that up in the PR so the micronaut >>>>> devs are aware of this. Not sure how the CI will work and what can be >>>>> arranged in this case. >>>>> >>>>> On Thu, Aug 27, 2020 at 3:50 PM Denis Magda wrote: >>>>> >>>>>> Michael, >>>>>> >>>>>> The docs look good enough for the release. Once the integration is >>>>>> released, I'll update and extend my Micronaut tutorial elucidating on >>>>>> how >>>>>> to use the integration in practice for various use cases. >>>>>> >>>>>> Btw, are the ignite-core and ignite-cache Maven artifacts will be >>>>>> released >>>>>> for a specific version of Ignite? Ideally, the version of Ignite >>>>>> needs to >>>>>> be set in a pom.xml and the Micronaut integration should pick them up. >>>>>> >>>>>> Also, what are we doing next - reviewing APIs of the ignite-cache >>>>>> module or >>>>>> going through a review process of the ignite-core and merging it >>>>>> first to >>>>>> the Micronaut repository? >>>>>> >>>>>> - >>>>>> Denis >>>>>> >>>>>> >>>>>> On Wed, Aug 26, 2020 at 3:35 PM Michael Pollind >>>>>> wrote: >>>>>> >>>>>> > Also you need to sign the CLA since you add a commit to my branch. >>>>>> > >>>>>> > branch: >>>>>> https://github.com/pollend/micronaut-ignite/tree/feature/rework >>>>>> > linked PR: >>>>>> https://github.com/micronaut-projects/micronaut-ignite/pull/33 >>>>>> > >>>>>> > -- >>>>>> > Michael Pollind >>>>>> > >>>>>> > On Wed, Aug 26, 2020 at 3:29 PM Denis Magda >>>>>> wrote: >>>>>> > >>>>>> > > Could you share the full path to the branch? Don't want to pick a >>>>>> wrong >>>>>> > one >>>>>> > > accidentally. >>>>>> > > >>>>>> > > >>>>>> > > - >>>>>> > > Denis >>>>>> > > >>>>>> > > >>>>>> > > On Wed,
Re: Micronaut/Ignite
looks like I was wrong, will have to wait till this PR get merged and a release is made in the repo. https://github.com/micronaut-projects/micronaut-core/pull/4070 On Fri, Sep 11, 2020 at 10:01 AM Michael Pollind wrote: > The caching is setup in the branch and the release candidate is already > out I think. can't think of anything off the top of my head with tweaking > the ignite cache module but i'm sure a few adjustments can be made. > > On Thu, Sep 10, 2020 at 10:41 AM Denis Magda wrote: > >> Michael, congrats, it was a pleasure working with you! >> >> Let us know once the release candidate is published. I'll go ahead and >> update my tutorial, and would probably create a separate blog post for >> DZone or Dev.to: >> >> https://www.gridgain.com/docs/tutorials/micronaut/getting-started/ignite-micronaut-getting-started >> >> Are you planning to work on the Micronaut Caching module? Or is it >> already enabled and we just need to prepare examples on how to use Ignite >> as a Micronaut cache? >> >> - >> Denis >> >> >> On Thu, Sep 10, 2020 at 9:17 AM Michael Pollind >> wrote: >> >>> With some help from @Denis Magda , we were able to >>> rework micronaut-ignite and a release candidate was approved. I'm pretty >>> happy with this first pass and there is a lot more that can be added but >>> this is a good initial first step. >>> >>> documentation can be bound here: >>> https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/ >>> PR: https://github.com/micronaut-projects/micronaut-ignite/pull/33 >>> >>> On Thu, Aug 27, 2020 at 5:32 PM Michael Pollind >>> wrote: >>> >>>> Not sure, I would probably bring that up in the PR so the micronaut >>>> devs are aware of this. Not sure how the CI will work and what can be >>>> arranged in this case. >>>> >>>> On Thu, Aug 27, 2020 at 3:50 PM Denis Magda wrote: >>>> >>>>> Michael, >>>>> >>>>> The docs look good enough for the release. Once the integration is >>>>> released, I'll update and extend my Micronaut tutorial elucidating on >>>>> how >>>>> to use the integration in practice for various use cases. >>>>> >>>>> Btw, are the ignite-core and ignite-cache Maven artifacts will be >>>>> released >>>>> for a specific version of Ignite? Ideally, the version of Ignite needs >>>>> to >>>>> be set in a pom.xml and the Micronaut integration should pick them up. >>>>> >>>>> Also, what are we doing next - reviewing APIs of the ignite-cache >>>>> module or >>>>> going through a review process of the ignite-core and merging it first >>>>> to >>>>> the Micronaut repository? >>>>> >>>>> - >>>>> Denis >>>>> >>>>> >>>>> On Wed, Aug 26, 2020 at 3:35 PM Michael Pollind >>>>> wrote: >>>>> >>>>> > Also you need to sign the CLA since you add a commit to my branch. >>>>> > >>>>> > branch: >>>>> https://github.com/pollend/micronaut-ignite/tree/feature/rework >>>>> > linked PR: >>>>> https://github.com/micronaut-projects/micronaut-ignite/pull/33 >>>>> > >>>>> > -- >>>>> > Michael Pollind >>>>> > >>>>> > On Wed, Aug 26, 2020 at 3:29 PM Denis Magda >>>>> wrote: >>>>> > >>>>> > > Could you share the full path to the branch? Don't want to pick a >>>>> wrong >>>>> > one >>>>> > > accidentally. >>>>> > > >>>>> > > >>>>> > > - >>>>> > > Denis >>>>> > > >>>>> > > >>>>> > > On Wed, Aug 26, 2020 at 2:47 PM Michael Pollind < >>>>> mpoll...@gmail.com> >>>>> > > wrote: >>>>> > > >>>>> > > > so that clears up the extra flag for micronaut-cache. just need >>>>> to >>>>> > > > intercept the default IgniteConfiguration bean and update the >>>>> > > > configuration. if you pull my latest changes from the rework >>>>> branch you >>>>> > > can >>>>
Re: Micronaut/Ignite
With some help from @Denis Magda , we were able to
rework micronaut-ignite and a release candidate was approved. I'm pretty
happy with this first pass and there is a lot more that can be added but
this is a good initial first step.
documentation can be bound here:
https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/
PR: https://github.com/micronaut-projects/micronaut-ignite/pull/33
On Thu, Aug 27, 2020 at 5:32 PM Michael Pollind wrote:
> Not sure, I would probably bring that up in the PR so the micronaut devs
> are aware of this. Not sure how the CI will work and what can be arranged
> in this case.
>
> On Thu, Aug 27, 2020 at 3:50 PM Denis Magda wrote:
>
>> Michael,
>>
>> The docs look good enough for the release. Once the integration is
>> released, I'll update and extend my Micronaut tutorial elucidating on how
>> to use the integration in practice for various use cases.
>>
>> Btw, are the ignite-core and ignite-cache Maven artifacts will be released
>> for a specific version of Ignite? Ideally, the version of Ignite needs to
>> be set in a pom.xml and the Micronaut integration should pick them up.
>>
>> Also, what are we doing next - reviewing APIs of the ignite-cache module
>> or
>> going through a review process of the ignite-core and merging it first to
>> the Micronaut repository?
>>
>> -
>> Denis
>>
>>
>> On Wed, Aug 26, 2020 at 3:35 PM Michael Pollind
>> wrote:
>>
>> > Also you need to sign the CLA since you add a commit to my branch.
>> >
>> > branch: https://github.com/pollend/micronaut-ignite/tree/feature/rework
>> > linked PR:
>> https://github.com/micronaut-projects/micronaut-ignite/pull/33
>> >
>> > --
>> > Michael Pollind
>> >
>> > On Wed, Aug 26, 2020 at 3:29 PM Denis Magda wrote:
>> >
>> > > Could you share the full path to the branch? Don't want to pick a
>> wrong
>> > one
>> > > accidentally.
>> > >
>> > >
>> > > -
>> > > Denis
>> > >
>> > >
>> > > On Wed, Aug 26, 2020 at 2:47 PM Michael Pollind
>> > > wrote:
>> > >
>> > > > so that clears up the extra flag for micronaut-cache. just need to
>> > > > intercept the default IgniteConfiguration bean and update the
>> > > > configuration. if you pull my latest changes from the rework branch
>> you
>> > > can
>> > > > look at the docs for that micronaut module. `./gradlew docs`.
>> > Finalizing
>> > > > the docs should be the last part of this. The configuration from my
>> > > > perspective seems pretty much there. Is there anything else that is
>> > > > missing?
>> > > >
>> > > > On Wed, Aug 26, 2020 at 1:31 PM Denis Magda
>> wrote:
>> > > >
>> > > > > 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 {
>> > > > > > @Override
>> > > > > > public IgniteConfiguration
>> > > > > > onCreated(BeanCreatedEvent event) {
>> > > > > > IgniteConfiguration configuration = event.getBean();
>> > > > > > configuration.setIgniteInstanceName("instance-a");
>> > > > > > return configuration;
>> > > > > > }
>> > > > > > }
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Aug 26, 2020 at 11:31 AM Denis Magda > >
>> > > > wrote:
>> > >
Re: Micronaut/Ignite
Not sure, I would probably bring that up in the PR so the micronaut devs
are aware of this. Not sure how the CI will work and what can be arranged
in this case.
On Thu, Aug 27, 2020 at 3:50 PM Denis Magda wrote:
> Michael,
>
> The docs look good enough for the release. Once the integration is
> released, I'll update and extend my Micronaut tutorial elucidating on how
> to use the integration in practice for various use cases.
>
> Btw, are the ignite-core and ignite-cache Maven artifacts will be released
> for a specific version of Ignite? Ideally, the version of Ignite needs to
> be set in a pom.xml and the Micronaut integration should pick them up.
>
> Also, what are we doing next - reviewing APIs of the ignite-cache module or
> going through a review process of the ignite-core and merging it first to
> the Micronaut repository?
>
> -
> Denis
>
>
> On Wed, Aug 26, 2020 at 3:35 PM Michael Pollind
> wrote:
>
> > Also you need to sign the CLA since you add a commit to my branch.
> >
> > branch: https://github.com/pollend/micronaut-ignite/tree/feature/rework
> > linked PR:
> https://github.com/micronaut-projects/micronaut-ignite/pull/33
> >
> > --
> > Michael Pollind
> >
> > On Wed, Aug 26, 2020 at 3:29 PM Denis Magda wrote:
> >
> > > Could you share the full path to the branch? Don't want to pick a wrong
> > one
> > > accidentally.
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Aug 26, 2020 at 2:47 PM Michael Pollind
> > > wrote:
> > >
> > > > so that clears up the extra flag for micronaut-cache. just need to
> > > > intercept the default IgniteConfiguration bean and update the
> > > > configuration. if you pull my latest changes from the rework branch
> you
> > > can
> > > > look at the docs for that micronaut module. `./gradlew docs`.
> > Finalizing
> > > > the docs should be the last part of this. The configuration from my
> > > > perspective seems pretty much there. Is there anything else that is
> > > > missing?
> > > >
> > > > On Wed, Aug 26, 2020 at 1:31 PM Denis Magda
> wrote:
> > > >
> > > > > 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 {
> > > > > > @Override
> > > > > > public IgniteConfiguration
> > > > > > onCreated(BeanCreatedEvent event) {
> > > > > > IgniteConfiguration configuration = event.getBean();
> > > > > > configuration.setIgniteInstanceName("instance-a");
> > > > > > return configuration;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 26, 2020 at 11:31 AM Denis Magda
> > > > 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
Re: Micronaut/Ignite
Also you need to sign the CLA since you add a commit to my branch.
branch: https://github.com/pollend/micronaut-ignite/tree/feature/rework
linked PR: https://github.com/micronaut-projects/micronaut-ignite/pull/33
--
Michael Pollind
On Wed, Aug 26, 2020 at 3:29 PM Denis Magda wrote:
> Could you share the full path to the branch? Don't want to pick a wrong one
> accidentally.
>
>
> -
> Denis
>
>
> On Wed, Aug 26, 2020 at 2:47 PM Michael Pollind
> wrote:
>
> > so that clears up the extra flag for micronaut-cache. just need to
> > intercept the default IgniteConfiguration bean and update the
> > configuration. if you pull my latest changes from the rework branch you
> can
> > look at the docs for that micronaut module. `./gradlew docs`. Finalizing
> > the docs should be the last part of this. The configuration from my
> > perspective seems pretty much there. Is there anything else that is
> > missing?
> >
> > On Wed, Aug 26, 2020 at 1:31 PM Denis Magda wrote:
> >
> > > Nice catch!
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Aug 26, 2020 at 12:16 PM Michael Pollind
> > > 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 {
> > > > @Override
> > > > public IgniteConfiguration
> > > > onCreated(BeanCreatedEvent event) {
> > > > IgniteConfiguration configuration = event.getBean();
> > > > configuration.setIgniteInstanceName("instance-a");
> > > > return configuration;
> > > > }
> > > > }
> > > >
> > > >
> > > > On Wed, Aug 26, 2020 at 11:31 AM Denis Magda
> > 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
Re: Micronaut/Ignite
so that clears up the extra flag for micronaut-cache. just need to
intercept the default IgniteConfiguration bean and update the
configuration. if you pull my latest changes from the rework branch you can
look at the docs for that micronaut module. `./gradlew docs`. Finalizing
the docs should be the last part of this. The configuration from my
perspective seems pretty much there. Is there anything else that is
missing?
On Wed, Aug 26, 2020 at 1:31 PM Denis Magda wrote:
> Nice catch!
>
> -
> Denis
>
>
> On Wed, Aug 26, 2020 at 12:16 PM Michael Pollind
> 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 {
> > @Override
> > public IgniteConfiguration
> > onCreated(BeanCreatedEvent event) {
> > IgniteConfiguration configuration = event.getBean();
> > configuration.setIgniteInstanceName("instance-a");
> > return configuration;
> > }
> > }
> >
> >
> > On Wed, Aug 26, 2020 at 11:31 AM Denis Magda 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
> > > 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
> > > > 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
>
Re: Micronaut/Ignite
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 {
@Override
public IgniteConfiguration
onCreated(BeanCreatedEvent event) {
IgniteConfiguration configuration = event.getBean();
configuration.setIgniteInstanceName("instance-a");
return configuration;
}
}
On Wed, Aug 26, 2020 at 11:31 AM Denis Magda 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
> 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
> > 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 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 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 an
Re: Micronaut/Ignite
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 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 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 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
>> > 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 cacheConfigurations,
>> >
>> Collection providers,
>> >
>> Collection executorConfigurations,
>> >
>> Optional platformConfigurations,
>> >Optional
>> collisionSpi,
>> >
>> Collection loadBalancingSpis,
>> >Collection
>> failoverSpis,
>> >@ConsistencyId
>> Optional consistencyId,
>> >@IgniteLifecycle
>> Collection lifecycleBeans) {
>> > configuration.setCacheConfiguration(cacheConfigurations.toArray(new
>> CacheConfiguration[0]))
>> > .setPluginProviders(providers.toArray(new PluginProvider[0]))
>> > .setExecutorConfiguration(executorConfigurations.toArray(new
>> ExecutorCon
Re: Any reason to keep ClientConfiguration final?
micronaut setups the configuration at compile time. so a lot of the
configuration is through annotating classes. There are two main methods for
this ConfigurationProperties/ConfigurationBuilder. ConfigurationBuilder
maps properties to a factor and ConfigurationProperties maps properties
onto a class object. It's the difference between wrapping a class and
extending it. You can see the differences by looking at these two items
listed below and the sample code that creates the thin client. It's more
useful just to inject the configuration vs having to unwrap the bean.
Hopefully this helps clarify things. The code is just a bit more clumsy
using a wrapping class this way, but it's not too bad from my perspective.
Thin Client:
https://github.com/micronaut-projects/micronaut-ignite/blob/7c767288f540f5ae6dd0479252db9a1c5072d120/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteThinClientConfiguration.java
Thick Client:
https://github.com/micronaut-projects/micronaut-ignite/blob/7c767288f540f5ae6dd0479252db9a1c5072d120/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java
...
/**
* Ignite {@link ClientConfiguration}.
* @param clientConfiguration client configuration
* @return client configuration
*/
@Bean
@Named("default")
@Primary
@Requires(beans = DefaultIgniteThinClientConfiguration.class)
public ClientConfiguration igniteClientConfiguration(@IgnitePrimary
DefaultIgniteThinClientConfiguration clientConfiguration) {
return clientConfiguration.getConfiguration();
}
/**
*
* @param configuration client configuration
* @return Ignite Thin client
*/
@EachBean(ClientConfiguration.class)
@Singleton
@Bean(preDestroy = "close")
public IgniteClient igniteThinClient(ClientConfiguration configuration) {
try {
return Ignition.startClient(configuration);
} catch (Exception e) {
LOG.error("Failed to instantiate Ignite Client: " + e.getMessage(), e);
throw e;
}
}
...
--
Michael Pollind
On Mon, Aug 24, 2020 at 1:43 PM Igor Sapego wrote:
> No objections from my side.
>
> What is the case? Some kind of new thin client?
>
> Best Regards,
> Igor
>
>
> On Mon, Aug 24, 2020 at 11:40 PM Pavel Tupitsyn
> wrote:
>
>> Denis,
>>
>> No objections to the removal of the "final" modifier from my side.
>> However, the use case sounds a bit weird to me, can you please describe
>> it in more detail?
>>
>> Thanks,
>> Pavel
>>
>> On Mon, Aug 24, 2020 at 10:47 PM Denis Magda wrote:
>>
>>> @Pavel Tupitsyn , @Igor Sapego
>>> ,
>>>
>>> Michael has been integrating Ignite with Micronaut and we hit some
>>> limitations related to the configuration. To simplify the configuration of
>>> the thin client instances, we need to inherit from the ClientConfiguration
>>> class
>>> <https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java>
>>> but
>>> the class is made final.
>>>
>>> Is any good reason for keeping its final? Otherwise, I'll go ahead and
>>> remove that modifier.
>>>
>>>
>>> -
>>> Denis
>>>
>>
Re: Micronaut/Ignite
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 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 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
> > 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 cacheConfigurations,
> >
> Collection providers,
> >
> Collection executorConfigurations,
> >
> Optional platformConfigurations,
> >Optional
> collisionSpi,
> >
> Collection loadBalancingSpis,
> >Collection
> failoverSpis,
> >@ConsistencyId
> Optional consistencyId,
> >@IgniteLifecycle
> Collection 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
> > wrote:
> >
> > here is an updated example what the yaml looks like now.
> >
> > ignite:
> > enabled: true
> > comunication-spi:
Re: Micronaut/Ignite
8eaf2d8aa171700a928eb/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 > 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 > > 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 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 > > > 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 > > &g
Re: Micronaut/Ignite
Hi Saikat, What fields in TcpCommunicationSPI are you referring to? On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra 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 > 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 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 > > 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: > > > > 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 > 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. > > > > > > > > > > > >
Re: Micronaut/Ignite
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 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 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: > > 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 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
Re: Micronaut/Ignite
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:
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 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
> 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
> > 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 config
Re: Micronaut/Ignite
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 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 > 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 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 "enablePartition
Re: Micronaut/Ignite
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 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 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 >> wrote: >> >> > oh, so we probably don't need to work with multiple instances. This is >> what >> > I have in the current master branch. I be
Re: Micronaut/Ignite
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 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 > 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/ > &
Re: Micronaut/Ignite
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 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: > partitionAwarenessEnabled: true > transactionConfiguration: > defaultTxConcurrency:... > defaultTxTimeout > > - > Denis > > > On Mon, Aug 17, 2020 at 6:50 PM Michael Pollind > 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 > > ). > > > >
Re: Micronaut/Ignite
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
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
> 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.
> >
> >
> >
> http
Re: Micronaut/Ignite
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 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 > 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 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 > > > 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/ > > >> > > > > > >
Re: Micronaut/Ignite
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 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 > 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/ >> >
Re: Micronaut/Ignite
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/
