HI Andrey, i have two records for my query. i did not see same results if i hit the same query number times. Results in number of records are empty, 1, 2.
Thanks On 22 March 2017 at 10:49, Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > Hi Anil, > > What do you mean "the results are not same"? It looks like query should > return a single row. > If there would be more than one row in result and order is not specified > in query, then it is possible to get rows in different order due to data > transferred from other nodes asynchronously. > > > > > > On Tue, Mar 21, 2017 at 7:02 AM, Anil <anilk...@gmail.com> wrote: > >> Hi Andrew, >> >> #1 - it is very simple select query - select * from person hwere personid >> = 'something'; >> i just ran the query in for loop and noticed the results are not same. >> >> #2 - it is stable topology. swap is configured. but this test was done >> when full load is completed and some compute job going on for other cache. >> >> Please let me know if you have any questions. thanks. >> >> Thanks. >> >> On 20 March 2017 at 21:07, Andrey Mashenkov <andrey.mashen...@gmail.com> >> wrote: >> >>> Hi Anil, >>> >>> 1. Would you please share sql query text? >>> >>> 2. Is it happening on unstable topology or during rebalancing? Or may be >>> eviction\expire policy or swap is configured? >>> >>> On Mon, Mar 20, 2017 at 5:41 PM, Anil <anilk...@gmail.com> wrote: >>> >>>> Yes. i am using partition cache only with no joins :) >>>> >>>> how about #2 ? >>>> >>>> On 20 March 2017 at 19:20, Andrey Mashenkov <andrey.mashen...@gmail.com >>>> > wrote: >>>> >>>>> Hi Anil, >>>>> >>>>> I should although mention that Replicated caches can participate in >>>>> same query with partitioned caches regardless a degree of parallelizm. >>>>> This limitation relates to partitioned caches only. >>>>> >>>>> On Mon, Mar 20, 2017 at 3:54 PM, Andrey Mashenkov < >>>>> andrey.mashen...@gmail.com> wrote: >>>>> >>>>>> Hi Anil, >>>>>> >>>>>> It is ok. Doc says *"If a query contains JOINs, then all the >>>>>> participating caches must have the same degree of parallelism.".* >>>>>> Possibly, it is easy to fix but there can be unobvious limitations, >>>>>> so we need a time to make a POC. >>>>>> I believe, it will be fixed in future releases. >>>>>> >>>>>> On Mon, Mar 20, 2017 at 1:11 PM, Anil <anilk...@gmail.com> wrote: >>>>>> >>>>>>> Hi Andrey, >>>>>>> >>>>>>> I see few more issues with IGNITE-4826 >>>>>>> >>>>>>> 1. queryParallelism should be used for all caches for which queries >>>>>>> are used other it throws following exception. >>>>>>> >>>>>>> Caused by: java.sql.SQLException: Failed to query Ignite. >>>>>>> at org.apache.ignite.internal.jdb >>>>>>> c2.JdbcStatement.executeQuery(JdbcStatement.java:131) >>>>>>> at org.apache.ignite.internal.jdb >>>>>>> c2.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:76) >>>>>>> at org.apache.commons.dbcp2.Deleg >>>>>>> atingPreparedStatement.executeQuery(DelegatingPreparedStatem >>>>>>> ent.java:83) >>>>>>> at org.apache.commons.dbcp2.Deleg >>>>>>> atingPreparedStatement.executeQuery(DelegatingPreparedStatem >>>>>>> ent.java:83) >>>>>>> >>>>>>> Caused by: javax.cache.CacheException: class >>>>>>> org.apache.ignite.IgniteException: Using indexes with different >>>>>>> parallelism levels in same query is forbidden. >>>>>>> at org.apache.ignite.internal.pro >>>>>>> cessors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:760) >>>>>>> at org.apache.ignite.internal.jdb >>>>>>> c2.JdbcQueryTask.call(JdbcQueryTask.java:161) >>>>>>> at org.apache.ignite.internal.jdb >>>>>>> c2.JdbcStatement.executeQuery(JdbcStatement.java:116) >>>>>>> ... 13 more >>>>>>> 2. query is not returning same result if it is hit number of times. >>>>>>> >>>>>>> please let me know if these are known issues. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Andrey V. Mashenkov >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Andrey V. Mashenkov >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Andrey V. Mashenkov >>> >> >> > > > -- > Best regards, > Andrey V. Mashenkov >
