Re: Ordering updates on backups in ATOMIC cache
If non sync evicts are configured, then cyclic buffer should be used. No? Thanks! Yakov On Sep 11, 2015 09:03, "Alexey Goncharuk"wrote: > Guys, > > I was thinking about ordering updates on backups so that we are able to > send entry processors on backups as we do in TRANSACTIONAL cache. > > What if we send not only the new version of an entry, but also the old > version (the one that was replaced). > > Let's say we have an entry with version v0, and we apply updates with > versions v1, v2, v3. Instead of sending just (val1, ver1), (val2, ver2), > (val3, ver3) we can send (val1, ver0->ver1), (val2, ver1->ver2), (val3, > ver2->ver3). In this case even if updated are processed on a backup node in > a different order, we can queue updates and wait until all updates are > received (like we did for ordered messages a while ago). > > The only concern that I have is that independent evicts cannot happen on a > backup node because the version of an entry should always match on primary > and backup nodes - so we should always initiate evict from primary node and > use version to evict an entry - basically, treat evict as a remove, but > with no write-through. > > Thoughts? >
Re: vert.x integration
Hi, I want to run Vert.x HA tests with the latest changes in Ignite. After it I'll check all related tickets and give answer. Other good news: bugs that I found in Vert.x test framework was fixed by Vert.x team. On Thu, Sep 10, 2015 at 11:09 PM, Dmitriy Setrakyanwrote: > This question goes to Andrey Gura. > > Andrey, I remember you have been working on Vert.x integration and got > stuck on one bug in Ignite that had to be fixed before hand. Was that bug > fixed by now? Can you let us know how close we are in your opinion to > completing this integration? > > D. > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
Re: SqlQuery.pageSize is ignored in replicated cache
Good, Sergi I've merged the test to 1.4 branch and assigned IGNITE-613 on you. When you fix the issue please validate the fix with this test and unmute the test by removing 'fail(...)' statement at the beginning of its body. -- Denis On 9/10/2015 4:00 PM, Sergi Vladykin wrote: Something like this could happen because replicated cache is incorrectly expected to have the whole dataset locally. I will take a look . Sergi 2015-09-10 15:38 GMT+03:00 Denis Magda: Hi Sergi, I was fixing one of the many SQL query tests ( https://issues.apache.org/jira/browse/IGNITE-613) when found that there is an issue in how 'pageSize' parameter is processed by Ignite SQL engine. Test does the following. At the beginning it starts 3 server nodes and 1 client node. Fills a replicated cache with 1000 entries. Right after that the following query is executed from the client node QueryCursor > q = cache.query(new SqlQuery (Integer.class,"_key >= 0 order by _key").setPageSize(10)); Then the test gets the first key in order to pre-load the first page: q.iterator().next().getKey() However, the iterator loads all 1000 entries ignoring the page size that is equal to 10. I see that the iterator already holds all the entries in a list and GridMapQueryExecutor.qryRess map on servers side is empty meaning that the whole data was transferred to the client. Is this a bug or expected behavior? -- Denis
Re: Added missing pages to Ignite documentation
Dmitriy, Thanks for improving javadoc. I've updated https://apacheignite.readme.io/docs/topology-validation according to your changes. On Fri, Sep 11, 2015 at 2:38 AM, Dmitriy Setrakyanwrote: > Thanks Anton, > > I made a few edits. Please take a look and see if you agree. > > D. > > On Thu, Sep 10, 2015 at 3:08 AM, Anton Vinogradov < > avinogra...@gridgain.com> > wrote: > > > Done, thanks for tips > > > > On Thu, Sep 10, 2015 at 12:44 PM, Yakov Zhdanov > > wrote: > > > > > I think that main docs should be in TopologyValidator interface. Other > > > places should be briefly documented and contain a link to validator > > > interface. > > > > > > Thanks! > > > > > > Yakov > > > On Sep 10, 2015 11:22, "Anton Vinogradov" > > > wrote: > > > > > > > Usage explaned at place where TopologyValidator used - at > > > > CacheConfiguration.setTopologyValidator(tv). > > > > Is it necessary to dublicate usage javadoc to TopologyValidator > class? > > > > > > > > On Thu, Sep 10, 2015 at 11:00 AM, Dmitriy Setrakyan < > > > dsetrak...@apache.org > > > > > > > > > wrote: > > > > > > > > > On Thu, Sep 10, 2015 at 12:35 AM, Anton Vinogradov < > > > > > avinogra...@gridgain.com > > > > > > wrote: > > > > > > > > > > > Dmitriy, > > > > > > TopologyValidator's javadoc was improved as a part of these > > changes. > > > > > > > > > > > > > > > > I just checked in master, and this is the only javadoc I can find > for > > > > > TopologyValidator class: > > > > > > > > > > /** > > > > > * Topology validator. > > > > > */ > > > > > > > > > > A bit too pithy for my taste :) > > > > > > > > > > > > > > > > On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan < > > > > > dsetrak...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Thanks Anton! > > > > > > > > > > > > > > By the way, I just noticed that the TopologyValidator has no > > > javadoc. > > > > > > > Perhaps it makes sense to add it as well? > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > > > > > > > avinogra...@gridgain.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I've created new pages on redme.io. > > > > > > > > These pages describe usage of Ignite expiry policies and > > topology > > > > > > > > validator. > > > > > > > > Urls: > > > > > > > > https://apacheignite.readme.io/docs/expiry-policies > > > > > > > > https://apacheignite.readme.io/docs/topology-validation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
NPE
Hi, Igniters, I'm faced with NPE and ask anybody to take a look at the filed ticket: https://issues.apache.org/jira/browse/IGNITE-1405 Perhaps we should fix it now in 1.4 Pavel.
Heap size in topology snapshot
Hi I've found that heap size of client nodes used in total size of grid heap size: [11:35:56,444][INFO][main][GridDiscoveryManager] Topology snapshot [ver=4, servers=4, clients=0, CPUs=4, heap=8.0GB] [11:36:04,556][INFO][disco-event-worker-#45%null%][GridDiscoveryManager] Added new node to topology: TcpDiscoveryNode [id=3cc4213b-b4a7-4f45-88b3-07cbdc3488b6, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 192.168.100.10], sockAddrs=[ksm-homepc/169.254.90.143:0, /0:0:0:0:0:0:0:1:0, /127.0.0.1:0, /192.168.100.10:0], discPort=0, order=5, intOrder=5, lastExchangeTime=1441960564491, loc=false, ver=1.4.0#20150910-sha1:071586e2, isClient=true] [11:36:04,558][INFO][disco-event-worker-#45%null%][GridDiscoveryManager] Topology snapshot [ver=5, servers=4, clients=1, CPUs=4, heap=9.0GB] But really only server nodes heap used for a grid and it might confuse the user for available heap on grid if a topology has a few server nodes and many clients. -- Sergey Kozlov
Re: vert.x integration
Andrey, According to IGNITE-1079, the Vert.x work is blocked by 3 other issues: https://issues.apache.org/jira/browse/IGNITE-1079 Would be nice if folks in the community gave an update on these. Thanks, D. On Fri, Sep 11, 2015 at 9:59 AM, Andrey Gurawrote: > Hi, > > I want to run Vert.x HA tests with the latest changes in Ignite. After it > I'll check all related tickets and give answer. > > Other good news: bugs that I found in Vert.x test framework was fixed by > Vert.x team. > > On Thu, Sep 10, 2015 at 11:09 PM, Dmitriy Setrakyan > > wrote: > > > This question goes to Andrey Gura. > > > > Andrey, I remember you have been working on Vert.x integration and got > > stuck on one bug in Ignite that had to be fixed before hand. Was that bug > > fixed by now? Can you let us know how close we are in your opinion to > > completing this integration? > > > > D. > > > > > > -- > Andrey Gura > GridGain Systems, Inc. > www.gridgain.com >
[jira] [Created] (IGNITE-1422) .Net: Marshalling can be optimized for fixed-length objects.
Vladimir Ozerov created IGNITE-1422: --- Summary: .Net: Marshalling can be optimized for fixed-length objects. Key: IGNITE-1422 URL: https://issues.apache.org/jira/browse/IGNITE-1422 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 Sometimes we can guess user object length in advance: 1) Strict rule: it is "reflective" and contains only fixed-length fields. 2) Speculative rule: It is "marshal aware", contains only fixed-length fields and there is only one metadata "path". In these cases we can do the following: 1) No tracking of length and raw offset. 2) Header can be written as one memcpy() rather than as multiple int/byte/bool writes. We need to have a fallback strategy for a cases when new metadata path appears or user write raw data. It is very easy: if expected and actual lengths differ at the end, set proper values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1421) .Net: Optimize writes of ultra-dense structures.
Vladimir Ozerov created IGNITE-1421: --- Summary: .Net: Optimize writes of ultra-dense structures. Key: IGNITE-1421 URL: https://issues.apache.org/jira/browse/IGNITE-1421 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 There is a case when we can dramatically increase marshal/unmarshal performance: 1) Type is a structure; 2) It contains only integer/float/double primitive types with well-defined; memory layout which is consistent with our serialization protocol; 3) We are sure that there are no gaps in it's memory layout. 4) User writes it as "marshal-aware" and fields write order is consistent with memory layout. In this case we can copy the whole structure into our stream with a single memcpy() operation. And we can read it from the stream as easy as [pointer dereference + position shift] (provided that target is on the stack). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Heap size in topology snapshot
It seems that we should write: servers-heap: xxGB, clients-heap: yyGB On Fri, Sep 11, 2015 at 4:32 PM, Sergey Kozlovwrote: > Hi > > I've found that heap size of client nodes used in total size of grid heap > size: > > [11:35:56,444][INFO][main][GridDiscoveryManager] Topology snapshot [ver=4, > servers=4, clients=0, CPUs=4, heap=8.0GB] > [11:36:04,556][INFO][disco-event-worker-#45%null%][GridDiscoveryManager] > Added new node to topology: TcpDiscoveryNode > [id=3cc4213b-b4a7-4f45-88b3-07cbdc3488b6, addrs=[0:0:0:0:0:0:0:1, > 127.0.0.1, 192.168.100.10], sockAddrs=[ksm-homepc/169.254.90.143:0, > /0:0:0:0:0:0:0:1:0, /127.0.0.1:0, /192.168.100.10:0], discPort=0, order=5, > intOrder=5, lastExchangeTime=1441960564491, loc=false, > ver=1.4.0#20150910-sha1:071586e2, isClient=true] > [11:36:04,558][INFO][disco-event-worker-#45%null%][GridDiscoveryManager] > Topology snapshot [ver=5, servers=4, clients=1, CPUs=4, heap=9.0GB] > > But really only server nodes heap used for a grid and it might confuse the > user for available heap on grid if a topology has a few server nodes and > many clients. > > -- > Sergey Kozlov > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
[jira] [Created] (IGNITE-1410) .Net: Implement IEvents.RecordLocal.
Vladimir Ozerov created IGNITE-1410: --- Summary: .Net: Implement IEvents.RecordLocal. Key: IGNITE-1410 URL: https://issues.apache.org/jira/browse/IGNITE-1410 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1450) Excessive exceptions are printed out during cache/node stop
Alexey Goncharuk created IGNITE-1450: Summary: Excessive exceptions are printed out during cache/node stop Key: IGNITE-1450 URL: https://issues.apache.org/jira/browse/IGNITE-1450 Project: Ignite Issue Type: Bug Affects Versions: 1.1.4 Reporter: Alexey Goncharuk Assignee: Yakov Zhdanov Fix For: ignite-1.4 In my unit tests, I start and stop caches in quick succession and my logs are full of the following exceptions: 6983 [exchange-worker-#114%t1-1%] ERROR GridCachePartitionExchangeManager - Runtime error caught during grid runnable execution: GridWorker [name=partition-exchanger, gridName=t1-1, finished=false, isCancelled=false, hashCode=1934136092, interrupted=false, runner=exchange-worker-#114%t1-1%] class org.apache.ignite.IgniteException: Failed to wait for affinity ready future for topology version: AffinityTopologyVersion [topVer=2, minorTopVer=2] at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:443) at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:398) at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:363) at org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodes(GridCacheAffinityManager.java:201) at org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.localNode(GridCacheAffinityManager.java:303) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemandPool.assign(GridDhtPartitionDemandPool.java:1028) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:260) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1076) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108) at java.lang.Thread.run(Thread.java:745) Caused by: class org.apache.ignite.IgniteCheckedException: Failed to wait for topology update, cache (or node) is stopping. at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.readyFuture(GridAffinityAssignmentCache.java:316) at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:437) ... 9 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1413) .Net: Get rid of set -> map conversion in PlatformDotNetCacheStore.writeAll
Vladimir Ozerov created IGNITE-1413: --- Summary: .Net: Get rid of set -> map conversion in PlatformDotNetCacheStore.writeAll Key: IGNITE-1413 URL: https://issues.apache.org/jira/browse/IGNITE-1413 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 This is a legacy artifact from a veeery old API which is currently removed. Just pass set without unnecessary conversions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1414) .Net: support async/await in the API via extension methods
Vladimir Ozerov created IGNITE-1414: --- Summary: .Net: support async/await in the API via extension methods Key: IGNITE-1414 URL: https://issues.apache.org/jira/browse/IGNITE-1414 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 Currently to get awaitable target (Task) for async operation, user have to do the following (pseudocode): {code} target.ExecuteOperation(); IFuture fut = target.CurrentFuture(); Task task = fut.ToTask(); {code} This is too complex. We need to think how to minimize this boilerplate code. Extensions + lambdas appears to be good candidates for this. E.g.: {code} Task task = target.DoAsync(t => t.Execute()); {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1433) .Net: Add GridException.JavaStackTrace
Vladimir Ozerov created IGNITE-1433: --- Summary: .Net: Add GridException.JavaStackTrace Key: IGNITE-1433 URL: https://issues.apache.org/jira/browse/IGNITE-1433 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 Propagate java stack trace as a string in ExceptionUtils.GetException and write it to a new field in IgniteException class. This will simplify debugging for us both locally and when getting error reports from clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1435) Platform .Net: Make it possible to sign core assembly with msbuild
Pavel Tupitsyn created IGNITE-1435: --- Summary: Platform .Net: Make it possible to sign core assembly with msbuild Key: IGNITE-1435 URL: https://issues.apache.org/jira/browse/IGNITE-1435 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: ignite-1.4 Currently we use InternalsVisibleTo attribute in Apache.Ignite.Core AssemblyInfo, which prevents signing the assembly with msbuild /p:SignAssembly file. Need to wrap them in a preprocessor check so that msbuild flag /p:DefineConstants will exclude that code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] ignite pull request: IGNITE-1435 Platform .Net: Make it possible t...
GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/84 IGNITE-1435 Platform .Net: Make it possible to sign core assembly with msbuild You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1435 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/84.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #84 commit 3e694599b59ca2d941f76c2ffe8b103888c41e9f Author: ptupitsynDate: 2015-09-11T14:50:07Z IGNITE-1435 Platform .Net: Make it possible to sign core assembly with msbuild --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-1441) CPP: Support filter in SCAN queries.
Vladimir Ozerov created IGNITE-1441: --- Summary: CPP: Support filter in SCAN queries. Key: IGNITE-1441 URL: https://issues.apache.org/jira/browse/IGNITE-1441 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1448) CPP: Implement cache iterators.
Vladimir Ozerov created IGNITE-1448: --- Summary: CPP: Implement cache iterators. Key: IGNITE-1448 URL: https://issues.apache.org/jira/browse/IGNITE-1448 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1424) .Net: Add tests for BIG_ENDIANs.
Vladimir Ozerov created IGNITE-1424: --- Summary: .Net: Add tests for BIG_ENDIANs. Key: IGNITE-1424 URL: https://issues.apache.org/jira/browse/IGNITE-1424 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Minor Fix For: ignite-1.5 As all our hardware uses LITTLE_ENDIAN byte order, BIG_ENDIAN was never tested properly. We do not know, whether it works. We do not know it's performance characteristics. Need to add ability to override endian final flags in both .Net and Java (e.g. through a system property or through "Ex" configuration) and then run unit tests with it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1438) CPP: Implement transactions API.
Vladimir Ozerov created IGNITE-1438: --- Summary: CPP: Implement transactions API. Key: IGNITE-1438 URL: https://issues.apache.org/jira/browse/IGNITE-1438 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1444) CPP: Implement cache expiry policy.
Vladimir Ozerov created IGNITE-1444: --- Summary: CPP: Implement cache expiry policy. Key: IGNITE-1444 URL: https://issues.apache.org/jira/browse/IGNITE-1444 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1442) CPP: Implement cache async mode.
Vladimir Ozerov created IGNITE-1442: --- Summary: CPP: Implement cache async mode. Key: IGNITE-1442 URL: https://issues.apache.org/jira/browse/IGNITE-1442 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1426) .Net: Improve/add forked tests
Vladimir Ozerov created IGNITE-1426: --- Summary: .Net: Improve/add forked tests Key: IGNITE-1426 URL: https://issues.apache.org/jira/browse/IGNITE-1426 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 Run forked tests from a separate directory to better cover assembly loading code and examples scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1434) Platforms: Ensure that @IgniteInstanceResource is set only on setters, not fields.
Vladimir Ozerov created IGNITE-1434: --- Summary: Platforms: Ensure that @IgniteInstanceResource is set only on setters, not fields. Key: IGNITE-1434 URL: https://issues.apache.org/jira/browse/IGNITE-1434 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Fix For: ignite-1.5 Currently @IgniteInstanceResource is set on fields. And then we have to deal with complex initiailzation logic. Instead, we must set this annotation on setters which will perform initialization immediately. Furthermore, when possible we must avoid injection in favor of direct setter calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1437) CPP: Implement SQL fields query.
Vladimir Ozerov created IGNITE-1437: --- Summary: CPP: Implement SQL fields query. Key: IGNITE-1437 URL: https://issues.apache.org/jira/browse/IGNITE-1437 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1440) CPP: Implement cache store.
Vladimir Ozerov created IGNITE-1440: --- Summary: CPP: Implement cache store. Key: IGNITE-1440 URL: https://issues.apache.org/jira/browse/IGNITE-1440 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1439) CPP: Implement futures.
Vladimir Ozerov created IGNITE-1439: --- Summary: CPP: Implement futures. Key: IGNITE-1439 URL: https://issues.apache.org/jira/browse/IGNITE-1439 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1445) CPP: Implement cache invoke.
Vladimir Ozerov created IGNITE-1445: --- Summary: CPP: Implement cache invoke. Key: IGNITE-1445 URL: https://issues.apache.org/jira/browse/IGNITE-1445 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.5 This will require well-defined architecture for generic callback calls from Java core to CPP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1449) DiscoverySpi interface should not reference TcpDiscoverySpi implementation
Kevin created IGNITE-1449: - Summary: DiscoverySpi interface should not reference TcpDiscoverySpi implementation Key: IGNITE-1449 URL: https://issues.apache.org/jira/browse/IGNITE-1449 Project: Ignite Issue Type: Bug Reporter: Kevin In DiscoverySpi, the setDataExchange and setMetricsProvider methods should return type DiscoverySpi instead of TcpDiscoverySpi. It should be possible that implementations of DiscoverySpi do not extend TcpDiscoverySpi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)