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
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/ > >> > > >
[DISCUSS] Migration of Kafka data streaming module
Hi, I wanted to discuss the proposal of migration of Kafka data streaming module from Ignite repository to Ignite Extensions repository. We earlier considered to not migrate Kafka module as mentioned here https://cwiki.apache.org/confluence/display/IGNITE/IEP-36:+Modularization#IEP36:Modularization-IgniteModules I am considering the kafka module migration will be beneficial in following respect: 1. It will allow us to keep all the 3rd party data streaming modules in Ignite Extensions repo. 2. The teamcity Streamers project can be removed as it will no longer need to be maintained. 3. Overall improvement in nightly build time for Apache Ignite. Please let me know your thoughts. Regards, Saikat
BEAM-9045 Implement an Ignite runner using Apache Ignite compute grid
Hi, I have been working on implementing the Apache Ignite Runner to run Apache Beam pipeline. I have created IgniteRunner and IgnitePipelineOptions. I have implemented the normalize pipeline method and currently working on run method implementation for Pipeline and IgnitePipelineTranslator. Jira : https://issues.apache.org/jira/browse/BEAM-9045 PR : https://github.com/apache/beam/pull/12593 Please review and feel free to share any feedback or questions. Regards, Saikat
Re: Apache Ignite 3.0
Hi Val, Thank you for adding the Cleanup section and Removals list. Pavel, As part of Apache Ignite Roadmap we had mentioned we will add modernization of .NET. Are we still targeting it in Apache Ignite 3.0 release? https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap Regards, Saikat On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam wrote: > If you want to make is simpler to have the components that you want, but > have that be immutable at install time you could take an approach similar > to the way spring does it with their initializer ( > https://start.spring.io/ ) as an example... Basically the concept being > something that produces a set of configurations that are used to define > what the environment looks like ( these could be k8s objects ) they could > be spring-configuration objects? They could be something that you develop > all upon ignite ( probably wouldn’t recommend this approach ) there seems > to be plenty of these types of things already > > Example > * https://spring.io/guides/gs/centralized-configuration > * > https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html > > And I'm by no means saying to use spring these are just examples that I > came across > > I'm thinking the outcome needs to be a platform config of source ( that > can be checked in for those doing gitops ) and maybe ends up as a config > map for those doing k8s, and some other fashion for those doing something > else. > > Honestly I am not deep enough into the internals of ignite to know how > this might work for the platform, was more describing what I'm seeing from > a bigger picture trend > > Regards > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > Bottomline Technologies > Office: 603-501-6446 | Mobile: 603-570-8418 > www.bottomline.com > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" > wrote: > > Hi Ilya, > > Can you please describe your vision of how it should work? > > Let's say, I want to set up a cluster of several standalone server > nodes > with a couple of optional modules enabled. What are my steps? > > -Val > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam < > adam.carb...@bottomline.com> > wrote: > > > Good Morning from the EastCoast > > > > I have to agree that the larger industry is tending towards > immutability, > > and that you build once and test, then you promote/migrate that > immutable > > binary object, be is a library or a docker image etc... however > there are > > still patterns that allow you to determine at install/or deployment > time ( > > helm as an example, you choose based on your values what the package > > installs/provides ) It just isn't decided at runtime but install and > often > > in a gitops type world that is determined by configuration as code. > I think > > run time is difficult to manage especially in our increasingly > > containerized world. > > > > Regards. > > > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > > Bottomline Technologies > > Office: 603-501-6446 | Mobile: 603-570-8418 > > www.bottomline.com > > > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" > wrote: > > > > Hello! > > > > On the contrary, I would suggest that apache2 way was outdated > even at > > times when apache was all rage. > > > > Now the nginx approach is prevalent: on devops phase, assemble a > custom > > bundle with all plugins included, store it somewhere, and ship > it to > > production as a whole to remove any on-the-fly uncertainty from > > production. > > > > This is what docker does, but also maven, which downloads > dependencies > > during build. You do not need to download anything in runtime, > except > > for > > experimental deployments. You need to be all set before runtime > starts. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov : > > > > > Hi, Val. > > > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko < > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > Hi Petr, > > > > > > > > I agree -- we should better modularize the platform. The > current > > way if > > > very error-prone, especially during upgrades -- any changes > made > > within > > > IGNITE_HOME (configs, scripts, modules, etc.) must be merged > with a > > new > > > version of the package. There is no standard way of doing this. > > > > > > > > However, I'm a bit concerned with your suggestion regarding > custom > > > dependency management. Can you please elaborate on how you > think it > > should > > > work? Are there tools we can reuse for this purpose? I would >
[MTCGA]: new failures in builds [5540462] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master ~Build Apache Ignite~ https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:44:27 15-08-2020
Operations block when cache is not active.
Hi I was told by Dennis to post this here. But basically he said to propose a change not to make operations block when the cluster is in inactive state. The operation should throw an exception to let the application continue working. Here is the original thread. http://apache-ignite-users.70518.x6.nabble.com/Operation-block-on-Cluster-recovery-rebalance-td33579.html
