RE: OOM when using Ignite as HDFS Cache

Hi, zhangshuai.ustc , is this problem solved? Can we help more on the subject? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/OOM-when-using-Ignite-as-HDFS-Cache-tp11900p12297.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: HDP, Hive + Ignite

Hi, Alena 1. logs you have attached show some errors, but , in fact, I cannot deal with them until the way to reproduce the problem is known. 2. Here I mean that IGFS (write-through cache built upon another file system) and the Ignite map-reduce engine (jobtracker on port 11211) are 2

Re: Ignite Web Sessions Caching Failover question

Hello Val, I did looked at this possibility but this is something needs to be done on Spring boot side so spring boot should provide us the capability to manage user session in memory when the distributed cache cant get connected, kind of a fall back mechanism. I still believe this is something

Re: Can sql query read from back up partion instead of primary partition

No, readFromBackup does not affect SQL in any way. Sergi 2017-04-27 12:52 GMT+03:00 neerajbhatt : > Hi All > > We are looking to scale our sql query read operation, can we read from > backup partitions instead of primary partitions ? > > There is something called

Re: tcp-disco-ip-finder-cleaner

Here is the ignite config -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/tcp-disco-ip-finder-cleaner-tp12249p12293.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Can sql query read from back up partion instead of primary partition

Hi All We are looking to scale our sql query read operation, can we read from backup partitions instead of primary partitions ? There is something called "mode", and setting "readFromBackup". They seem to work for cache operations. Is there similar concept for SQL queries. Thanks -- View

Re: tcp-disco-ip-finder-cleaner

Hi Would you please share ignite config? On Tue, Apr 25, 2017 at 9:55 PM, gatorjh wrote: > We are running Ignite 1.8.0 within Docker on an AWS instance. Ignite > registers with Zookeeper. We use a BasicAddressResolver in the Ignite > config > so that only the Docker host IP

Re: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing - Query execution is too long

Hi, 1. You may want to make Ignite use index on APPLICATION_DATE or even composite index of two fields: EXPIRATION_DT, APPLICATION_DATE. Ignite does not support HINTs in 1.x version, but it will be added in 2.0. 2. I see no query plan for second query. Try to run in from console with explain

Re: Write behind and eventual consistency

Hi Val, Our use case : 1. Read records from file 2. Do computations on each record 3. Put them in the cache and persistence using write behind. 4. When all the records from file are processed, updated in Cache and also persisted to DB, we want to trigger some other process which will do next

Re: CacheAbstractJdbcStore batch deleteAll bug.

Hi, Gordon. Do you have a reproducer we could debug? Thanks. On Wed, Apr 26, 2017 at 9:50 AM, Gordon Reid (Nine Mile) < gordon.r...@ninemilefinancial.com> wrote: > Actually the fix will be a little more complicated, because the variable > “em” has already been updated to the new type before

RE: Write behind and eventual consistency

Hi Val, the use case is the following 1) Load data into the database from an external system 2) Once ready load it into the grid 3) Process something that does massive write behinds 4) Take a snapshot of the results (or) Do a backup of the tables <<--- At this point I need the eventual

Re: Ignite Web Sessions Caching Failover question

It seems that it will always throw an exception in this scenario. However it makes sense to me, are you willing to contribute this improvement? -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Web-Sessions-Caching-Failover-question-tp12240p12286.html

RE: Write behind and eventual consistency

Hi Steve, What is the business use case behind this? -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Write-behind-and-eventual-consistency-tp12242p12285.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Offheap and max memory

> It looks like documentation is misleading. I partially agree. CacheConfiguration is validated during creation of a cache (when you call a ignite.getOrCreateCache) and some mismatches like OFFHEAP mode with offHeapMaxMemory equlas -1 will be resolved. Maybe it makes sense to add explanation to

AW: Network Discovery inside docker containers

Ok, I heard from chat that I should use an https://ignite.apache.org/releases/1.8.0/javadoc/org/apache/ignite/configuration/BasicAddressResolver.html ADDRESS Resolver. I will look into it. Thankx Lukas Lukas Lentner, B. Sc. St.-Cajetan-Straße 13 81669 München Deutschland Fon: +49 /

Network Discovery inside docker containers

Hi, I have a question about Discovery in a Docker environment. I have multiple machines running multiple docker containers with ignite in it. I want to use JDBC Discovery. I give every container a dedicated communication port and discovery port. My understanding was that the Database Table

Re: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing - Query execution is too long

Hi Andrew, Thanks for the reply. Removing index did helped. But we got the same issue in one more query. Could you let us know how to what could be the issue here. 02:51:52.591 [http-/172.30.8.97:8443-27] WARN org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing - Query execution is