Berlin and S.F. Bay Area meetups next week featuring Apache Ignite
Igniters, Next week there are a number of events featuring Apache Ignite -- including meetups in Berlin and the San Francisco Bay Area. On Tuesday there will be an excellent webinar titled, “Redis Replaced: Why Companies Now Choose Apache® Ignite™ to Improve Application Speed and Scale.” This webinar, hosted by Ignite PMC Denis Magda, starts at 11 a.m. Pacific time. Be sure to RSVP! Speaking of Denis, in case you missed it, he published a fantastic blog post yesterday headlined: “Apache Cassandra vs. Apache Ignite: Strong Consistency and Transactions.” This post, part of a series on Apache Cassandra vs. Apache Ignite, examines the pros & cons of NoSQL databases in terms of consistency and ACID transactions compared with how Apache Ignite handles them. Meanwhile, starting on Tuesday, Ignite evangelist Akmal Chaudhri touches down in Berlin where he’ll begin a three-day meetup roadshow. First up is the Java Usergroup Berlin-Brandenburg Meetup on Tuesday evening. Akmal’s talk is titled, "Skyrocket Java applications with the open-source Apache Ignite." Then on Wednesday he’s back behind the podium – this time at the Berlin Kubernetes Meetup. This meetup is sold-out! Great job, Akmal! There are 125 RSVPs and another 88 on the waiting list. Akmal’s talk is called, "Distributed Database DevOps Dilemmas? Kubernetes to the rescue!" On Thursday (Feb. 22), Akmal takes the stage at the Big Data, Berlin Meetup. This event’s venue is large enough so there won’t be a need for a waiting list. Even so, an impressive 156 people have so far RSVP’d. His talk there is titled, “Apache Ignite: the in-memory hammer in your data science toolkit.” Backing up a day and to the Bay is the fabulous Bay Area In-Memory Computing Meetup on Feb. 21 in Santa Clara. Eden Kim, Chair of the SNIA Solid State Storage Technical Work Group will present, "Real-world workloads and in-memory performance." His discussion will compare real-world datacenter workloads between NVMe SSD block IO and NVDIMM-N byte addressable load-store.” Ignite committer Valentin Kulichenko will also speak on, "Building consistent and highly available distributed systems with Apache Ignite and GridGain." If you’re at the HQ then RSVP now and make plans to catch all the action. Read more about all of next week’s event here and have a great weekend!
Re: How to explicitly stop write behind
Matt, GridCacheWriteBehindStore#stop() is an internal method that is invoked when cache is destroyed or node is stopped, you should not call it explicitly. Alexey's suggestion makes sense to me, I think you should implemented it this way. -Val -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: How to stop explicitly write behind
Thanks Alexey, that is exactly what we are doing now actually. We're hoping to find a way to avoid this though, to ensure our nodes aren't doing any unnecessary work, as well as avoiding unexpected results if the backend system comes back up. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: How to explicitly stop write behind
OK so digging a little further, I found GridCacheWriteBehindStore#stop() - but still no idea how to get access to this. - Matt -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: How to stop explicitly write behind
Matt, I think it is CacheStoreAdapter that should handle such a requirement. Implement your CacheStoreAdapter to handle the underlying storage being out of service. Ignite will continue calling CacheStoreAdapter's methods but they would not go to the underlying store.
How to stop explicitly write behind
Hi, I've got a CacheStoreAdapter that implements write behind, and there's a case where the backend storage API can go away. And when this happens, I'd like to have Ignite _not_ continue to call the write behind methods, and instead, just stop. Otherwise, Ignite will completely hammer the non-existent backend and logging goes crazy. So is there a way to tell Ignite to stop calling the CacheStoreAdapter's write behind methods? - Matt -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Moving a folder when deployed on Kubernetes
Hi, The folder ignite-rest-http can be added to the classpath by modifying the value of OPTION_LIBS section in https://apacheignite.readme.io/docs/kubernetes-deployment#section-ignite-pods-deployment It should be as below: - name: OPTION_LIBS value: ignite-kubernetes,ignite-rest-http Regards, Vishwas -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: QR factorisation
Hi Pieter, You are right and we use MGS for QR factorization, so it`s just typo in javadoc. Right now we don`t plan to change QR factorization algorithm. We will fix this typo. Thanks for heads up. Regards, Yury PS: right now we use QR factorization as analytical solver for linear regression, but this isn`t good solution because of hight computation complexity. And we already implemented gradient descent and LSQR for linear regression. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Moving a folder when deployed on Kubernetes
Hi, Your question has been asked before: http://apache-ignite-users.70518.x6.nabble.com/Web-Console-on-Kubernetes-Cluster-td18591.html Unfortunately, there's no docker image for web agent, so you need to prepare and install it manually like any other regular java application. thanks, Mike. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
QR factorisation
In the comments of ignite/modules/ml/src/main/java/org/apache/ignite/ml/math/decompositions/QRDecomposition.java it is noted that the QR factorisation is calculated using Householder reflections. The implementation however is using Modified Gram-Schmidt. Does this mean that future versions will Householder instead of MGS? Kind regards Pieter -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
RE: Affinity Key Annotation
Ah, thanks! From: Alexey Kukushkin [mailto:kukushkinale...@gmail.com] Sent: Friday, February 16, 2018 5:40 AM To: user@ignite.apache.org Subject: Re: Affinity Key Annotation Michael, data colocation work like this: * Ignite caches have partitions assignments so that primary partitions with same ID are assigned to the same physical location (node). * When you put/get data to a cache, Ignite maps value of a field annotated with @AffinityKeyMapped to a partition. * Thus, entries having same value of the @AffinityKeyMapped field go to the same location. In your example if recordNo and policyNo are equal then the entries will go to the same location.
Re: Affinity Key Annotation
Michael, data colocation work like this: - Ignite caches have partitions assignments so that primary partitions with same ID are assigned to the same physical location (node). - When you put/get data to a cache, Ignite maps value of a field annotated with @AffinityKeyMapped to a partition. - Thus, entries having same value of the @AffinityKeyMapped field go to the same location. In your example if recordNo and policyNo are equal then the entries will go to the same location.
