Apache Ignite

GridGain Developer Hub - Apache Ignitetm

Welcome to the Apache Ignite developer hub run by GridGain. Here you'll find comprehensive guides and documentation to help you start working with Apache Ignite as quickly as possible, as well as support if you get stuck.


GridGain also provides Community Edition which is a distribution of Apache Ignite made available by GridGain. It is the fastest and easiest way to get started with Apache Ignite. The Community Edition is generally more stable than the Apache Ignite release available from the Apache Ignite website and may contain extra bug fixes and features that have not made it yet into the release on the Apache website.


Let's jump right in!


Documentation     Ask a Question     Download


Javadoc     Scaladoc     Examples
Ask A Question



Free form queries broken in 1.0?

I had the following query... String sqlStr = "SELECT * FROM MyTrx WHERE fullName ='" + myRequest.getFullName() + "' "; I know I don't have to do long form for simple query like above, but I'm trying to debug a longer query that uses UNION. So reduced my query to the shortest possible query... MyModel... public class MyTrx implements Serializable { private static final long serialVersionUID = -2604193489375322501L; @QuerySqlField(index = true) Long id; @QuerySqlField(index = true) String fullName; } The config... CacheConfiguration<Long, com.xxx.model.MyTrx> orgCacheCfg = new CacheConfiguration<>("myCache"); orgCacheCfg.setCacheMode(CacheMode.PARTITIONED); orgCacheCfg.setAtomicityMode(CacheAtomicityMode.ATOMIC); orgCacheCfg.setBackups(0); orgCacheCfg.setIndexedTypes(Long.class, com.xxx.model.MyTrx.class); And I get... Apr 07, 2015 3:38:54 PM org.apache.ignite.logger.java.JavaLogger error SEVERE: Failed to execute local query: GridQueryRequest [reqId=1, pageSize=1024, space=myCache, qrys=[GridCacheSqlQuery [qry=SELECT "myCache".MYTRX._KEY __C0, "myCache".MYTRX._VAL __C1 FROM "myCache".MYTRX WHERE SELECT MYTRX._KEY, MYTRX._VAL, MYTRX.ID, MYTRX.FULLNAME FROM "myCache".MYTRX WHERE FULLNAME = 'johnsmith', params=[]]]] class org.apache.ignite.IgniteCheckedException: Failed to execute SQL query. at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:597) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:615) at org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:201) at org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:117) at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:353) at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:294) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:714) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:805) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:742) at org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:534) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:439) at com.xxx.service.myCache.lambda$start$4(myCache.java:113) at com.xxx.service.myCache$$Lambda$48/1471131776.handle(Unknown Source) at io.vertx.core.eventbus.impl.EventBusImpl$HandlerRegistration.handle(EventBusImpl.java:1097) at io.vertx.core.eventbus.impl.EventBusImpl.lambda$doReceive$110(EventBusImpl.java:737) at io.vertx.core.eventbus.impl.EventBusImpl$$Lambda$69/2022112580.handle(Unknown Source) at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:263) at io.vertx.core.impl.ContextImpl$$Lambda$4/400136488.run(Unknown Source) at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor.lambda$new$180(OrderedExecutorFactory.java:91) at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor$$Lambda$2/1870252780.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.h2.jdbc.JdbcSQLException: Data conversion error converting "(1, Transaction [id=1, fullName=johnsmith], 1, johnsmith)"; SQL statement: SELECT "myCache".MYTRX._KEY __C0, "myCache".MYTRX._VAL __C1 FROM "myCache".MYTRX WHERE SELECT MYTRX._KEY, MYTRX._VAL, MYTRX.ID, MYTRX.FULLNAME FROM "myCache".MYTRX WHERE FULLNAME = 'johnsmith' [22018-175] at org.h2.message.DbException.getJdbcSQLException(DbException.java:332) at org.h2.message.DbException.get(DbException.java:161) at org.h2.value.Value.convertTo(Value.java:878) at org.h2.value.Value.getBoolean(Value.java:387) at org.h2.expression.Expression.getBooleanValue(Expression.java:180) at org.h2.command.dml.Select.queryFlat(Select.java:529) at org.h2.command.dml.Select.queryWithoutCache(Select.java:632) at org.h2.command.dml.Query.query(Query.java:297) at org.h2.command.dml.Query.query(Query.java:284) at org.h2.command.dml.Query.query(Query.java:36) at org.h2.command.CommandContainer.query(CommandContainer.java:91) at org.h2.command.Command.executeQuery(Command.java:196) at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:106) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:594) ... 22 more Caused by: java.lang.NumberFormatException at java.math.BigDecimal.<init>(BigDecimal.java:550) at java.math.BigDecimal.<init>(BigDecimal.java:383) at java.math.BigDecimal.<init>(BigDecimal.java:806) at org.h2.value.Value.convertTo(Value.java:825) ... 33 more

Posted by John Smith about a year ago


Running multiple NEAR_ONLY caches in same JVM for production redeployment

We have run into a strange issue that is preventing us from moving forward with Ignite in our application at this time. We are using the Data Grid feature (strictly) running a single grid (currently composed of four standalone nodes on four separate systems) with a partitioned cache and one backup configured. Then we have a web application that is configured to use a NEAR_ONLY cache that connects to that grid. This is all working fine … except when we redeploy our application. We are running on WebLogic Server 10.3 which supports production redeployment such that you can deploy a new version of your application at the same time as the old version. When this happens, WebLogic will route all new sessions to the new version and any old sessions will remain on the old version until they timeout, at which time the old version is decommissioned. This works fine (we’ve been doing it for years) but not with Ignite. Ignite complains upon startup with the error "MBean was already registered: org.apache:group=Kernal,name=Ignition”. We have tried several things to get around this but to no avail. Essentially it is trying to start another Ignite instance in the same JVM with the same configuration as the already running NEAR_CACHE instance. I see that the IgnitionEx.registerFactoryMbean method is checking to ensure that there is no Mbean registered , but oddly it is using effectively a hard-code value based upon the string "Kernal" and the simple class name of Ignition. I don't profess to fully understand why it wants no existing MBeans, but it does strike me as odd that it is using a hard-coded value. I have seen in the docs that multiple instances can run in the same JVM, but I haven't seen how to make it work (at least not within the context of a web application container where ManagementFactory.getPlatformMBeanServer() is going to return the same value as the first Ignite node that was started). I also tried calling Ignition.ignite(configuration) but that results in the following exception: org.apache.ignite.IgniteIllegalStateException: Grid instance was not properly started or was already stopped. I am very happy with Ignite, but unfortunately this issue is preventing me from being able to move forward with it. I hope I'm just missing something simple. I appreciate any help or guidance anyone can offer.

Posted by Eric Broyles about a year ago


How to improve query perfoamnce?

Hi running RC3 I have the following cache config.... <bean class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> <property name="requireSerializable" value="false"/> </bean> ... <bean parent="cache-template"> <property name="name" value="myCache"/> <property name="cacheMode" value="PARTITIONED"/> <property name="atomicityMode" value="ATOMIC"/> <property name="distributionMode" value="PARTITIONED_ONLY"/> <property name="backups" value="0"/> </bean> ... <bean id="cache-template" abstract="true" class="org.apache.ignite.configuration.CacheConfiguration"> <property name="startSize" value="1000000"/> <property name="queryIndexEnabled" value="true"/> </bean> My model look like so... public class MyModel { @QuerySqlField(index = true) Long id; @QuerySqlField(index = true) Integer someField1; @QuerySqlField(index = true) Integer someField2; @QuerySqlField(index = true) String someField3; @QuerySqlField(index = true) String someField14; @QuerySqlField(index = true) String someField5; @QuerySqlField(index = true) String someField6; @QuerySqlField(index = true) String someField7; @QuerySqlField(index = true) String someField8; @QuerySqlField(index = true) Long someField9; @QuerySqlField(index = true) String someField10; @QuerySqlField(index = true) String someField11; .. Setters and Getters here... } And in my application I run... // Do this once at startup... Ignite ignite = Ignition.start("cache.xml"); myCache= ignite.jcache("risk"); // Per http POST request in my servlet myCache.put(request.getId(), request); String sqlStr = "someField1 = ? OR " + "someField2 = ? OR " + "someField3 = ? OR " + "someField4 = ? OR " + "someField5= ? OR " + "someField6 = ? OR " + "someField7 = ? OR " + "someField8 = ? OR " + "someField9 = ?"; SqlQuery sql = new SqlQuery(MyModel.class, sqlStr); QueryCursor<Entry<Long, Transaction>> cursor = myCache.query(sql.setArgs(...)); for (Entry<Long, Transaction> t : cursor) size++; Even on a single node with verry few entries a couple thousand I am only able to execute about 200 queries per second at average 400ms. Is there anything I can do to improve the performance? The query at most will only ever return 1-2 records even if the data grid could reach millions of records.

Posted by John Smith about a year ago


Cache not loading correctly

I have a problem with a cache loader service that loads data into a cache at process start-up. If I run a single node, everything works fine and my log message shows the exact same number of items added to the cache as the calls: `ignite.jcache(cacheName).localSize(CachePeekMode.PRIMARY)` and `ignite.jcache(cacheName).size(CachePeekMode.PRIMARY)` return. If I then start more nodes running, then everything works as I'd expect and the full cache is balanced correctly across the cluster. The cache size remains the same overall, and the local caches show numbers indicating that the data has been shared between them correctly. Problems appear though when I start multiple nodes at the same time. My log message confirms that the same number of records were added to the cache but `ignite.jcache(cacheName).localSize(CachePeekMode.PRIMARY)` and `ignite.jcache(cacheName).size(CachePeekMode.PRIMARY)` both return a significantly lower number. On the last run my logs show that 1,163,076 records were added to the cache, but both the above method calls show only 376,879 entries. Running `ignite.jcache(cacheName).localSize(CachePeekMode.PRIMARY)` on the other nodes in the cluster consistently returns `0`. Have you seen problems like this, and can you suggest a fix? This looks like a cache balancing problem during the discovery phase to me. I don't want to have to start the primary node before the others at this will complicate the deployment and will mean that one node will have to hold all the records until the other nodes are running. Thanks, Steve.

Posted by Steve Neal about a year ago