[jira] [Updated] (IGNITE-1128) A single node without any load produces 200MB of garbage

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-1128:

Fix Version/s: (was: 1.6)

> A single node without any load produces 200MB of garbage 
> -
>
> Key: IGNITE-1128
> URL: https://issues.apache.org/jira/browse/IGNITE-1128
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Denis Magda
> Attachments: heap_profiling_one_node.png, ig-1128.png
>
>
> Just start one node with default-config.xml
> See attached screenshot from VisualVm.
> If I try to take heap dump from VisualVm it first do GC and heap dump is not 
> useful than.
> But in VisualVm memory profiler I see that some arrays of Objects constantly 
> generated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1358) PortableMarshaller: 'userType' flag is not written for objects of some types

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-1358:

Fix Version/s: (was: 1.5)

> PortableMarshaller: 'userType' flag is not written for objects of some types
> 
>
> Key: IGNITE-1358
> URL: https://issues.apache.org/jira/browse/IGNITE-1358
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
>
> The 'userType' flag is not written when the following classes are serialized:
> - enums;
> - object and enum arrays;
> - classes.
> This leads to the situation that the predefined types map is ignored during 
> deserialization and the type is always considered as user's.
> To support this feature requires changes in the portable protocol.
> For now there is a workaround in the code. 
> Ideally, the protocol must be changes and the workaround must be removed.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-801) [Test] GridCacheReplicatedDataStructuresFailoverSelfTest hangs on TC

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-801:
---
Fix Version/s: (was: 1.5)

> [Test] GridCacheReplicatedDataStructuresFailoverSelfTest hangs on TC
> 
>
> Key: IGNITE-801
> URL: https://issues.apache.org/jira/browse/IGNITE-801
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Shutak
>Assignee: Denis Magda
>  Labels: Muted_test
> Attachments: ignite-801.patch
>
>
> See GG-5306
> http://94.72.60.102/viewLog.html?buildId=113217=bt6=buildResultsDiv
> {noformat}
> 2013-05-31 10:39:07
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode):
> "Attach Listener" daemon prio=10 tid=0x03a94800 nid=0x648 waiting on 
> condition [0x]
>java.lang.Thread.State: RUNNABLE
> "tcp-disco-sock-reader-#2408%a940475f-1965-484a-8a43-0a1fcc3bf292" prio=10 
> tid=0x7f06f8b1a000 nid=0x42d runnable [0x7f0702d84000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.read(SocketInputStream.java:150)
>   at java.net.SocketInputStream.read(SocketInputStream.java:121)
>   at 
> org.gridgain.grid.marshaller.jdk.GridJdkMarshallerInputStreamWrapper.read(GridJdkMarshallerInputStreamWrapper.java:47)
>   at 
> java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2308)
>   at 
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2321)
>   at 
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2792)
>   at 
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:799)
>   at java.io.ObjectInputStream.init(ObjectInputStream.java:299)
>   at 
> org.gridgain.grid.marshaller.jdk.GridJdkMarshallerObjectInputStream.init(GridJdkMarshallerObjectInputStream.java:30)
>   at 
> org.gridgain.grid.marshaller.jdk.GridJdkMarshaller.unmarshal(GridJdkMarshaller.java:115)
>   at 
> org.gridgain.grid.spi.discovery.tcp.GridTcpDiscoverySpi$SocketReader.body(GridTcpDiscoverySpi.java:3985)
>   at org.gridgain.grid.spi.GridSpiThread.run(GridSpiThread.java:56)
> "Thread-1905" prio=10 tid=0x7f06f8268000 nid=0x428 waiting on condition 
> [0x7f06e1f29000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.gridgain.grid.kernal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:89)
>   at org.gridgain.grid.kernal.GridKernal.stop0(GridKernal.java:1629)
>   - locked 0x00078a53c600 (a 
> org.gridgain.grid.util.GridBreaker)
>   at org.gridgain.grid.kernal.GridKernal.stop(GridKernal.java:1605)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop0(GridFactory.java:2295)
>   - locked 0x00078a473b60 (a 
> org.gridgain.grid.GridFactory$GridNamedInstance)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop(GridFactory.java:2256)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance$2.run(GridFactory.java:2223)
> "Thread-1911" prio=10 tid=0x026b1000 nid=0x420 waiting on condition 
> [0x7f06e6af4000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.gridgain.grid.kernal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:89)
>   at org.gridgain.grid.kernal.GridKernal.stop0(GridKernal.java:1629)
>   - locked 0x000789b76068 (a 
> org.gridgain.grid.util.GridBreaker)
>   at org.gridgain.grid.kernal.GridKernal.stop(GridKernal.java:1605)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop0(GridFactory.java:2295)
>   - locked 0x00078a4738f8 (a 
> org.gridgain.grid.GridFactory$GridNamedInstance)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop(GridFactory.java:2256)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance$2.run(GridFactory.java:2223)
> "SIGTERM handler" daemon prio=10 tid=0x01ec2800 nid=0x41e in 
> Object.wait() [0x7f06e8316000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1258)
>   - locked 0x00078a473948 (a 
> org.gridgain.grid.GridFactory$GridNamedInstance$2)
>   at java.lang.Thread.join(Thread.java:1332)
>   at 
> java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
>   at 
> java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
>   at java.lang.Shutdown.runHooks(Shutdown.java:123)
>   at java.lang.Shutdown.sequence(Shutdown.java:167)
>   at java.lang.Shutdown.exit(Shutdown.java:212)
>   - locked

[jira] [Updated] (IGNITE-845) TcpDiscoveryCloudIpFinderSelfTest.testAmazonWebServices always fails on public TC

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-845:
---
Fix Version/s: (was: 1.5)

> TcpDiscoveryCloudIpFinderSelfTest.testAmazonWebServices always fails on 
> public TC
> -
>
> Key: IGNITE-845
> URL: https://issues.apache.org/jira/browse/IGNITE-845
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: sprint-4
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> AWS didn't authorize us when the amazon test is run on the public TC from 
> docker containers. Everything is fine on the private TC (configuration is 
> identical on both TCs). Noted that ignite-aws module's tests are also failing 
> on the public TC. Probably there is some docker + aws related issue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-893) Implement adaptive internal buffer's initial size in OptimizedMarshaller

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-893:
---
Fix Version/s: (was: 1.6)

> Implement adaptive internal buffer's initial size in OptimizedMarshaller
> 
>
> Key: IGNITE-893
> URL: https://issues.apache.org/jira/browse/IGNITE-893
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Denis Magda
>Assignee: Denis Magda
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1644) .Net: DateTime.Kind is lost during serialization

2015-10-09 Thread Pavel Tupitsyn (JIRA) 
Pavel  Tupitsyn created IGNITE-1644:
---

 Summary: .Net: DateTime.Kind is lost during serialization
 Key: IGNITE-1644
 URL: https://issues.apache.org/jira/browse/IGNITE-1644
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


For example, we write and then read from the same stream (locally):

{code}
var dt = DateTime.Now;
writer.WriteObject(dt);

var dt2 = reader.ReadObject();
Assert.AreEqual(dt, dt2);  // fail
{code}

This happens because we always write DateTime as UTC and lose DateTime.Kind, so 
on deserialization we do not know whether ToLocal should be called.

Possible solutions:
* write .Net DateTime in a different format, not compatible with Java (breaks 
queries)
* 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1571) .Net: Improve Guid and DateTime reader/writer interface.

2015-10-09 Thread Vladimir Ozerov (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950085#comment-14950085
 ] 

Vladimir Ozerov commented on IGNITE-1571:
-

Pavel,
Lets's just rollback all API changes, add exception in case of null appeared in 
a structure and keep the rest minor fixes.

> .Net: Improve Guid and DateTime reader/writer interface.
> 
>
> Key: IGNITE-1571
> URL: https://issues.apache.org/jira/browse/IGNITE-1571
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> Currently we force user to write Guid and DateTime as nullables. We do this 
> to be more compatible with Java.
> But user is more likely to operate on plain types: Guid, Guid[], DateTime, 
> DateTime[]. 
> We need to add these methods to API, and rename existing ones to 
> "ReadNullableDateTime", etc..
> Note that while trivial to on writer side, it will be harder to implement for 
> readers. Currently we lookup by type ID, which will be equal for the type and 
> it's nullable counterpart. For this reason we probably must lookup by type ID 
> + type or simply by type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-801) [Test] GridCacheReplicatedDataStructuresFailoverSelfTest hangs on TC

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-801:
---
Fix Version/s: 1.5

> [Test] GridCacheReplicatedDataStructuresFailoverSelfTest hangs on TC
> 
>
> Key: IGNITE-801
> URL: https://issues.apache.org/jira/browse/IGNITE-801
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Shutak
>Assignee: Denis Magda
>  Labels: Muted_test
> Fix For: 1.5
>
> Attachments: ignite-801.patch
>
>
> See GG-5306
> http://94.72.60.102/viewLog.html?buildId=113217=bt6=buildResultsDiv
> {noformat}
> 2013-05-31 10:39:07
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode):
> "Attach Listener" daemon prio=10 tid=0x03a94800 nid=0x648 waiting on 
> condition [0x]
>java.lang.Thread.State: RUNNABLE
> "tcp-disco-sock-reader-#2408%a940475f-1965-484a-8a43-0a1fcc3bf292" prio=10 
> tid=0x7f06f8b1a000 nid=0x42d runnable [0x7f0702d84000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.read(SocketInputStream.java:150)
>   at java.net.SocketInputStream.read(SocketInputStream.java:121)
>   at 
> org.gridgain.grid.marshaller.jdk.GridJdkMarshallerInputStreamWrapper.read(GridJdkMarshallerInputStreamWrapper.java:47)
>   at 
> java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2308)
>   at 
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2321)
>   at 
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2792)
>   at 
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:799)
>   at java.io.ObjectInputStream.init(ObjectInputStream.java:299)
>   at 
> org.gridgain.grid.marshaller.jdk.GridJdkMarshallerObjectInputStream.init(GridJdkMarshallerObjectInputStream.java:30)
>   at 
> org.gridgain.grid.marshaller.jdk.GridJdkMarshaller.unmarshal(GridJdkMarshaller.java:115)
>   at 
> org.gridgain.grid.spi.discovery.tcp.GridTcpDiscoverySpi$SocketReader.body(GridTcpDiscoverySpi.java:3985)
>   at org.gridgain.grid.spi.GridSpiThread.run(GridSpiThread.java:56)
> "Thread-1905" prio=10 tid=0x7f06f8268000 nid=0x428 waiting on condition 
> [0x7f06e1f29000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.gridgain.grid.kernal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:89)
>   at org.gridgain.grid.kernal.GridKernal.stop0(GridKernal.java:1629)
>   - locked 0x00078a53c600 (a 
> org.gridgain.grid.util.GridBreaker)
>   at org.gridgain.grid.kernal.GridKernal.stop(GridKernal.java:1605)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop0(GridFactory.java:2295)
>   - locked 0x00078a473b60 (a 
> org.gridgain.grid.GridFactory$GridNamedInstance)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop(GridFactory.java:2256)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance$2.run(GridFactory.java:2223)
> "Thread-1911" prio=10 tid=0x026b1000 nid=0x420 waiting on condition 
> [0x7f06e6af4000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.gridgain.grid.kernal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:89)
>   at org.gridgain.grid.kernal.GridKernal.stop0(GridKernal.java:1629)
>   - locked 0x000789b76068 (a 
> org.gridgain.grid.util.GridBreaker)
>   at org.gridgain.grid.kernal.GridKernal.stop(GridKernal.java:1605)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop0(GridFactory.java:2295)
>   - locked 0x00078a4738f8 (a 
> org.gridgain.grid.GridFactory$GridNamedInstance)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance.stop(GridFactory.java:2256)
>   at 
> org.gridgain.grid.GridFactory$GridNamedInstance$2.run(GridFactory.java:2223)
> "SIGTERM handler" daemon prio=10 tid=0x01ec2800 nid=0x41e in 
> Object.wait() [0x7f06e8316000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1258)
>   - locked 0x00078a473948 (a 
> org.gridgain.grid.GridFactory$GridNamedInstance$2)
>   at java.lang.Thread.join(Thread.java:1332)
>   at 
> java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
>   at 
> java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
>   at java.lang.Shutdown.runHooks(Shutdown.java:123)
>   at java.lang.Shutdown.sequence(Shutdown.java:167)
>   at java.lang.Shutdown.exit(Shutdown.java:212)
>

[jira] [Updated] (IGNITE-1405) NPE during node start in corner case

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-1405:

Fix Version/s: (was: 1.5)

> NPE during node start in corner case
> 
>
> Key: IGNITE-1405
> URL: https://issues.apache.org/jira/browse/IGNITE-1405
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Denis Magda
>
> I'm tried to establish external connect to node during it starting
> {code}
> [14:07:29,284][SEVERE][ignite-#45%rest-tester%][GridTcpRestProtocol] Failed 
> to process client request: GridClientTopologyRequest [includeMetrics=true, 
> includeAttrs=true]
> class org.apache.ignite.IgniteCheckedException: null
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6978)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:150)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.allNodes(GridDiscoveryManager.java:1421)
> at 
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.handleAsync(GridTopologyCommandHandler.java:100)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:226)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:79)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:133)
> ... 4 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1619) Platform .Net: Generic type is lost during array/collection serialization

2015-10-09 Thread Pavel Tupitsyn (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950165#comment-14950165
 ] 

Pavel  Tupitsyn commented on IGNITE-1619:
-

There is another problem with this ticket: adding TypeId that is not supported 
in Java can break Compute API and other things if user decides to use one of 
these onsupported types as a Job argument, for example. Java part won't be able 
to pass it around.

Let's stop this ticket until we have an ability to pass around unsopported 
types in Java.

> Platform .Net: Generic type is lost during array/collection serialization
> -
>
> Key: IGNITE-1619
> URL: https://issues.apache.org/jira/browse/IGNITE-1619
> Project: Ignite
>  Issue Type: Bug
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Pavel  Tupitsyn
>Assignee: Pavel  Tupitsyn
> Fix For: 1.5
>
>
> We do not serialize collection/array element type, so on deserialization we 
> can not recreate original collection. So generic arrays/collections can't be 
> used in job arguments, service arguments, etc.
> * We should keep current format for non-generic collections, arrays of 
> primitives, and arrays of objects
> * Generic collections and arrays should be written with new TypeIds (not 
> compatible with other platforms) and include type information



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-1572) .Net: Check if we can get rid of "WritePortableOrSerializable" method.

2015-10-09 Thread Pavel Tupitsyn (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941040#comment-14941040
 ] 

Pavel  Tupitsyn edited comment on IGNITE-1572 at 10/9/15 10:13 AM:
---

Good catch, I have removed these wrappers, since we have 
SerializableObjectHolder in Writer/Reader.
However, one test (TestPortableObjectInTask) has failed. We have 2 issues:
* .Net writes user objects as FullObj (103) or PortObj (27), but Java always 
returns them as PortObj (27), so we loose that information. Removed wrappers 
indirectly solved that problem.
* In KeepPortable mode with Serializable object, we return PortableUserObject 
[SerializableObjectHolder] to the user, which is a bug, caused by the first 
issue.


was (Author: ptupitsyn):
Good catch, I have remove these wrappers, since we have 
SerializableObjectHolder in Writer/Reader.
However, one test (TestPortableObjectInTask) has failed. We have 2 issues:
* .Net writes user objects as FullObj (103) or PortObj (27), but Java always 
returns them as PortObj (27), so we loose that information. Removed wrappers 
indirectly solved that problem.
* In KeepPortable mode with Serializable object, we return PortableUserObject 
[SerializableObjectHolder] to the user, which is a bug, causes by the first 
issue.

> .Net: Check if we can get rid of "WritePortableOrSerializable" method.
> --
>
> Key: IGNITE-1572
> URL: https://issues.apache.org/jira/browse/IGNITE-1572
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel  Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> We have lots of places where "WritePortableOrSerializable" routine is 
> invoked. It is not clear why do we need it provided that we already handle 
> [Serializable] classes properly. 
> Looks like we are able to get rid of it safely, aren't we? Need to 
> double-check.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.

2015-10-09 Thread Konstantin Boudnik (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951536#comment-14951536
 ] 

Konstantin Boudnik commented on IGNITE-1555:


Here's an idea: these assemblies are mostly for the downstream consumption, 
like Bigtop, etc. Let's call them {{ignite-integration}} and later on will be 
adding other ecosystem adapters and plugins for things like Flink, etc. Does it 
make sense?


> Combine ignite-hadoop and ignite-spark into signle ignite-accelerator 
> assembly.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
>  Issue Type: New Feature
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into 
> single assembly called ignite-accelerator. This will be advantageous for 
> downstream integrators like Bigtop, where all bits can be packaged together, 
> tested, and deployed with proper configurations and permissions to avoid 
> interoperability issues. A typical is when spark-shell starts an Ignite node 
> which crashes because user 'spark' isn't allowed to write into Ignite's 
> work-dir, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm

2015-10-09 Thread Chandresh Pancholi (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950050#comment-14950050
 ] 

Chandresh Pancholi commented on IGNITE-429:
---

How to check data added in streamer.

StormStreamer.java
getStreamer().addData(k, igniteGrid.get(k));

When i try fetching data in Test class i am getting Null.

> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm 
> and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable 
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm

2015-10-09 Thread Gianfranco Murador (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950055#comment-14950055
 ] 

Gianfranco Murador commented on IGNITE-429:
---

Hi Chandresh,  
I think that the test is more complex, in my opinion, 
You should start another node , insert data into the grid with the streamer and 
then retrieve the same grid and ensure that the same data were included. From 
the moment the single node is stopped we also lose the data entered in the grid.
I think it's difficult to get the test within 5 sec.

> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm 
> and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable 
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-1625) .Net: Remove Types serialization from Continuous Queries

2015-10-09 Thread Vladimir Ozerov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-1625.
---

> .Net: Remove Types serialization from Continuous Queries
> 
>
> Key: IGNITE-1625
> URL: https://issues.apache.org/jira/browse/IGNITE-1625
> Project: Ignite
>  Issue Type: Improvement
>  Components: interop
>Affects Versions: 1.5
>Reporter: Pavel  Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.5
>
>
> See ContinuousQueryFilterHolder class: it serializes KeyType and ValueType, 
> but this is redundant, since user filter already carries type information.
> * Remove type serialization
> * Leverage DelegateTypeDescriptor to get rid of reflection in 
> UnmanagedCallbacks.ContinuousQueryFilterCreate



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm

2015-10-09 Thread Chandresh Pancholi (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950036#comment-14950036
 ] 

Chandresh Pancholi commented on IGNITE-429:
---

Ignore above stack trace.

> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm 
> and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable 
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1093) Rebalancing with default parameters is very slow

2015-10-09 Thread Anton Vinogradov (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951275#comment-14951275
 ] 

Anton Vinogradov commented on IGNITE-1093:
--

Worked on fixing duplicate partition eviction attempts happens at the end of 
the rebalancing. In case cache contains 20m entries each node evicts 2gb of 
data when third nide join topology. As a result - there is throughput problems 
at the end of rebalancing.




Solution that works is to use singlethreadpool to evict partitions. In this 
case eviction is not so agressive and cause not so long pauses. But this 
solution gives no 100% guarantie that gc pause will be less than 
failureDetectionTimeout and supply node will not left topology.




Second checked solution is to split each partition's eviction to small parts, 
for example no more than 1000 entries. This will give chances for other 
callable submitted to system pool to be evecuted without long delays.

This scheme workes sometimes, but still have good chancess to have big gc 
pauses. 

I checked this solution and it passes 3 of 3 attemps, but when I decided to 
recheck it becomes to fail again.




I think that I tryed to solve result instead of reason.



Currently partitions evicted in a bulk way, for example using checkEvictions 
method, that way seems to be reason of long gc pauses.

Will be better to rent partitions step-by-step at 
EVT_CACHE_REBALANCE_PART_LOADED event.

In this case there will be less chances to have long gc pauses, uniformity in 
this case will be guaranted by rebalancing process that use limited threads 
count.



Thoughts?

> Rebalancing with default parameters is very slow
> 
>
> Key: IGNITE-1093
> URL: https://issues.apache.org/jira/browse/IGNITE-1093
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-7
>Reporter: Pavel Konstantinov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.5
>
> Attachments: Plot_ThroughputLatencyProbe_01.png, rebalancing.zip
>
>
> # Start one node with partitioned cache with one backup.
> # Load into the cache 40billions of keys using DataStreamer
> # Start second node on the same host



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-638) Implement IgniteSemaphore data structure

2015-10-09 Thread Valentin Kulichenko (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951199#comment-14951199
 ] 

Valentin Kulichenko commented on IGNITE-638:


Hi Vladislav,

I looked through the code and here are my comments:
# I don't see a single test for the new functionality. Please provide good 
coverage including multi-node tests with restarts.
# Example doesn't compile on line 56. Also I think it's a bit too complicated. 
It's main purpose is to show how to use the API, so it needs to be as simple as 
possible.
# {{GridCacheSemaphoreState.isFair()}} will always return {{false}}, because 
the constructor that sets it is never used. I believe it's a bug.
# You throw an exception if initial number of permits is negative. Java 
semaphore allows it and I think we should be consistent.
# Method names should not be abbreviated. E.g., 
{{GridCacheSemaphoreState.getCnt()}} should be 
{{GridCacheSemaphoreState.getCount()}}.
# Braces are not always used according to guidelines [1]. For example, see 
{{DataStructuresProcessor}}, lines 1319-1325.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-BracesandIdentation

> Implement IgniteSemaphore data structure
> 
>
> Key: IGNITE-638
> URL: https://issues.apache.org/jira/browse/IGNITE-638
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: sprint-9
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>  Labels: features, newbie
> Fix For: 1.5
>
>
> We need to add {{IgniteSemaphore}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteSemaphore}} should have similar API to 
> {{java.util.concurrent.IgniteSemaphore}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> permits and allow user threads to block whenever no more permits are 
> available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.

2015-10-09 Thread Konstantin Boudnik (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated IGNITE-1555:
---
Summary: Combine ignite-hadoop and ignite-spark into signle assembly for 
downstream consumption.  (was: Combine ignite-hadoop and ignite-spark into 
signle ignite-accelerator assembly.)

> Combine ignite-hadoop and ignite-spark into signle assembly for downstream 
> consumption.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
>  Issue Type: New Feature
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into 
> single assembly called ignite-accelerator. This will be advantageous for 
> downstream integrators like Bigtop, where all bits can be packaged together, 
> tested, and deployed with proper configurations and permissions to avoid 
> interoperability issues. A typical is when spark-shell starts an Ignite node 
> which crashes because user 'spark' isn't allowed to write into Ignite's 
> work-dir, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.

2015-10-09 Thread Konstantin Boudnik (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated IGNITE-1555:
---
Attachment: IGNITE-1555.patch

> Combine ignite-hadoop and ignite-spark into signle assembly for downstream 
> consumption.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
>  Issue Type: New Feature
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into 
> single assembly called ignite-accelerator. This will be advantageous for 
> downstream integrators like Bigtop, where all bits can be packaged together, 
> tested, and deployed with proper configurations and permissions to avoid 
> interoperability issues. A typical is when spark-shell starts an Ignite node 
> which crashes because user 'spark' isn't allowed to write into Ignite's 
> work-dir, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.

2015-10-09 Thread Konstantin Boudnik (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated IGNITE-1555:
---
Attachment: IGNITE-1555.patch

Latest patch for the {{integration}} edition

> Combine ignite-hadoop and ignite-spark into signle assembly for downstream 
> consumption.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
>  Issue Type: New Feature
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into 
> single assembly called ignite-accelerator. This will be advantageous for 
> downstream integrators like Bigtop, where all bits can be packaged together, 
> tested, and deployed with proper configurations and permissions to avoid 
> interoperability issues. A typical is when spark-shell starts an Ignite node 
> which crashes because user 'spark' isn't allowed to write into Ignite's 
> work-dir, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.

2015-10-09 Thread Konstantin Boudnik (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated IGNITE-1555:
---
Attachment: (was: IGNITE-1555.patch)

> Combine ignite-hadoop and ignite-spark into signle assembly for downstream 
> consumption.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
>  Issue Type: New Feature
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into 
> single assembly called ignite-accelerator. This will be advantageous for 
> downstream integrators like Bigtop, where all bits can be packaged together, 
> tested, and deployed with proper configurations and permissions to avoid 
> interoperability issues. A typical is when spark-shell starts an Ignite node 
> which crashes because user 'spark' isn't allowed to write into Ignite's 
> work-dir, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1647) CPP: Implement SqlFieldQuery

2015-10-09 Thread Igor Sapego (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950576#comment-14950576
 ] 

Igor Sapego commented on IGNITE-1647:
-

Following implementation is proposed:
1. New class {{SqlFiledsQuery}}.
2. New method for Cache class: {{QueryFieldsCursor Query(const 
SqlFiledsQuery&)}}.
3. New class {{QueryFieldsCursor}} with method {{FieldsRow GetNext()}}.
4. New class {{FieldsRow}} with methods {{T GetNext()}} and {{bool HasNext()}}.

> CPP: Implement SqlFieldQuery
> 
>
> Key: IGNITE-1647
> URL: https://issues.apache.org/jira/browse/IGNITE-1647
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.5
>
>
> Need to decide on interface of the SqlFieldQuery class in C++ and implement 
> it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1645) .Net: Throw exception on null flag in PortableReader when reading non-nullable value types

2015-10-09 Thread Pavel Tupitsyn (JIRA) 
Pavel  Tupitsyn created IGNITE-1645:
---

 Summary: .Net: Throw exception on null flag in PortableReader when 
reading non-nullable value types
 Key: IGNITE-1645
 URL: https://issues.apache.org/jira/browse/IGNITE-1645
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


Currently we always return default(T) when deserializing null value. So for 
value types there is no way  for the user to discern a missing cache key from a 
cache key with default value.

* throw exceptions when there is Null in stream and we are trying to read a 
value type
* update Cache API with Try* methods



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1646) .Net: IgniteGuid must be serializable and portable.

2015-10-09 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1646:
---

 Summary: .Net: IgniteGuid must be serializable and portable.
 Key: IGNITE-1646
 URL: https://issues.apache.org/jira/browse/IGNITE-1646
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Blocker
 Fix For: 1.5


1) User must be able to pass IgniteGuid over a wire using serializable 
semantics when serialized manually by user.
2) On the other hand, it must be portable for correct passing between Java and 
.Net.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1571) .Net: Improve Guid and DateTime reader/writer interface.

2015-10-09 Thread Pavel Tupitsyn (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950207#comment-14950207
 ] 

Pavel  Tupitsyn commented on IGNITE-1571:
-

Agree to revert API changes since we keep specialized methods only for Java 
interoperability.
However, we can't throw exceptions when there is null for value type. This 
breaks a lot of things. For example Cache.Get() will throw an error 
if there is no such key, which is incorrect.

> .Net: Improve Guid and DateTime reader/writer interface.
> 
>
> Key: IGNITE-1571
> URL: https://issues.apache.org/jira/browse/IGNITE-1571
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel  Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> Currently we force user to write Guid and DateTime as nullables. We do this 
> to be more compatible with Java.
> But user is more likely to operate on plain types: Guid, Guid[], DateTime, 
> DateTime[]. 
> We need to add these methods to API, and rename existing ones to 
> "ReadNullableDateTime", etc..
> Note that while trivial to on writer side, it will be harder to implement for 
> readers. Currently we lookup by type ID, which will be equal for the type and 
> it's nullable counterpart. For this reason we probably must lookup by type ID 
> + type or simply by type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-1571) .Net: Improve Guid and DateTime reader/writer interface.

2015-10-09 Thread Pavel Tupitsyn (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950207#comment-14950207
 ] 

Pavel  Tupitsyn edited comment on IGNITE-1571 at 10/9/15 11:34 AM:
---

Agree to revert API changes since we keep specialized methods only for Java 
interoperability.
However, we can't throw exceptions when there is null for value type. This 
breaks a lot of things. For example Cache.Get() will throw an error 
if there is no such key, which is incorrect.

Let's fix this separately: IGNITE-1645


was (Author: ptupitsyn):
Agree to revert API changes since we keep specialized methods only for Java 
interoperability.
However, we can't throw exceptions when there is null for value type. This 
breaks a lot of things. For example Cache.Get() will throw an error 
if there is no such key, which is incorrect.

> .Net: Improve Guid and DateTime reader/writer interface.
> 
>
> Key: IGNITE-1571
> URL: https://issues.apache.org/jira/browse/IGNITE-1571
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> Currently we force user to write Guid and DateTime as nullables. We do this 
> to be more compatible with Java.
> But user is more likely to operate on plain types: Guid, Guid[], DateTime, 
> DateTime[]. 
> We need to add these methods to API, and rename existing ones to 
> "ReadNullableDateTime", etc..
> Note that while trivial to on writer side, it will be harder to implement for 
> readers. Currently we lookup by type ID, which will be equal for the type and 
> it's nullable counterpart. For this reason we probably must lookup by type ID 
> + type or simply by type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1646) .Net: IgniteGuid must be serializable and portable.

2015-10-09 Thread Vladimir Ozerov (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950276#comment-14950276
 ] 

Vladimir Ozerov commented on IGNITE-1646:
-

Looks like there is no need to mark it portable. Serializable should be enough.

> .Net: IgniteGuid must be serializable and portable.
> ---
>
> Key: IGNITE-1646
> URL: https://issues.apache.org/jira/browse/IGNITE-1646
> Project: Ignite
>  Issue Type: Bug
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> 1) User must be able to pass IgniteGuid over a wire using serializable 
> semantics when serialized manually by user.
> 2) On the other hand, it must be portable for correct passing between Java 
> and .Net.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1526) IBM JDK is not fully supported by the platfrom

2015-10-09 Thread Denis Magda (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950245#comment-14950245
 ] 

Denis Magda commented on IGNITE-1526:
-

Merged to the master branch.

> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some 
> functionality still doesn't work. As an example 
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi] 
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
>   at 
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
>   at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
>   at 
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing 
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed 
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object 
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at 
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException: 
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID = 
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617)
> at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:162
> 2)
> at 
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
> at 
>

[jira] [Closed] (IGNITE-1526) IBM JDK is not fully supported by the platfrom

2015-10-09 Thread Denis Magda (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda closed IGNITE-1526.
---

> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some 
> functionality still doesn't work. As an example 
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi] 
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
>   at 
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
>   at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
>   at 
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing 
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed 
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object 
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at 
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException: 
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID = 
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617)
> at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:162
> 2)
> at 
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
> at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 771)
> at

[jira] [Created] (IGNITE-1648) ignitevisorcmd: key "-t" for command "log" works incorrect

2015-10-09 Thread Vasilisa Sidorova (JIRA) 
Vasilisa  Sidorova created IGNITE-1648:
--

 Summary: ignitevisorcmd: key "-t" for command "log" works incorrect
 Key: IGNITE-1648
 URL: https://issues.apache.org/jira/browse/IGNITE-1648
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
 Environment: Ubuntu 14.04, Apache-Ignite-1.5.0 build #29
Reporter: Vasilisa  Sidorova
Priority: Minor
 Fix For: 1.5


-
DESCRIPTION
-
The key '-t' works incorrect when it's time to print querying events into log - 
it's print topology snapshot as many times as events are in query. Log became 
difficult to read  
-
STEPS FOR REPRODUCE
-
# Run two nodes in the grid
# Run  ignitevisorcmd.sh
# Connect visor to the grid (open)
# Run logging by command, for example:
{noformat}
log -l -p=30 -t=120 -f=../work/visor/test_log
{noformat}
# Generate several grid-wide events by, for example, start-stop one more node
-
ACTUAL RESULT
-
There is events query in the log every 30 seconds and topology snapshot  every 
2 minutes and every 30 seconds before events query logging -  as many times as 
events are in query. Look at the part of log:
{noformat}
10/09/15, 16:08:27 | Log started.
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:37 |  => NODE_JOINED: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:38 |  => NODE_LEFT: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:42 |  => NODE_JOINED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:44 |  => NODE_FAILED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:46 |  => NODE_JOINED: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:50 |  => NODE_LEFT: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:54 |  => NODE_JOINED: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:59 |  => NODE_LEFT: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:05 |  => NODE_JOINED: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:09 |  => NODE_LEFT: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_JOINED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_FAILED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:17 |  => NODE_JOINED: id8=e15a193f, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:10:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:12:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:14:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:15:27 | Log stopped.
{noformat}
-
EXPECTED RESULT
-
There is events query in the log every 30 seconds and topology snapshot  every 
2 minutes. Something like this:
{noformat}
10/09/15, 16:08:27 | Log started.
10/09/15, 16:08:37 |  => NODE_JOINED: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:38 |  => NODE_LEFT: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:42 |  => NODE_JOINED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:44 |  => NODE_FAILED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:46 |  => NODE_JOINED: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:50 |  => NODE_LEFT: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:54 |  => NODE_JOINED: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:59 |  => NODE_LEFT: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:05 |  => NODE_JOINED: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:09 |  => NODE_LEFT: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_JOINED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_FAILED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:17 |  => NODE_JOINED: id8=e15a193f, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:10:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:12:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:14:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:15:27

[jira] [Closed] (IGNITE-1571) .Net: Improve Guid and DateTime reader/writer interface.

2015-10-09 Thread Vladimir Ozerov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IGNITE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-1571.
---

> .Net: Improve Guid and DateTime reader/writer interface.
> 
>
> Key: IGNITE-1571
> URL: https://issues.apache.org/jira/browse/IGNITE-1571
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> Currently we force user to write Guid and DateTime as nullables. We do this 
> to be more compatible with Java.
> But user is more likely to operate on plain types: Guid, Guid[], DateTime, 
> DateTime[]. 
> We need to add these methods to API, and rename existing ones to 
> "ReadNullableDateTime", etc..
> Note that while trivial to on writer side, it will be harder to implement for 
> readers. Currently we lookup by type ID, which will be equal for the type and 
> it's nullable counterpart. For this reason we probably must lookup by type ID 
> + type or simply by type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1647) CPP: Implement SqlFieldQuery

2015-10-09 Thread Igor Sapego (JIRA) 
Igor Sapego created IGNITE-1647:
---

 Summary: CPP: Implement SqlFieldQuery
 Key: IGNITE-1647
 URL: https://issues.apache.org/jira/browse/IGNITE-1647
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.1.4
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.5


Need to decide on interface of the SqlFieldQuery class in C++ and implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used

2015-10-09 Thread Denis Magda (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950423#comment-14950423
 ] 

Denis Magda commented on IGNITE-1272:
-

TC looks good.

However, activated the following test suites for {{PortableMarshaller}}. Need 
to fix them. Doesn't make sense to open separate JIRA issue. The tests fail on 
master's source code version as well:
- GridCacheDeploymentSelfTest;
- GridCacheDeploymentOffHeapSelfTest;
- Compute Test Suite (7 failling tests);

> PortableMarshaller: issues when different class loaders are used
> 
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails 
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}} 
> by type id. Returned descriptor has a constructor which already has been 
> loaded with another class loader. Fix is not trivial and issue is reproduced 
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1645) .Net: Throw exception on null flag in PortableReader when reading non-nullable value types

2015-10-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950539#comment-14950539
 ] 

ASF GitHub Bot commented on IGNITE-1645:


GitHub user ptupitsyn opened a pull request:

https://github.com/apache/ignite/pull/146

IGNITE-1645 .Net: Throw exception on null flag in PortableReader when 
reading non-nullable value types



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ptupitsyn/ignite ignite-1645

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/146.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 #146


commit 60d70e4207733dba5c89f619d5b0f6408c1752ce
Author: ptupitsyn 
Date:   2015-10-09T11:46:10Z

Throw in reader

commit 00a16a2c34958cb38ea39d20e1a2f586e723ac06
Author: ptupitsyn 
Date:   2015-10-09T11:47:18Z

wip

commit 293ec0820c97c4cc176fc214938e8f2dec99d80c
Author: ptupitsyn 
Date:   2015-10-09T11:48:50Z

Merge remote-tracking branch 'remotes/upstream/ignite-1282' into ignite-1645

commit 79228771e5823daa81706c5bbf4351ae5ff3
Author: ptupitsyn 
Date:   2015-10-09T12:35:09Z

wip

commit ac9060827eb0774d7c0370554a578d98f5fb6c78
Author: ptupitsyn 
Date:   2015-10-09T12:35:33Z

wip

commit 06c6e5ca0f2de80e03d093165a9ea3eb2b1b0a06
Author: ptupitsyn 
Date:   2015-10-09T12:57:27Z

wip

commit aa6e43a7617956c5a81eeb3afd414ca3448e1b56
Author: ptupitsyn 
Date:   2015-10-09T14:13:53Z

wip

commit 3edb9b9f7d06182feebbb22079f2eea2ed0675fa
Author: ptupitsyn 
Date:   2015-10-09T14:32:32Z

iface done

commit 0ceea4f53a5f4fc31e201c011e52cec8e22339d8
Author: ptupitsyn 
Date:   2015-10-09T14:57:49Z

wip

commit 20c7b66538bd81852a26018cabb7188f806e2ec4
Author: ptupitsyn 
Date:   2015-10-09T14:57:54Z

wip

commit 6167bec2a1a60f65731d07fe2f17fcf06272b25c
Author: ptupitsyn 
Date:   2015-10-09T14:59:42Z

wip

commit 8ae9b9701e308afc4ccb09839c691b2e305bc5e4
Author: ptupitsyn 
Date:   2015-10-09T14:59:47Z

wip

commit 777456ede1a9031dc9feb6a524bf6b3e1431d739
Author: ptupitsyn 
Date:   2015-10-09T15:01:33Z

fixing tetst

commit 4b830771e8683469a342dbc232fd941020c0c660
Author: ptupitsyn 
Date:   2015-10-09T15:12:55Z

wip




> .Net: Throw exception on null flag in PortableReader when reading 
> non-nullable value types
> --
>
> Key: IGNITE-1645
> URL: https://issues.apache.org/jira/browse/IGNITE-1645
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Pavel  Tupitsyn
>Assignee: Pavel  Tupitsyn
> Fix For: 1.5
>
>
> Currently we always return default(T) when deserializing null value. So for 
> value types there is no way  for the user to discern a missing cache key from 
> a cache key with default value.
> * throw exceptions when there is Null in stream and we are trying to read a 
> value type
> * update Cache API with Try* methods



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)