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

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

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.

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,

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

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

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:

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

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

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: