Re: Unsubscribe

Hello! Please send email to this address: user-unsubscr...@ignite.apache.org It has to be from the e-mail box that you have subscribed to. Regards, -- Ilya Kasnacheev пт, 19 февр. 2021 г. в 01:02, Ryan Trollip : > I sent an unsubscribe request but am still getting emails. Please remove > fro

Re: Ignite 2.81. - NULL pointer exception

Hello! I have filed a ticket https://issues.apache.org/jira/browse/IGNITE-13475 Regards, -- Ilya Kasnacheev пт, 19 февр. 2021 г. в 02:24, narges saleh : > Was there a resolution for this issue? > > On Mon, Sep 7, 2020 at 9:40 AM Ilya Kasnacheev > wrote: > >> Hello! >> >> I wonder why there's

Re: very fast loading of very big table

Hello! Is there a chance that you have tried enabling streaming (data streamer) on the clients? Regards, -- Ilya Kasnacheev пт, 19 февр. 2021 г. в 10:10, : > Hi Denis, > > Data space is 3.7Gb according to MSSQL table properries > > Vladimir > > 9:47, 19 февраля 2021 г., Denis Magda : > > Hell

Re: very fast loading of very big table

> 295 million rows > 3 min 35 sec Agree with Ilya, DataStreamer should do this much faster, have you tried it? > 3.7Gb I would not call this "big" by any means today, when even the cheapest laptops have 8GB of RAM. On Fri, Feb 19, 2021 at 1:33 PM Ilya Kasnacheev wrote: > Hello! > > Is there

Re: very fast loading of very big table

Hi Vladimir, Did you try to use SQL command 'COPY FROM ' via thin JDBC? This command uses 'IgniteDataStreamer' to write data into cluster and parse CSV on the server node. PS. AFAIK IgniteDataStreamer is one of the fastest ways to load data. Hi Denis, Data space is 3.7Gb according to MSSQL

Re: very fast loading of very big table

What would be the difference between doing cache.putAll(all rows) and separating them by affinity key+executing putAll inside a compute job. If I'm not mistaken, doing putAll should end up splitting those rows by affinity key in one of the servers, right? Is there a comparison of that? On Fri, Feb

Re: very fast loading of very big table

I think it’s more that that putAll is mostly atomic, so the more records you save in one chunk, the more locking, etc. happens. Distributing as compute jobs means all the putAlls will be local which is beneficial, and the size of each put is going to be smaller (also beneficial). But that’s a l

Re: very fast loading of very big table

Hi folks, thanks for your interest in my work. I didn't try COPY FROM since I've tried to work with Ignite SQL a couple of years ago and didn't succeed. Probably because examples available aren't complete/downloadable/compilable (the paper [1] contains GitHub repo, that is my five cents in changin

Proper way to configure RDMS as persistent store

I followed the example in the Ignite documentation for how to configure Ignite to act as a cache with a postgres database. I have been able to implement the person example and have had success configuring ca

Re: very fast loading of very big table

> First of all, I tried to select the whole table as once Hmm, it looks like MSSQL data retrieval may be the bottleneck here, not Ignite. Can you run a test where some dummy data of the same size as real data is generated and inserted into Ignite, so that we test Ignite perf only, excluding MSSQL

Re: very fast loading of very big table

Pavel, maybe it's time to put your five-cent in. Can you share your code as a GitHub project? Maybe with the script to reproduce 6 GB of data. As for MSSQL data retrieval being the bottleneck - don't think so, I got 15 min load time for 1 node and 3.5 min time for 4 nodes. Looks like a linear dep

Corrupted B+ Tree Causing Repeated Crashes

We are encountering the following error repeatedly, which causes our node to crash: 2021-02-19 13:30:38,175 ERROR STDIO [pool-32-thread-5] {} Feb 19, 2021 1:30:38 PM org.apache.ignite.logger.java.JavaLogger error SEVERE: Critical system error detected. Will be handled accordingly to configured

Re: Corrupted B+ Tree Causing Repeated Crashes

Hello! What version of Apache Ignite are you using?   19.02.2021, 22:07, "Mitchell Rathbun (BLOOMBERG/ 731 LEX)" : > We are encountering the following error repeatedly, which causes our node to > crash: > > 2021-02-19 13:30:38,175 ERROR STDIO [pool-32-thread-5] {} Feb 19, 2021 > 1:30:38 PM org.

Re: Corrupted B+ Tree Causing Repeated Crashes

2.9.1 From: user@ignite.apache.org At: 02/19/21 14:18:44To: Mitchell Rathbun (BLOOMBERG/ 731 LEX ) , user@ignite.apache.org Subject: Re: Corrupted B+ Tree Causing Repeated Crashes Hello! What version of Apache Ignite are you using? 19.02.2021, 22:07, "Mitchell Rathbun (BLOOMBERG/ 731 LEX)"

Re: Corrupted B+ Tree Causing Repeated Crashes

Actually, we were using 2.7.5 when the data was corrupted. We upgraded to 2.9.1 without clearing the corrupted data and got the error that was posted in the first message. From: user@ignite.apache.org At: 02/19/21 14:18:44To: Mitchell Rathbun (BLOOMBERG/ 731 LEX ) , user@ignite.apache.org Su

Near Cache versus Continuous Query

Hi, I have a use case where I want a fully copy of a replicated cache on a subset of my thick clients. In this example, I have an ETL thick client that creates and updates a replicated cache in my server grid. I then have a series of webserver thick clients that I always want a fully up to date

Near Cache versus Continuous Query

Hi, I have a use case where I want a fully copy of a replicated cache on a subset of my thick clients. In this example, I have an ETL thick client that creates and updates a replicated cache in my server grid. I then have a series of webserver thick clients that I always want a fully up to date

Re: Near Cache versus Continuous Query

Hi, > it created a near cache on each server node There are two Near Cache modes: * Server Node Near Cache - configured once before cache start for all server nodes * Client Node Near Cache - configured dynamically on per-node basis Please make sure to use the second mode, like explained in the