Re: Ordering updates on backups in ATOMIC cache

2015-09-11 Thread Yakov Zhdanov
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

2015-09-11 Thread Andrey Gura
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


Re: SqlQuery.pageSize is ignored in replicated cache

2015-09-11 Thread Denis Magda

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

2015-09-11 Thread Anton Vinogradov
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 Setrakyan 
wrote:

> 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

2015-09-11 Thread Pavel Konstantinov
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

2015-09-11 Thread Sergey Kozlov
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

2015-09-11 Thread Dmitriy Setrakyan
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 Gura  wrote:

> 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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Alexey Kuznetsov
It seems that we should write: servers-heap: xxGB, clients-heap: yyGB

On Fri, Sep 11, 2015 at 4:32 PM, Sergey Kozlov  wrote:

> 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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Alexey Goncharuk (JIRA)
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

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Pavel Tupitsyn (JIRA)
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...

2015-09-11 Thread ptupitsyn
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: ptupitsyn 
Date:   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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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.

2015-09-11 Thread Vladimir Ozerov (JIRA)
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

2015-09-11 Thread Kevin (JIRA)
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)