[jira] [Assigned] (IGNITE-1287) Platforms .Net: Move memory management code to Ignite.
[ https://issues.apache.org/jira/browse/IGNITE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1287: -- Assignee: Pavel Tupitsyn Platforms .Net: Move memory management code to Ignite. -- Key: IGNITE-1287 URL: https://issues.apache.org/jira/browse/IGNITE-1287 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Pavel Tupitsyn Priority: Critical Fix For: ignite-1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-1286) Platforms .Net: Create solution and empty projects core, test, test-runner
[ https://issues.apache.org/jira/browse/IGNITE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1286: --- Comment: was deleted (was: Done, pull request updated.) Platforms .Net: Create solution and empty projects core, test, test-runner Key: IGNITE-1286 URL: https://issues.apache.org/jira/browse/IGNITE-1286 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Pavel Tupitsyn Priority: Critical Fix For: ignite-1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1286) Platforms .Net: Create solution and empty projects core, test, test-runner
[ https://issues.apache.org/jira/browse/IGNITE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709244#comment-14709244 ] Pavel Tupitsyn commented on IGNITE-1286: https://github.com/apache/ignite/pull/28 Platforms .Net: Create solution and empty projects core, test, test-runner Key: IGNITE-1286 URL: https://issues.apache.org/jira/browse/IGNITE-1286 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Priority: Critical Fix For: ignite-1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1287) Platforms .Net: Move memory management code to Ignite.
[ https://issues.apache.org/jira/browse/IGNITE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709570#comment-14709570 ] Pavel Tupitsyn commented on IGNITE-1287: Tests in Ignite and GridGain work. https://github.com/apache/ignite/pull/31 See corresponding GG branch as well. Platforms .Net: Move memory management code to Ignite. -- Key: IGNITE-1287 URL: https://issues.apache.org/jira/browse/IGNITE-1287 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Pavel Tupitsyn Priority: Critical Fix For: ignite-1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1286) Platforms .Net: Create solution and empty projects core, test, test-runner
[ https://issues.apache.org/jira/browse/IGNITE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1286: -- Assignee: Pavel Tupitsyn Platforms .Net: Create solution and empty projects core, test, test-runner Key: IGNITE-1286 URL: https://issues.apache.org/jira/browse/IGNITE-1286 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Pavel Tupitsyn Priority: Critical Fix For: ignite-1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1759) .Net: Guid read/write is not platform-safe.
[ https://issues.apache.org/jira/browse/IGNITE-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1759: --- Assignee: Pavel Tupitsyn > .Net: Guid read/write is not platform-safe. > --- > > Key: IGNITE-1759 > URL: https://issues.apache.org/jira/browse/IGNITE-1759 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > Two problems here: > 1) We do not count for endiannes, so byte shifts might be invalid. > 2) Guid doesn't have fixed layout. For this reason there are no guarantees > that it will take 16 bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1759) .Net: Guid read/write is not platform-safe.
[ https://issues.apache.org/jira/browse/IGNITE-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14966838#comment-14966838 ] Pavel Tupitsyn edited comment on IGNITE-1759 at 10/21/15 1:59 PM: --- 2) We can check at startup whether Guid has expected layout and then choose either a current faster approach, or a slower way through a Guid constructor. was (Author: ptupitsyn): 1) Endianness does not matter here. Basically, we interpret a 16-byte memory chunk as 2 ulongs and then reorder some bytes in them. 2) We can check at startup whether Guid has expected layout and then choose either a current faster approach, or a slower way through a Guid constructor. > .Net: Guid read/write is not platform-safe. > --- > > Key: IGNITE-1759 > URL: https://issues.apache.org/jira/browse/IGNITE-1759 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > Two problems here: > 1) We do not count for endiannes, so byte shifts might be invalid. > 2) Guid doesn't have fixed layout. For this reason there are no guarantees > that it will take 16 bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1759) .Net: Guid read/write is not platform-safe.
[ https://issues.apache.org/jira/browse/IGNITE-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14966838#comment-14966838 ] Pavel Tupitsyn commented on IGNITE-1759: - 1) Endianness does not matter here. Basically, we interpret a 16-byte memory chunk as 2 ulongs and then reorder some bytes in them. 2) We can check at startup whether Guid has expected layout and then choose either a current faster approach, or a slower way through a Guid constructor. > .Net: Guid read/write is not platform-safe. > --- > > Key: IGNITE-1759 > URL: https://issues.apache.org/jira/browse/IGNITE-1759 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > Two problems here: > 1) We do not count for endiannes, so byte shifts might be invalid. > 2) Guid doesn't have fixed layout. For this reason there are no guarantees > that it will take 16 bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1785) .Net: Improve PlatformMemory/PortableStream performance and memory usage
Pavel Tupitsyn created IGNITE-1785: --- Summary: .Net: Improve PlatformMemory/PortableStream performance and memory usage Key: IGNITE-1785 URL: https://issues.apache.org/jira/browse/IGNITE-1785 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 * PlatformMemory is just a single "long _memPtr" and can be easily converted to a struct to reduce allocations (it is allocated a lot) * PlatformMemoryStream works with PlatformMemory.Length and Capacity indirectly. By employing a struct approach from https://issues.apache.org/jira/browse/IGNITE-1428 we can work with Length and Capacity directly, which may be faster, and will eliminate the need for SyncronizeInput/Output calls. * PlatformMemoryStream is allocated even more often than PlatformMemory, need to investigate whether it can also be a struct. See how List<>.GetEnumerator works, which is a struct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1780) .Net: DateTime is seialized incorrectly.
[
https://issues.apache.org/jira/browse/IGNITE-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-1780:
---
Assignee: Pavel Tupitsyn
> .Net: DateTime is seialized incorrectly.
>
>
> Key: IGNITE-1780
> URL: https://issues.apache.org/jira/browse/IGNITE-1780
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> Add the following test to PortableSelfTest.cs:
> {code}
> [Test]
> public void TestWriteDate()
> {
> DateTime time = DateTime.Now;
> DateTime timeUtc = DateTime.UtcNow;
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
> timeUtc);
> }
> {code}
> Observe that it fails becuase we loose DateTimeKind.
> DateTime must be serialized in portable form only in two cases:
> 1) IPortableWriter.WriteDate()
> 2) IPortableWriter.WriteDateArray()
> In all other cases it should be serialized in some other form. E.g., we can
> introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
> Arrays (IGNITE-1779) in it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1780) .Net: DateTime is seialized incorrectly.
[
https://issues.apache.org/jira/browse/IGNITE-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn closed IGNITE-1780.
---
Assignee: Vladimir Ozerov (was: Pavel Tupitsyn)
> .Net: DateTime is seialized incorrectly.
>
>
> Key: IGNITE-1780
> URL: https://issues.apache.org/jira/browse/IGNITE-1780
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> Add the following test to PortableSelfTest.cs:
> {code}
> [Test]
> public void TestWriteDate()
> {
> DateTime time = DateTime.Now;
> DateTime timeUtc = DateTime.UtcNow;
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
> timeUtc);
> }
> {code}
> Observe that it fails becuase we loose DateTimeKind.
> DateTime must be serialized in portable form only in two cases:
> 1) IPortableWriter.WriteDate()
> 2) IPortableWriter.WriteDateArray()
> In all other cases it should be serialized in some other form. E.g., we can
> introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
> Arrays (IGNITE-1779) in it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1779) .Net: Evaluate BinaryFormatter overhead for generic collections.
[ https://issues.apache.org/jira/browse/IGNITE-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1779: --- Assignee: Pavel Tupitsyn > .Net: Evaluate BinaryFormatter overhead for generic collections. > > > Key: IGNITE-1779 > URL: https://issues.apache.org/jira/browse/IGNITE-1779 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > It seems that BinaryFormatter is extrmly inefficient. I tried to write a > single Guid with and it resulted in >100 bytes comparing to 16 bytes when > written in portable form. > If we notice the same overhead for collections/arrays which are fairly often > used types, we will have to revert to our initial approach when collections > were serialized using our own mechanics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1644) .Net: DateTime.Kind is lost during serialization
[
https://issues.apache.org/jira/browse/IGNITE-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1644:
Description:
Add the following test to PortableSelfTest.cs:
{code}
[Test]
public void TestWriteDate()
{
DateTime time = DateTime.Now;
DateTime timeUtc = DateTime.UtcNow;
Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
timeUtc);
}
{code}
Observe that it fails becuase we loose DateTimeKind.
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.
DateTime must be serialized in portable form only in two cases:
1) IPortableWriter.WriteDate()
2) IPortableWriter.WriteDateArray()
In these cases we should throw exception on a non-UTC date.
In all other cases it should be serialized in some other form. E.g., we can
introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
Arrays (IGNITE-1779) in it.
This will break queries to some extent.
was:
Add the following test to PortableSelfTest.cs:
{code}
[Test]
public void TestWriteDate()
{
DateTime time = DateTime.Now;
DateTime timeUtc = DateTime.UtcNow;
Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
timeUtc);
}
{code}
Observe that it fails becuase we loose DateTimeKind.
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)
* throw exceptions for non-utc DateTime (force user to use UTC-only during
serialization)
> .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
>
>
> Add the following test to PortableSelfTest.cs:
> {code}
> [Test]
> public void TestWriteDate()
> {
> DateTime time = DateTime.Now;
> DateTime timeUtc = DateTime.UtcNow;
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
> timeUtc);
> }
> {code}
> Observe that it fails becuase we loose DateTimeKind.
> 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.
> DateTime must be serialized in portable form only in two cases:
> 1) IPortableWriter.WriteDate()
> 2) IPortableWriter.WriteDateArray()
> In these cases we should throw exception on a non-UTC date.
> In all other cases it should be serialized in some other form. E.g., we can
> introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
> Arrays (IGNITE-1779) in it.
> This will break queries to some extent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1760) .Net: Validate field type in PortableReaderImpl
[ https://issues.apache.org/jira/browse/IGNITE-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1760: Priority: Critical (was: Major) > .Net: Validate field type in PortableReaderImpl > --- > > Key: IGNITE-1760 > URL: https://issues.apache.org/jira/browse/IGNITE-1760 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > Currently in methods like ReadInt we just ignore type id byte and proceed to > read data, which can result in garbage in case of type mismatch. > Need to validate whether data is of expected type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1644) .Net: DateTime.Kind is lost during serialization
[
https://issues.apache.org/jira/browse/IGNITE-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970874#comment-14970874
]
Pavel Tupitsyn commented on IGNITE-1644:
-
There is a problem with arrays. ReflectiveSerializer writes ALL arrays as
arrays. But PortableWriterImpl only writes arrays of known types as arrays. All
other arrays are written as Serializable.
> .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
>
>
> Add the following test to PortableSelfTest.cs:
> {code}
> [Test]
> public void TestWriteDate()
> {
> DateTime time = DateTime.Now;
> DateTime timeUtc = DateTime.UtcNow;
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
> timeUtc);
> }
> {code}
> Observe that it fails becuase we loose DateTimeKind.
> 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.
> DateTime must be serialized in portable form only in two cases:
> 1) IPortableWriter.WriteDate()
> 2) IPortableWriter.WriteDateArray()
> In these cases we should throw exception on a non-UTC date.
> In all other cases it should be serialized in some other form. E.g., we can
> introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
> Arrays (IGNITE-1779) in it.
> This will break queries to some extent.
--
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
[ https://issues.apache.org/jira/browse/IGNITE-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14968953#comment-14968953 ] Pavel Tupitsyn commented on IGNITE-1619: - 1,3) Fixed 2) HashSet does not implement ICollection, so we can't use it in these methods. There is no non-generic set in .Net. > 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-1779) .Net: Evaluate BinaryFormatter overhead for generic collections.
[
https://issues.apache.org/jira/browse/IGNITE-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976285#comment-14976285
]
Pavel Tupitsyn edited comment on IGNITE-1779 at 10/27/15 12:44 PM:
{code:title=PortableSelfTest.cs}
[Test]
public void TestArraySerializable()
{
var serArr = Enumerable.Range(1, 1).Select(x => new
SerializableObject {Foo = x}).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
_marsh.Marshal(serArr).Length / serArr.Length); // 18
Console.WriteLine("As object array: " +
_marsh.Marshal(objArr).Length / serArr.Length); // 232
}
[Test]
public void TestArrayWithRawPortables()
{
var marsh =
new PortableMarshaller(new PortableConfiguration
{
TypeConfigurations =
new List { new
PortableTypeConfiguration(typeof(PrimitiveFieldRawPortableType)) }
});
PrimitiveFieldRawPortableType[] serArr = Enumerable.Range(1,
1000).Select(x => new PrimitiveFieldRawPortableType { PDouble = x }).ToArray();
object[] objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
marsh.Marshal(serArr).Length / serArr.Length);
Console.WriteLine("As object array: " +
marsh.Marshal(objArr).Length / objArr.Length);
}
{code}
was (Author: ptupitsyn):
{code:title=PortableSelfTest.cs}
[Test]
public void TestArraySerializable()
{
var serArr = Enumerable.Range(1, 1).Select(x => new
SerializableObject {Foo = x}).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
_marsh.Marshal(serArr).Length / serArr.Length); // 18
Console.WriteLine("As object array: " +
_marsh.Marshal(objArr).Length / serArr.Length); // 232
}
[Test]
public void TestArrayWithRawPortables()
{
var marsh =
new PortableMarshaller(new PortableConfiguration
{
TypeConfigurations =
new List { new
PortableTypeConfiguration(typeof(PrimitiveFieldRawPortableType)) }
});
var serArr = Enumerable.Range(1, 1000).Select(x => new
PrimitiveFieldRawPortableType { PDouble = x }).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
marsh.Marshal(serArr).Length / serArr.Length); // 128
Console.WriteLine("As object array: " +
marsh.Marshal(objArr).Length / objArr.Length); // 383
}
{code}
> .Net: Evaluate BinaryFormatter overhead for generic collections.
>
>
> Key: IGNITE-1779
> URL: https://issues.apache.org/jira/browse/IGNITE-1779
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> It seems that BinaryFormatter is extrmly inefficient. I tried to write a
> single Guid with and it resulted in >100 bytes comparing to 16 bytes when
> written in portable form.
> If we notice the same overhead for collections/arrays which are fairly often
> used types, we will have to revert to our initial approach when collections
> were serialized using our own mechanics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1779) .Net: Evaluate BinaryFormatter overhead for generic collections.
[
https://issues.apache.org/jira/browse/IGNITE-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976285#comment-14976285
]
Pavel Tupitsyn edited comment on IGNITE-1779 at 10/27/15 12:40 PM:
{code:title=PortableSelfTest.cs}
[Test]
public void TestArraySerializable()
{
var serArr = Enumerable.Range(1, 1).Select(x => new
SerializableObject {Foo = x}).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
_marsh.Marshal(serArr).Length / serArr.Length); // 18
Console.WriteLine("As object array: " +
_marsh.Marshal(objArr).Length / serArr.Length); // 232
}
[Test]
public void TestArrayWithRawPortables()
{
var marsh =
new PortableMarshaller(new PortableConfiguration
{
TypeConfigurations =
new List { new
PortableTypeConfiguration(typeof(PrimitiveFieldRawPortableType)) }
});
var serArr = Enumerable.Range(1, 1000).Select(x => new
PrimitiveFieldRawPortableType { PDouble = x }).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
marsh.Marshal(serArr).Length / serArr.Length); // 128
Console.WriteLine("As object array: " +
marsh.Marshal(objArr).Length / objArr.Length); // 383
}
{code}
was (Author: ptupitsyn):
{code:title=PortableSelfTest.cs}
[Test]
public void TestArraySerializable()
{
var serArr = Enumerable.Range(1, 1).Select(x => new
SerializableObject {Foo = x}).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
_marsh.Marshal(serArr).Length / serArr.Length);
Console.WriteLine("As object array: " +
_marsh.Marshal(objArr).Length / serArr.Length);
}
{code}
As serializable: 18
As object array: 232
> .Net: Evaluate BinaryFormatter overhead for generic collections.
>
>
> Key: IGNITE-1779
> URL: https://issues.apache.org/jira/browse/IGNITE-1779
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> It seems that BinaryFormatter is extrmly inefficient. I tried to write a
> single Guid with and it resulted in >100 bytes comparing to 16 bytes when
> written in portable form.
> If we notice the same overhead for collections/arrays which are fairly often
> used types, we will have to revert to our initial approach when collections
> were serialized using our own mechanics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1779) .Net: Evaluate BinaryFormatter overhead for generic collections.
[
https://issues.apache.org/jira/browse/IGNITE-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976285#comment-14976285
]
Pavel Tupitsyn commented on IGNITE-1779:
-
{code:title=PortableSelfTest.cs}
[Test]
public void TestArraySerializable()
{
var serArr = Enumerable.Range(1, 1).Select(x => new
SerializableObject {Foo = x}).ToArray();
var objArr = serArr.OfType().ToArray();
Console.WriteLine("As serializable: " +
_marsh.Marshal(serArr).Length / serArr.Length);
Console.WriteLine("As object array: " +
_marsh.Marshal(objArr).Length / serArr.Length);
}
{code}
As serializable: 18
As object array: 232
> .Net: Evaluate BinaryFormatter overhead for generic collections.
>
>
> Key: IGNITE-1779
> URL: https://issues.apache.org/jira/browse/IGNITE-1779
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> It seems that BinaryFormatter is extrmly inefficient. I tried to write a
> single Guid with and it resulted in >100 bytes comparing to 16 bytes when
> written in portable form.
> If we notice the same overhead for collections/arrays which are fairly often
> used types, we will have to revert to our initial approach when collections
> were serialized using our own mechanics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1770) Portables: implement constant-time field lookup.
[ https://issues.apache.org/jira/browse/IGNITE-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1770: --- Assignee: Pavel Tupitsyn (was: Vladimir Ozerov) > Portables: implement constant-time field lookup. > > > Key: IGNITE-1770 > URL: https://issues.apache.org/jira/browse/IGNITE-1770 > Project: Ignite > Issue Type: Task > Components: general, interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.5 > > > See > https://cwiki.apache.org/confluence/display/IGNITE/Portable+object+constant-time+field+lookup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1770) Portables: implement constant-time field lookup.
[ https://issues.apache.org/jira/browse/IGNITE-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1770: --- Assignee: Pavel Tupitsyn (was: Vladimir Ozerov) > Portables: implement constant-time field lookup. > > > Key: IGNITE-1770 > URL: https://issues.apache.org/jira/browse/IGNITE-1770 > Project: Ignite > Issue Type: Task > Components: general, interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.5 > > > See > https://cwiki.apache.org/confluence/display/IGNITE/Portable+object+constant-time+field+lookup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1644) .Net: DateTime.Kind is lost during serialization
[
https://issues.apache.org/jira/browse/IGNITE-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14974158#comment-14974158
]
Pavel Tupitsyn commented on IGNITE-1644:
-
To fix mismatch between Reader/Writer and PortableBuilder APIs I've added
Set_x_Field methods to the builder.
> .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
>
>
> Add the following test to PortableSelfTest.cs:
> {code}
> [Test]
> public void TestWriteDate()
> {
> DateTime time = DateTime.Now;
> DateTime timeUtc = DateTime.UtcNow;
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
> timeUtc);
> }
> {code}
> Observe that it fails becuase we loose DateTimeKind.
> 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.
> DateTime must be serialized in portable form only in two cases:
> 1) IPortableWriter.WriteDate()
> 2) IPortableWriter.WriteDateArray()
> In these cases we should throw exception on a non-UTC date.
> In all other cases it should be serialized in some other form. E.g., we can
> introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
> Arrays (IGNITE-1779) in it.
> This will break queries to some extent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1652) .Net: Rework async APIs (remove WithAsync/GetFuture)
[
https://issues.apache.org/jira/browse/IGNITE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1652:
Description:
{code}
cache.WithAsync().Get();
IFuture future = cache.GetFuture();
{code}
should become
{code}
Task task = cache.GetAsync();
{code}
Guidelines: https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
First step is .Net-only (remove GetFuture from public API, call it inside
*Async methods). This requires 2 JNI calls.
Later we should look into making it a single JNI call.
was:
{code}
cache.WithAsync().Get();
var future = cache.GetFuture();
{code}
should become
{code}
var future = cache.GetAsync();
{code}
See if we can make ToTask() more efficient, or even get rid of Futures
completely in favor of tasks, preserving performance.
First step is .Net-only (remove GetFuture from public API, call it inside
*Async methods). This requires 2 JNI calls.
Later we should look into making it a single JNI call.
> .Net: Rework async APIs (remove WithAsync/GetFuture)
>
>
> Key: IGNITE-1652
> URL: https://issues.apache.org/jira/browse/IGNITE-1652
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> {code}
> cache.WithAsync().Get();
> IFuture future = cache.GetFuture();
> {code}
> should become
> {code}
> Task task = cache.GetAsync();
> {code}
> Guidelines: https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
> First step is .Net-only (remove GetFuture from public API, call it inside
> *Async methods). This requires 2 JNI calls.
> Later we should look into making it a single JNI call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1652) .Net: Rework async APIs (remove WithAsync/GetFuture)
[
https://issues.apache.org/jira/browse/IGNITE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14974216#comment-14974216
]
Pavel Tupitsyn commented on IGNITE-1652:
-
Let's hide IFuture and return Tasks directly to have a .Net-friendly API.
Later we can improve Task creation performance:
https://issues.apache.org/jira/browse/IGNITE-1791
> .Net: Rework async APIs (remove WithAsync/GetFuture)
>
>
> Key: IGNITE-1652
> URL: https://issues.apache.org/jira/browse/IGNITE-1652
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> {code}
> cache.WithAsync().Get();
> var future = cache.GetFuture();
> {code}
> should become
> {code}
> var future = cache.GetAsync();
> {code}
> See if we can make ToTask() more efficient, or even get rid of Futures
> completely in favor of tasks, preserving performance.
> First step is .Net-only (remove GetFuture from public API, call it inside
> *Async methods). This requires 2 JNI calls.
> Later we should look into making it a single JNI call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1619) Platform .Net: Generic type is lost during array/collection serialization
[ https://issues.apache.org/jira/browse/IGNITE-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14966607#comment-14966607 ] Pavel Tupitsyn edited comment on IGNITE-1619 at 10/21/15 2:32 PM: --- Since most CLR collections are Serializable, we can rely on that instead of inventing our own mechanism. The downside is that elements of List will be written as Serializable instead of Portable, but user can work around that by serializing the collection manually. 1,2) Comments fixed 3,5,6) Removed, no more applicable 4) Reverted was (Author: ptupitsyn): Since most CLR collections are Serializable, we can rely on that instead of inventing our own mechanism. The downside is that elements of List will be written as Serializable instead of Portable, but user can work around that by serializing the collection manually. 1,2) Comments fixed 3,6) Descriptor logic removed since it is not actually reachable 4) .. > 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] [Updated] (IGNITE-1884) .Net: JNI local ref can't be accessed from another thread
[
https://issues.apache.org/jira/browse/IGNITE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1884:
Description:
Documentation:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
{code}
Local references are only valid in the thread in which they are created. The
native code must not pass local references from one thread to another.
{code}
We have two places where we DO pass local JNI reference to another thread:
* CacheParallelLoadStoreAdapter
* CacheTestStore.LoadCache
And, potentially (due to user code):
* UnmanagedCallbacks.DataStreamerStreamReceiverInvoke
For some reason it has worked for us before.
But renamings in IGNITE-1881 have caused test execution order to change, and
these store tests cause process crash.
To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be
executed before store tests. All other tests can be excluded. 100% repro rate:
"FATAL ERROR in native method: Bad global or local ref passed to JNI".
was:
Documentation:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
{code}
Local references are only valid in the thread in which they are created. The
native code must not pass local references from one thread to another.
{code}
We have two places where we DO pass local JNI reference to another thread:
* CacheParallelLoadStoreAdapter
* CacheTestStore.LoadCache
For some reason it has worked for us before.
But renamings in IGNITE-1881 have caused test execution order to change, and
these store tests cause process crash.
To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be
executed before store tests. All other tests can be excluded. 100% repro rate:
"FATAL ERROR in native method: Bad global or local ref passed to JNI".
> .Net: JNI local ref can't be accessed from another thread
> -
>
> Key: IGNITE-1884
> URL: https://issues.apache.org/jira/browse/IGNITE-1884
> Project: Ignite
> Issue Type: Bug
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.5
>
>
> Documentation:
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
> {code}
> Local references are only valid in the thread in which they are created. The
> native code must not pass local references from one thread to another.
> {code}
> We have two places where we DO pass local JNI reference to another thread:
> * CacheParallelLoadStoreAdapter
> * CacheTestStore.LoadCache
> And, potentially (due to user code):
> * UnmanagedCallbacks.DataStreamerStreamReceiverInvoke
> For some reason it has worked for us before.
> But renamings in IGNITE-1881 have caused test execution order to change, and
> these store tests cause process crash.
> To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be
> executed before store tests. All other tests can be excluded. 100% repro
> rate: "FATAL ERROR in native method: Bad global or local ref passed to JNI".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1884) .Net: JNI local ref can't be accessed from another thread
Pavel Tupitsyn created IGNITE-1884:
---
Summary: .Net: JNI local ref can't be accessed from another thread
Key: IGNITE-1884
URL: https://issues.apache.org/jira/browse/IGNITE-1884
Project: Ignite
Issue Type: Bug
Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 1.5
Documentation:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
{code}
Local references are only valid in the thread in which they are created. The
native code must not pass local references from one thread to another.
{code}
We have two places where we DO pass local JNI reference to another thread:
* CacheParallelLoadStoreAdapter
* CacheTestStore.LoadCache
For some reason it has worked for us before.
But renamings in IGNITE-1881 have caused test execution order to change, and
these store tests cause process crash.
To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be
executed before store tests. All other tests can be excluded. 100% repro rate:
"FATAL ERROR in native method: Bad global or local ref passed to JNI".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1884) .Net: JNI local ref can't be accessed from another thread
[
https://issues.apache.org/jira/browse/IGNITE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1884:
Priority: Blocker (was: Major)
> .Net: JNI local ref can't be accessed from another thread
> -
>
> Key: IGNITE-1884
> URL: https://issues.apache.org/jira/browse/IGNITE-1884
> Project: Ignite
> Issue Type: Bug
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.5
>
>
> Documentation:
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
> {code}
> Local references are only valid in the thread in which they are created. The
> native code must not pass local references from one thread to another.
> {code}
> We have two places where we DO pass local JNI reference to another thread:
> * CacheParallelLoadStoreAdapter
> * CacheTestStore.LoadCache
> For some reason it has worked for us before.
> But renamings in IGNITE-1881 have caused test execution order to change, and
> these store tests cause process crash.
> To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be
> executed before store tests. All other tests can be excluded. 100% repro
> rate: "FATAL ERROR in native method: Bad global or local ref passed to JNI".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1884) .Net: JNI local ref can't be accessed from another thread
[
https://issues.apache.org/jira/browse/IGNITE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000129#comment-15000129
]
Pavel Tupitsyn commented on IGNITE-1884:
-
1,2) Both of these cases go down to ThrowToJava. It just sets an exception in
Java, but does not affect C++ program flow. So the handle won't leak.
http://mindprod.com/jgloss/jni.html#EXCEPTIONS
However, in future there may be the case with C++ or some other client where
exceptions are possible. I'll address this with a wrapper/destructor.
3,4) Creating a wrapper and checking thread id would also introduce an
overhead. Before doing this, we need to make sure if that is actually faster
than GlobalRef. Let's do that separately.
> .Net: JNI local ref can't be accessed from another thread
> -
>
> Key: IGNITE-1884
> URL: https://issues.apache.org/jira/browse/IGNITE-1884
> Project: Ignite
> Issue Type: Bug
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.5
>
>
> Documentation:
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
> {code}
> Local references are only valid in the thread in which they are created. The
> native code must not pass local references from one thread to another.
> {code}
> We have two places where we DO pass local JNI reference to another thread:
> * CacheParallelLoadStoreAdapter
> * CacheTestStore.LoadCache
> And, potentially (due to user code):
> * UnmanagedCallbacks.DataStreamerStreamReceiverInvoke
> For some reason it has worked for us before.
> But renamings in IGNITE-1881 have caused test execution order to change, and
> these store tests cause process crash.
> To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be
> executed before store tests. All other tests can be excluded. 100% repro
> rate: "FATAL ERROR in native method: Bad global or local ref passed to JNI".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1845) .Net: Adopt portable API changes.
[ https://issues.apache.org/jira/browse/IGNITE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000121#comment-15000121 ] Pavel Tupitsyn commented on IGNITE-1845: - Please make sure you check PR#212. It certainly has these changes: https://github.com/apache/ignite/pull/212/files > .Net: Adopt portable API changes. > - > > Key: IGNITE-1845 > URL: https://issues.apache.org/jira/browse/IGNITE-1845 > Project: Ignite > Issue Type: Task > Components: general, interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.5 > > > Important API changes will be introduced as a part of IGNITE-950. > Once these changes are in place, we need to port them to .Net. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1694) .Net: More efficient way to call native methods.
[ https://issues.apache.org/jira/browse/IGNITE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000536#comment-15000536 ] Pavel Tupitsyn commented on IGNITE-1694: - * [DllImport] works fine after LoadLibrary call, no additional changes required. * PutBenchmark ~2% faster. * TC ok. > .Net: More efficient way to call native methods. > > > Key: IGNITE-1694 > URL: https://issues.apache.org/jira/browse/IGNITE-1694 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.6 > > > Currently we invoke native platform using > "Marshal.GetDelegateForFunctionPointer". > This is the least efficient way to call external code. What can be done to > improve it: > 1) Add [SuppressUnmanagedCodeSecurity] attribute. > 2) Use P/Invoke instead. We do not use it now because we unpack native > library in runtime into some temp folder, while PInvoke searches for > libraries in predefined file system places. Need to evaluate whether we can > switch back to P/Invoke somehow. > See > http://ybeernet.blogspot.ru/2011/03/techniques-of-calling-unmanaged-code.html > for more info. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1694) .Net: More efficient way to call native methods.
[ https://issues.apache.org/jira/browse/IGNITE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1694: --- Assignee: Pavel Tupitsyn > .Net: More efficient way to call native methods. > > > Key: IGNITE-1694 > URL: https://issues.apache.org/jira/browse/IGNITE-1694 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.6 > > > Currently we invoke native platform using > "Marshal.GetDelegateForFunctionPointer". > This is the least efficient way to call external code. What can be done to > improve it: > 1) Add [SuppressUnmanagedCodeSecurity] attribute. > 2) Use P/Invoke instead. We do not use it now because we unpack native > library in runtime into some temp folder, while PInvoke searches for > libraries in predefined file system places. Need to evaluate whether we can > switch back to P/Invoke somehow. > See > http://ybeernet.blogspot.ru/2011/03/techniques-of-calling-unmanaged-code.html > for more info. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1866) .Net: turn SerializableObjectHolder & DateTimeHolder into structs
[ https://issues.apache.org/jira/browse/IGNITE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000319#comment-15000319 ] Pavel Tupitsyn commented on IGNITE-1866: - Implementation shows no performance increase in reader benchmarks. And there is a drop in writer benchmarks due to boxing in IBinarySerializer.WriteBinary call. Not efficient, closing. > .Net: turn SerializableObjectHolder & DateTimeHolder into structs > - > > Key: IGNITE-1866 > URL: https://issues.apache.org/jira/browse/IGNITE-1866 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Reduce allocations on read and write -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1866) .Net: turn SerializableObjectHolder & DateTimeHolder into structs
[ https://issues.apache.org/jira/browse/IGNITE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-1866. - Resolution: Won't Fix > .Net: turn SerializableObjectHolder & DateTimeHolder into structs > - > > Key: IGNITE-1866 > URL: https://issues.apache.org/jira/browse/IGNITE-1866 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Reduce allocations on read and write -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1845) .Net: Adopt portable API changes.
[ https://issues.apache.org/jira/browse/IGNITE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998385#comment-14998385 ] Pavel Tupitsyn commented on IGNITE-1845: - 1,2) Fixed. 3) Renamings in tests lead to hard-to-debug issues with portable type ids. Let's address them separately. Please see PR 212: https://github.com/apache/ignite/pull/212 > .Net: Adopt portable API changes. > - > > Key: IGNITE-1845 > URL: https://issues.apache.org/jira/browse/IGNITE-1845 > Project: Ignite > Issue Type: Task > Components: general, interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.5 > > > Important API changes will be introduced as a part of IGNITE-950. > Once these changes are in place, we need to port them to .Net. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1626: --- Assignee: Pavel Tupitsyn > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1894) .Net: Delegate support in the API via extension methods
Pavel Tupitsyn created IGNITE-1894:
---
Summary: .Net: Delegate support in the API via extension methods
Key: IGNITE-1894
URL: https://issues.apache.org/jira/browse/IGNITE-1894
Project: Ignite
Issue Type: Improvement
Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Fix For: 1.6
In many places we require a single-method interface implementation from the
user:
{code:title=ICompute}
TRes Call(IComputeFunc clo);
{code}
All of these can be extended to accept a delegate:
{code:title=ICompute}
TRes Call(Func clo);
{code}
We can't replace interfaces with delegates completely (which is desirable),
because it will take away serialization control from the user. So the interface
approach has to stay as a primary.
Delegate support can be added via extension methods, which wrap provided
delegates into a class that implements corresponding interface.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001985#comment-15001985 ] Pavel Tupitsyn commented on IGNITE-1626: - TODO: * Create nuspec file which includes all required files (dll, default config, jars) * Investigate nuget on linux * x86/x64? > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002024#comment-15002024 ] Pavel Tupitsyn commented on IGNITE-1626: - x86/x64: Standard way is to have two different packages. https://github.com/taliesins/neosis/pull/1 > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001985#comment-15001985 ] Pavel Tupitsyn edited comment on IGNITE-1626 at 11/12/15 12:53 PM: TODO: * Create nuspec file which includes all required files (dll, default config, jars) * Create TC build that packs and publishes new nuget package * x86/x64? was (Author: ptupitsyn): TODO: * Create nuspec file which includes all required files (dll, default config, jars) * Investigate nuget on linux * x86/x64? > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1906) .Net: Ignite configuration without Spring.
Pavel Tupitsyn created IGNITE-1906: --- Summary: .Net: Ignite configuration without Spring. Key: IGNITE-1906 URL: https://issues.apache.org/jira/browse/IGNITE-1906 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 * Spring is alien for .NET developers. * In-code configuration is often preferrable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1908) .Net: Query configuration
Pavel Tupitsyn created IGNITE-1908: --- Summary: .Net: Query configuration Key: IGNITE-1908 URL: https://issues.apache.org/jira/browse/IGNITE-1908 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.5 Configure queries in code. This includes attribute-based configuration (similar to QuerySqlField in Java). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1909) .Net: Discovery configuration
Pavel Tupitsyn created IGNITE-1909: --- Summary: .Net: Discovery configuration Key: IGNITE-1909 URL: https://issues.apache.org/jira/browse/IGNITE-1909 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.5 Configure discovery in code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1907) .Net: Cache configuration
Pavel Tupitsyn created IGNITE-1907: --- Summary: .Net: Cache configuration Key: IGNITE-1907 URL: https://issues.apache.org/jira/browse/IGNITE-1907 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.5 Configure cache in code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1906) .Net: Ignite configuration without Spring
[ https://issues.apache.org/jira/browse/IGNITE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1906: Summary: .Net: Ignite configuration without Spring (was: .Net: Ignite configuration without Spring.) > .Net: Ignite configuration without Spring > - > > Key: IGNITE-1906 > URL: https://issues.apache.org/jira/browse/IGNITE-1906 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > * Spring is alien for .NET developers. > * In-code configuration is often preferrable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1906) .Net: Ignite configuration without Spring
[ https://issues.apache.org/jira/browse/IGNITE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1906: Description: * Spring is alien for .NET developers * In-code configuration is often preferrable was: * Spring is alien for .NET developers. * In-code configuration is often preferrable > .Net: Ignite configuration without Spring > - > > Key: IGNITE-1906 > URL: https://issues.apache.org/jira/browse/IGNITE-1906 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > * Spring is alien for .NET developers > * In-code configuration is often preferrable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003723#comment-15003723
]
Pavel Tupitsyn commented on IGNITE-1896:
-
1) I don't propose to remove current method altogether, I propose to complement
it with more usable methods. If arguments are added, API won't be broken. We
can keep simple methods for simple scenarios, and current approach for higher
customization
2) There is a problem. When you use a dictionary, you have to specify generic
arguments only once, in constructor. Then you never have to do it again:
{code}
var dict = new Dictionary();
dict[1] = new Person(); // No generic arguments
var person = dict[1]; // No generic arguments
{code}
Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache(); // generic arguments specified
once, this is fine
var person = cache.Get(1); // no generic arguments, good
// Why do we force user to specify typeof(Person)? Cache already knows this
type.
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)
// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}
Same issue we had with GetFuture. Too much typing, prone to errors, makes
refactoring hard.
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003723#comment-15003723
]
Pavel Tupitsyn edited comment on IGNITE-1896 at 11/13/15 8:44 AM:
---
1) I don't propose to remove current method altogether, I propose to complement
it with more usable methods. If arguments are added, API won't be broken. We
can keep simple methods for simple scenarios, and current approach for higher
customization
2) There is a problem. When you use a dictionary, you have to specify generic
arguments only once, in constructor. Then you never have to do it again, no
chance to make a mistake:
{code}
var dict = new Dictionary();
dict[1] = new Person(); // No generic arguments
var person = dict[1]; // No generic arguments
{code}
Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache(); // generic arguments specified
once, this is fine
var person = cache.Get(1); // no generic arguments, good
// Why do we force user to specify typeof(Person)? Cache already knows this
type.
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)
// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}
Same issue we had with GetFuture. Too much typing, prone to errors, makes
refactoring hard.
was (Author: ptupitsyn):
1) I don't propose to remove current method altogether, I propose to complement
it with more usable methods. If arguments are added, API won't be broken. We
can keep simple methods for simple scenarios, and current approach for higher
customization
2) There is a problem. When you use a dictionary, you have to specify generic
arguments only once, in constructor. Then you never have to do it again:
{code}
var dict = new Dictionary();
dict[1] = new Person(); // No generic arguments
var person = dict[1]; // No generic arguments
{code}
Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache(); // generic arguments specified
once, this is fine
var person = cache.Get(1); // no generic arguments, good
// Why do we force user to specify typeof(Person)? Cache already knows this
type.
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)
// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}
Same issue we had with GetFuture. Too much typing, prone to errors, makes
refactoring hard.
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-1902:
---
Assignee: Pavel Tupitsyn
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1902:
Description:
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to .NET:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
was:
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to CPP:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to .NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1915) .Net: Ignite as Entity Framework Second-Level Cache
Pavel Tupitsyn created IGNITE-1915: --- Summary: .Net: Ignite as Entity Framework Second-Level Cache Key: IGNITE-1915 URL: https://issues.apache.org/jira/browse/IGNITE-1915 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.6 Entity Framework is #1 ORM for .NET We should provide easy solution to boost Entity Framework performance with Ignite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1626: --- Assignee: Pavel Tupitsyn (was: Vladimir Ozerov) > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1907) .Net: Cache configuration
[ https://issues.apache.org/jira/browse/IGNITE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1907: --- Assignee: Pavel Tupitsyn > .Net: Cache configuration > - > > Key: IGNITE-1907 > URL: https://issues.apache.org/jira/browse/IGNITE-1907 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > Configure cache in code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1924) Incomplete marshaller cache rebalancing causes Grid hangs
[ https://issues.apache.org/jira/browse/IGNITE-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1924: Summary: Incomplete marshaller cache rebalancing causes Grid hangs (was: Uncompleme marshaller cashe rebalancing cause Grid hangs) > Incomplete marshaller cache rebalancing causes Grid hangs > - > > Key: IGNITE-1924 > URL: https://issues.apache.org/jira/browse/IGNITE-1924 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Critical > > End of the log. > [11:49:32] : [org.apache.ignite:ignite-core] [11:49:32,947][INFO > ][exchange-worker-#220584%tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander] > Starting rebalancing > [cache=ignite-marshaller-sys-cache, mode=SYNC, > fromNode=108bffdb-1c1e-49aa-9525-b434784fa001, partitionsCount=7, > topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], updateSeq=1] > [11:49:32] : [org.apache.ignite:ignite-core] [11:49:32,962][INFO > ][exchange-worker-#220584%tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander] > Starting rebalancing > [cache=ignite-marshaller-sys-cache, mode=SYNC, > fromNode=20660c29-91a1-4279-9dc1-88d192bc6002, partitionsCount=6, > topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], updateSeq=1] > [11:49:32] : [org.apache.ignite:ignite-core] [11:49:32,962][INFO > ][exchange-worker-#220584%tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander] > Starting rebalancing > [cache=ignite-marshaller-sys-cache, mode=SYNC, > fromNode=00b3a75a-074d-46a5-a158-3956c0ec4000, partitionsCount=7, > topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], updateSeq=1] > [11:49:32] : [org.apache.ignite:ignite-core] [11:49:32,963][INFO > ][ignite-#220587%marshaller-cache-tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander] > Completed rebalancing > [cache=ignite-marshaller-sys-cache, > fromNode=00b3a75a-074d-46a5-a158-3956c0ec4000, > topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], time=21 ms] > [11:49:32] : [org.apache.ignite:ignite-core] [11:49:32,963][INFO > ][ignite-#220586%marshaller-cache-tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander] > Completed rebalancing > [cache=ignite-marshaller-sys-cache, > fromNode=108bffdb-1c1e-49aa-9525-b434784fa001, > topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], time=21 ms] > Hang on: > [11:51:56] : [org.apache.ignite:ignite-core] Thread > [name="ignite-#220562%sys-tcp.IgniteCacheSslStartStopSelfTest3%", id=287517, > state=WAITING, blockCnt=0, waitCnt=3] > [11:51:56] : [org.apache.ignite:ignite-core] Lock > [object=o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture@b402f89, > ownerName=null, ownerId=-1] > [11:51:56] : [org.apache.ignite:ignite-core] at > sun.misc.Unsafe.park(Native Method) > [11:51:56] : [org.apache.ignite:ignite-core] at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > [11:51:56] : [org.apache.ignite:ignite-core] at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > [11:51:56] : [org.apache.ignite:ignite-core] at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) > [11:51:56] : [org.apache.ignite:ignite-core] at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) > [11:51:56] : [org.apache.ignite:ignite-core] at > o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157) > [11:51:56] : [org.apache.ignite:ignite-core] at > o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115) > [11:51:56] : [org.apache.ignite:ignite-core] at > o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.waitForCacheRebalancing(GridDhtPartitionDemander.java:265) > [11:51:56] : [org.apache.ignite:ignite-core] at > o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.access$400(GridDhtPartitionDemander.java:85) > [11:51:56] : [org.apache.ignite:ignite-core] at > o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$3.call(GridDhtPartitionDemander.java:323) > [11:51:56] : [org.apache.ignite:ignite-core] at > o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$3.call(GridDhtPartitionDemander.java:320) > [11:51:56] :
[jira] [Created] (IGNITE-1921) .Net: Handle leak during ComputeJobHolder serialization
Pavel Tupitsyn created IGNITE-1921: --- Summary: .Net: Handle leak during ComputeJobHolder serialization Key: IGNITE-1921 URL: https://issues.apache.org/jira/browse/IGNITE-1921 Project: Ignite Issue Type: Bug Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Priority: Blocker Fix For: 1.5 See where ComputeJobHolder is constructed and serialized. In case of non-serializable user job there is a handle leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1626: --- Assignee: Vladimir Ozerov (was: Pavel Tupitsyn) > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Blocker > Fix For: 1.5 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1626: Comment: was deleted (was: TODO: * Create nuspec file which includes all required files (dll, default config, jars) * Create TC build that packs and publishes new nuget package * x86/x64?) > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1880) .Net: Intermittent "Invalid global JNI handle passed to DeleteGlobalRef"
[
https://issues.apache.org/jira/browse/IGNITE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998513#comment-14998513
]
Pavel Tupitsyn commented on IGNITE-1880:
-
LocalToGlobal call was missing from ContinuousQueryGetInitialQueryCursor.
> .Net: Intermittent "Invalid global JNI handle passed to DeleteGlobalRef"
>
>
> Key: IGNITE-1880
> URL: https://issues.apache.org/jira/browse/IGNITE-1880
> Project: Ignite
> Issue Type: Bug
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Example of a failure: http://94.72.60.102/viewLog.html?buildId=565513
> {code}
> [18:07:47] : [Step 10/11] FATAL ERROR in native method: Invalid global JNI
> handle passed to DeleteGlobalRef
> [18:07:47] : [Step 10/11] FATAL ERROR in native method: Bad global or local
> ref passed to JNI
> {code}
> UnmanagedTarget class releases JNI handles in finalizer.
> Finalizers run at non-deterministic time. Due to some irrelevant changes
> there may be failures sometimes. Need to ensure that we do not release the
> same handle twice, and that we pass correct handles from unmanaged code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002326#comment-15002326 ] Pavel Tupitsyn edited comment on IGNITE-1626 at 11/12/15 4:17 PM: --- * nuspec file created to include all necessary JAR files, Apache.Ignite.Core.dll, and default config file * version is being set automatically from assemblyinfo * IGNITE_HOME resolve logic adjusted to detect NuGet deployment * Package tested locally: no extra steps from the user are required (besides Java installation). Install package => Ignition.Start works. * TC config created to build nupkg: http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet > INFRA team must be asked about a place where NuGet package could be stored. No need for this. Package is created by TC task, tested, and then pushed to nuget.org. What is left: * proper wording in summary and description * icon was (Author: ptupitsyn): * nuspec file created to include all necessary JAR files, Apache.Ignite.Core.dll, and default config file * version is being set automatically from assemblyinfo * IGNITE_HOME resolve logic adjusted to detect NuGet deployment * Package tested locally: no extra steps from the user are required (besides Java installation). Install package => Ignition.Start works. * TC config created to build nupkg: http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1896) .Net: Improve query API
Pavel Tupitsyn created IGNITE-1896:
---
Summary: .Net: Improve query API
Key: IGNITE-1896
URL: https://issues.apache.org/jira/browse/IGNITE-1896
Project: Ignite
Issue Type: Improvement
Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 1.5
Current API is very clumsy.
Cache is generic, however we require the user to specify query type explicitly.
There are cases when query type is a string and/or is different from current
cache generic type, so the current API has to be kept.
However, we should provide simple methods with generic inference:
{code}
IQueryCursor> ScanQuery(ICacheEntryFilter
filter);
IQueryCursor> SqlQuery(string sql, params object[]
args);
IQueryCursor> SqlQuery(string sql, bool local,
params object[] args);
IQueryCursor> TextQuery(string text);
IQueryCursor> TextQuery(string text, bool local);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1933) .Net: GetOrCreateCache overloads with CacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1933: Assignee: (was: Pavel Tupitsyn) > .Net: GetOrCreateCache overloads with CacheConfiguration > > > Key: IGNITE-1933 > URL: https://issues.apache.org/jira/browse/IGNITE-1933 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn > Fix For: 1.6 > > > Add GetOrCreateCache overloads that accept CacheConfiguration, similar to > Ignite in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1933) .Net: GetOrCreateCache overloads with CacheConfiguration
Pavel Tupitsyn created IGNITE-1933: --- Summary: .Net: GetOrCreateCache overloads with CacheConfiguration Key: IGNITE-1933 URL: https://issues.apache.org/jira/browse/IGNITE-1933 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.6 Add GetOrCreateCache overloads that accept CacheConfiguration, similar to Ignite in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1907) .Net: Cache configuration
[ https://issues.apache.org/jira/browse/IGNITE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1907: Description: Configure cache in code (was: * Configure cache in code * Add GetOrCreateCache overloads) > .Net: Cache configuration > - > > Key: IGNITE-1907 > URL: https://issues.apache.org/jira/browse/IGNITE-1907 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > Configure cache in code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1933) .Net: GetOrCreateCache overloads with CacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1933: --- Assignee: Pavel Tupitsyn > .Net: GetOrCreateCache overloads with CacheConfiguration > > > Key: IGNITE-1933 > URL: https://issues.apache.org/jira/browse/IGNITE-1933 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Add GetOrCreateCache overloads that accept CacheConfiguration, similar to > Ignite in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1908) .Net: Query configuration
[ https://issues.apache.org/jira/browse/IGNITE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008671#comment-15008671 ] Pavel Tupitsyn commented on IGNITE-1908: - Stopping this because new query API (QueryEntity) is not yet finalized. > .Net: Query configuration > - > > Key: IGNITE-1908 > URL: https://issues.apache.org/jira/browse/IGNITE-1908 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Configure queries in code. > This includes attribute-based configuration (similar to QuerySqlField in > Java). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1934) .Net: Store tests broken after keepPortableInStore renaming
Pavel Tupitsyn created IGNITE-1934: --- Summary: .Net: Store tests broken after keepPortableInStore renaming Key: IGNITE-1934 URL: https://issues.apache.org/jira/browse/IGNITE-1934 Project: Ignite Issue Type: Bug Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Priority: Blocker Fix For: 1.5 Need to fix .net test configs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1907) .Net: Cache configuration
[ https://issues.apache.org/jira/browse/IGNITE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1907: Description: * Configure cache in code * Add GetOrCreateCache overloads was:Configure cache in code > .Net: Cache configuration > - > > Key: IGNITE-1907 > URL: https://issues.apache.org/jira/browse/IGNITE-1907 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.5 > > > * Configure cache in code > * Add GetOrCreateCache overloads -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1880) .Net: Intermittent "Invalid global JNI handle passed to DeleteGlobalRef"
Pavel Tupitsyn created IGNITE-1880:
---
Summary: .Net: Intermittent "Invalid global JNI handle passed to
DeleteGlobalRef"
Key: IGNITE-1880
URL: https://issues.apache.org/jira/browse/IGNITE-1880
Project: Ignite
Issue Type: Bug
Components: interop
Affects Versions: 1.5
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 1.5
Example of a failure: http://94.72.60.102/viewLog.html?buildId=565513
{code}
[18:07:47] : [Step 10/11] FATAL ERROR in native method: Invalid global JNI
handle passed to DeleteGlobalRef
[18:07:47] : [Step 10/11] FATAL ERROR in native method: Bad global or local
ref passed to JNI
{code}
UnmanagedTarget class releases JNI handles in finalizer.
Finalizers run at non-deterministic time. Due to some irrelevant changes there
may be failures sometimes. Need to ensure that we do not release the same
handle twice, and that we pass correct handles from unmanaged code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1881) .Net: Rename "portable" to "binary/binarizable"
Pavel Tupitsyn created IGNITE-1881: --- Summary: .Net: Rename "portable" to "binary/binarizable" Key: IGNITE-1881 URL: https://issues.apache.org/jira/browse/IGNITE-1881 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 https://issues.apache.org/jira/browse/IGNITE-1845 addressed these renames in Core, need to do the same in the rest of the codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1873) .Net: Investigate BinaryFormatter vs DataContractSerializer vs XmlSerializer
Pavel Tupitsyn created IGNITE-1873: --- Summary: .Net: Investigate BinaryFormatter vs DataContractSerializer vs XmlSerializer Key: IGNITE-1873 URL: https://issues.apache.org/jira/browse/IGNITE-1873 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: 1.6 Reporter: Pavel Tupitsyn Priority: Minor Fix For: 1.6 DataContractSerializer and XmlSerializer, in binary mode (BinaryWriter), are said to be faster and produce more compact results than BinaryFormatter. We can consider changing it in SerializableObjectHolder. Need to run benchmarks first. Comprehensive feature comparison: http://manski.net/2014/10/net-serializers-comparison-chart/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1414) .Net: support async/await in the API via extension methods
[
https://issues.apache.org/jira/browse/IGNITE-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn closed IGNITE-1414.
---
> .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
>
> 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] [Assigned] (IGNITE-1563) .Net: Implement "atomic" data structures.
[ https://issues.apache.org/jira/browse/IGNITE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1563: --- Assignee: Pavel Tupitsyn > .Net: Implement "atomic" data structures. > - > > Key: IGNITE-1563 > URL: https://issues.apache.org/jira/browse/IGNITE-1563 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > This includes: > atomicSequence; > atomicStamped; > atomicReference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1417) .Net: Implement distributed queue.
[ https://issues.apache.org/jira/browse/IGNITE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1417: Summary: .Net: Implement distributed queue. (was: .Net: Implement desitributed queue.) > .Net: Implement distributed queue. > -- > > Key: IGNITE-1417 > URL: https://issues.apache.org/jira/browse/IGNITE-1417 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1835) .Net: Use thread-local pool to store schemas in PortableWriter
[ https://issues.apache.org/jira/browse/IGNITE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987203#comment-14987203 ] Pavel Tupitsyn edited comment on IGNITE-1835 at 11/3/15 1:09 PM: -- I'm not sure about shrinking. If the array has come to a certain size, it happened for a reason, and it will probably happen again. Doing 2 reallocations of an array on each write will perform poorly. And we are talking about small savings here. In Java there is a 256*4=1KB limit for the buffer. IGNITE-1814 has been merged to 1282, and I've merged from 1282. was (Author: ptupitsyn): I'm not sure about shrinking. If the array has come to a certain size, it happened for a reason, and it will probably happen again. Doing 2 reallocations of an array on each write will perform poorly. And we are talking about laughable savings here. In Java there is a 256*4=1KB limit for the buffer. > .Net: Use thread-local pool to store schemas in PortableWriter > -- > > Key: IGNITE-1835 > URL: https://issues.apache.org/jira/browse/IGNITE-1835 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > Avoid array allocations in PortableWriter by keeping a single ThreadLocal > array to store schema fields. > See SchemaHolder in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1835) .Net: Use thread-local pool to store schemas in PortableWriter
[ https://issues.apache.org/jira/browse/IGNITE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987203#comment-14987203 ] Pavel Tupitsyn commented on IGNITE-1835: - I'm not sure about shrinking. If the array has come to a certain size, it happened for a reason, and it will probably happen again. Doing 2 reallocations of an array on each write will perform poorly. And we are talking about laughable savings here. In Java there is a 256*4=1KB limit for the buffer. > .Net: Use thread-local pool to store schemas in PortableWriter > -- > > Key: IGNITE-1835 > URL: https://issues.apache.org/jira/browse/IGNITE-1835 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > Avoid array allocations in PortableWriter by keeping a single ThreadLocal > array to store schema fields. > See SchemaHolder in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1768) .Net: Review portable configuration on Java side.
[ https://issues.apache.org/jira/browse/IGNITE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14982228#comment-14982228 ] Pavel Tupitsyn commented on IGNITE-1768: - * LifecycleBean * CacheStore * TypeConfiguration > .Net: Review portable configuration on Java side. > - > > Key: IGNITE-1768 > URL: https://issues.apache.org/jira/browse/IGNITE-1768 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > I am concerned why for some objects we pass assembly + type, while for others > type only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1768) .Net: Review portable configuration on Java side.
[ https://issues.apache.org/jira/browse/IGNITE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1768: --- Assignee: Pavel Tupitsyn > .Net: Review portable configuration on Java side. > - > > Key: IGNITE-1768 > URL: https://issues.apache.org/jira/browse/IGNITE-1768 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > I am concerned why for some objects we pass assembly + type, while for others > type only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1768) .Net: Review portable configuration on Java side.
[ https://issues.apache.org/jira/browse/IGNITE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14982228#comment-14982228 ] Pavel Tupitsyn edited comment on IGNITE-1768 at 10/30/15 9:43 AM: --- * LifecycleBean * CacheStore * TypeConfiguration * IdMapper/NameMapper * IPortables PlatformDotNetPortableTypeConfiguration has nameMapper, idMapper, serializer which are type names without an assembly. was (Author: ptupitsyn): * LifecycleBean * CacheStore * TypeConfiguration * IdMapper/NameMapper * IPortables > .Net: Review portable configuration on Java side. > - > > Key: IGNITE-1768 > URL: https://issues.apache.org/jira/browse/IGNITE-1768 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > I am concerned why for some objects we pass assembly + type, while for others > type only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1818) .Net: compact footer offsets
Pavel Tupitsyn created IGNITE-1818: --- Summary: .Net: compact footer offsets Key: IGNITE-1818 URL: https://issues.apache.org/jira/browse/IGNITE-1818 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 Implement protocol changes in .NET -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1858) .Net: Update project settings to support VS2010-VS2015
[ https://issues.apache.org/jira/browse/IGNITE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1858: Summary: .Net: Update project settings to support VS2010-VS2015 (was: .Net: Update project settings to support VS2015) > .Net: Update project settings to support VS2010-VS2015 > -- > > Key: IGNITE-1858 > URL: https://issues.apache.org/jira/browse/IGNITE-1858 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: > * Benchmark performance in Release mode is very low. Turns out "optimize > code" is unchecked in project settings. For some reason, this checkbox does > not affect benchmarks in VS2013, but the difference is dramatic in VS2015. > * Language version is not set, so VS2015 allows C# 6 features like null > propagation (and R# suggests these changes). But using these features will > break compilation in VS2013 and earlier. So we should set language version to > C# 4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1858) .Net: Update project settings to support VS2015
[ https://issues.apache.org/jira/browse/IGNITE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1858: Affects Version/s: 1.5 > .Net: Update project settings to support VS2015 > --- > > Key: IGNITE-1858 > URL: https://issues.apache.org/jira/browse/IGNITE-1858 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > > I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: > * Benchmark performance in Release mode is very low. Turns out "optimize > code" is unchecked in project settings. For some reason, this checkbox does > not affect benchmarks in VS2013, but the difference is dramatic in VS2015. > * Language version is not set, so VS2015 allows C# 6 features like null > propagation (and R# suggests these changes). But using these features will > break compilation in VS2013 and earlier. So we should set language version to > C# 4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1858) .Net: Update project settings to support VS2015
[ https://issues.apache.org/jira/browse/IGNITE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1858: Fix Version/s: 1.5 > .Net: Update project settings to support VS2015 > --- > > Key: IGNITE-1858 > URL: https://issues.apache.org/jira/browse/IGNITE-1858 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: > * Benchmark performance in Release mode is very low. Turns out "optimize > code" is unchecked in project settings. For some reason, this checkbox does > not affect benchmarks in VS2013, but the difference is dramatic in VS2015. > * Language version is not set, so VS2015 allows C# 6 features like null > propagation (and R# suggests these changes). But using these features will > break compilation in VS2013 and earlier. So we should set language version to > C# 4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1858) .Net: Update project settings to support VS2015
Pavel Tupitsyn created IGNITE-1858: --- Summary: .Net: Update project settings to support VS2015 Key: IGNITE-1858 URL: https://issues.apache.org/jira/browse/IGNITE-1858 Project: Ignite Issue Type: Task Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: * Benchmark performance in Release mode is very low. Turns out "optimize code" is unchecked in project settings. For some reason, this checkbox does not affect benchmarks in VS2013, but the difference is dramatic in VS2015. * Language version is not set, so VS2015 allows C# 6 features like null propagation (and R# suggests these changes). But using these features will break compilation in VS2013 and earlier. So we should set language version to C# 4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1858) .Net: Update project settings to support VS2010-VS2015
[ https://issues.apache.org/jira/browse/IGNITE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1858: Description: I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: * Benchmark performance in Release mode is very low. Turns out "optimize code" is unchecked in project settings. For some reason, this checkbox does not affect benchmarks in VS2013, but the difference is dramatic in VS2015. * Language version is not set, so VS2015 allows C# 6 features like null propagation (and R# suggests these changes). But using these features will break compilation in VS2013 and earlier. So we should set language version to C# 4.0 And current solution file can't be opened in VS2010. Need to fix version in header. was: I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: * Benchmark performance in Release mode is very low. Turns out "optimize code" is unchecked in project settings. For some reason, this checkbox does not affect benchmarks in VS2013, but the difference is dramatic in VS2015. * Language version is not set, so VS2015 allows C# 6 features like null propagation (and R# suggests these changes). But using these features will break compilation in VS2013 and earlier. So we should set language version to C# 4.0 > .Net: Update project settings to support VS2010-VS2015 > -- > > Key: IGNITE-1858 > URL: https://issues.apache.org/jira/browse/IGNITE-1858 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: > * Benchmark performance in Release mode is very low. Turns out "optimize > code" is unchecked in project settings. For some reason, this checkbox does > not affect benchmarks in VS2013, but the difference is dramatic in VS2015. > * Language version is not set, so VS2015 allows C# 6 features like null > propagation (and R# suggests these changes). But using these features will > break compilation in VS2013 and earlier. So we should set language version to > C# 4.0 > And current solution file can't be opened in VS2010. Need to fix version in > header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1858) .Net: Update project settings to support VS2010-VS2015
[ https://issues.apache.org/jira/browse/IGNITE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991359#comment-14991359 ] Pavel Tupitsyn commented on IGNITE-1858: - Turns out that VS2010 does not support langVersion switch. So we'll have to skip this change. > .Net: Update project settings to support VS2010-VS2015 > -- > > Key: IGNITE-1858 > URL: https://issues.apache.org/jira/browse/IGNITE-1858 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: > * Benchmark performance in Release mode is very low. Turns out "optimize > code" is unchecked in project settings. For some reason, this checkbox does > not affect benchmarks in VS2013, but the difference is dramatic in VS2015. > * Language version is not set, so VS2015 allows C# 6 features like null > propagation (and R# suggests these changes). But using these features will > break compilation in VS2013 and earlier. So we should set language version to > C# 4.0 > And current solution file can't be opened in VS2010. Need to fix version in > header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1858) .Net: Update project settings to support VS2010-VS2015
[ https://issues.apache.org/jira/browse/IGNITE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991407#comment-14991407 ] Pavel Tupitsyn commented on IGNITE-1858: - Changes made: * fix sln file to support VS2010 * fix a couple of generic inference issues for VS2010 compiler * Enable code optimization in all projects in Release Verified in VS2010, VS2013, VS2015. Code compiles and runs, benchmark results are equally fine. TC is ok. > .Net: Update project settings to support VS2010-VS2015 > -- > > Key: IGNITE-1858 > URL: https://issues.apache.org/jira/browse/IGNITE-1858 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > I've opened Ignite.NET solution in VS2015 and noticed a couple of issues: > * Benchmark performance in Release mode is very low. Turns out "optimize > code" is unchecked in project settings. For some reason, this checkbox does > not affect benchmarks in VS2013, but the difference is dramatic in VS2015. > * Language version is not set, so VS2015 allows C# 6 features like null > propagation (and R# suggests these changes). But using these features will > break compilation in VS2013 and earlier. So we should set language version to > C# 4.0 > And current solution file can't be opened in VS2010. Need to fix version in > header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1737) .Net: Review naming and xmldoc in IPortableTypeDescriptor
[ https://issues.apache.org/jira/browse/IGNITE-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-1737. --- > .Net: Review naming and xmldoc in IPortableTypeDescriptor > - > > Key: IGNITE-1737 > URL: https://issues.apache.org/jira/browse/IGNITE-1737 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > * NameConverter & Mapper properties should be renamed > * documentation needs to be more detaileed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1737) .Net: Review naming and xmldoc in IPortableTypeDescriptor
[ https://issues.apache.org/jira/browse/IGNITE-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-1737. - Resolution: Fixed Assignee: Pavel Tupitsyn Done as part of IGNITE-1834 > .Net: Review naming and xmldoc in IPortableTypeDescriptor > - > > Key: IGNITE-1737 > URL: https://issues.apache.org/jira/browse/IGNITE-1737 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > * NameConverter & Mapper properties should be renamed > * documentation needs to be more detaileed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1845) .Net: Adopt portable API changes.
[ https://issues.apache.org/jira/browse/IGNITE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1845: --- Assignee: Pavel Tupitsyn > .Net: Adopt portable API changes. > - > > Key: IGNITE-1845 > URL: https://issues.apache.org/jira/browse/IGNITE-1845 > Project: Ignite > Issue Type: Task > Components: general, interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.5 > > > Important API changes will be introduced as a part of IGNITE-950. > Once these changes are in place, we need to port them to .Net. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1785) .Net: Improve PlatformMemory/PortableStream performance and memory usage
[ https://issues.apache.org/jira/browse/IGNITE-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1785: --- Assignee: (was: Pavel Tupitsyn) > .Net: Improve PlatformMemory/PortableStream performance and memory usage > > > Key: IGNITE-1785 > URL: https://issues.apache.org/jira/browse/IGNITE-1785 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn > Fix For: 1.6 > > > * PlatformMemory is just a single "long _memPtr" and can be easily converted > to a struct to reduce allocations (it is allocated a lot) > * PlatformMemoryStream works with PlatformMemory.Length and Capacity > indirectly. By employing a struct approach from > https://issues.apache.org/jira/browse/IGNITE-1428 we can work with Length and > Capacity directly, which may be faster, and will eliminate the need for > SyncronizeInput/Output calls. > * PlatformMemoryStream is allocated even more often than PlatformMemory, need > to investigate whether it can also be a struct. See how List<>.GetEnumerator > works, which is a struct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1737) .Net: Review naming and xmldoc in IPortableTypeDescriptor
[ https://issues.apache.org/jira/browse/IGNITE-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1737: --- Assignee: (was: Pavel Tupitsyn) > .Net: Review naming and xmldoc in IPortableTypeDescriptor > - > > Key: IGNITE-1737 > URL: https://issues.apache.org/jira/browse/IGNITE-1737 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn > Fix For: 1.6 > > > * NameConverter & Mapper properties should be renamed > * documentation needs to be more detaileed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1428) .Net: Use struct with fixed layout for InteropMemory operations.
[ https://issues.apache.org/jira/browse/IGNITE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1428: --- Assignee: Pavel Tupitsyn > .Net: Use struct with fixed layout for InteropMemory operations. > > > Key: IGNITE-1428 > URL: https://issues.apache.org/jira/browse/IGNITE-1428 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Minor > > This will decrease probability of bugs caused by pointer arithmetics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1791) .Net: Improve Task-based async API efficiency with TaskCompletionSource
[ https://issues.apache.org/jira/browse/IGNITE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-1791. - Resolution: Fixed Done as part of IGNITE-1652. > .Net: Improve Task-based async API efficiency with TaskCompletionSource > --- > > Key: IGNITE-1791 > URL: https://issues.apache.org/jira/browse/IGNITE-1791 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Currently we use TaskFactory.FromAsync to create tasks and return them from > API. This requires implementing IAsyncResult, which has a heavyweight > WaitHandle inside. TaskFactory then uses > ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task > completion. > Creating WaitHandle and waiting on it are redundant extra steps. > [TaskCompletionSource|https://msdn.microsoft.com/en-us/library/dd449174(v=vs.100).aspx] > allows lighter-weight approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1791) .Net: Improve Task-based async API efficiency with TaskCompletionSource
[ https://issues.apache.org/jira/browse/IGNITE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-1791. --- > .Net: Improve Task-based async API efficiency with TaskCompletionSource > --- > > Key: IGNITE-1791 > URL: https://issues.apache.org/jira/browse/IGNITE-1791 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Currently we use TaskFactory.FromAsync to create tasks and return them from > API. This requires implementing IAsyncResult, which has a heavyweight > WaitHandle inside. TaskFactory then uses > ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task > completion. > Creating WaitHandle and waiting on it are redundant extra steps. > [TaskCompletionSource|https://msdn.microsoft.com/en-us/library/dd449174(v=vs.100).aspx] > allows lighter-weight approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1835) .Net: Use thread-local pool to store schemas in PortableWriter
Pavel Tupitsyn created IGNITE-1835: --- Summary: .Net: Use thread-local pool to store schemas in PortableWriter Key: IGNITE-1835 URL: https://issues.apache.org/jira/browse/IGNITE-1835 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 Avoid array allocations in PortableWriter by keeping a single ThreadLocal array to store schema fields. See SchemaHolder in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1834) .Net: Remove MetadataEnabled property
Pavel Tupitsyn created IGNITE-1834: --- Summary: .Net: Remove MetadataEnabled property Key: IGNITE-1834 URL: https://issues.apache.org/jira/browse/IGNITE-1834 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 MetadataEnabled is going to be removed from Ignite, need to reflect this in .Net. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1866) .Net: turn SerializableObjectHolder & DateTimeHolder into structs
Pavel Tupitsyn created IGNITE-1866: --- Summary: .Net: turn SerializableObjectHolder & DateTimeHolder into structs Key: IGNITE-1866 URL: https://issues.apache.org/jira/browse/IGNITE-1866 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 Reduce allocations on read and write -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1863) IgniteAtomicReference.compareAndSet does not work for nulls
[
https://issues.apache.org/jira/browse/IGNITE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1863:
Description:
IgniteAtomicReference allows null as a value, but when current value is null,
compareAndSet does not work:
{code}
IgniteAtomicReference atomic =
ignite.atomicReference(atomicName, null, true);
assertEquals(null, atomic.get());
boolean res = atomic.compareAndSet(null, "x");
assertTrue(res);// fail
assertEquals("x", atomic.get());// fail
{code}
was:
IgniteAtomicReference allows null as a value, but when current value is null,
compareAndSet does not work:
{code}
IgniteAtomicReference atomic =
ignite.atomicReference(atomicName, null, true);
assertEquals(null, atomic.get());
boolean res = atomic.compareAndSet(null, "x");
assertEquals(null, atomic.get()); // ok
assertTrue(res);// fail
assertEquals("x", atomic.get());// fail
{code}
> IgniteAtomicReference.compareAndSet does not work for nulls
> ---
>
> Key: IGNITE-1863
> URL: https://issues.apache.org/jira/browse/IGNITE-1863
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
> Fix For: 1.5
>
>
> IgniteAtomicReference allows null as a value, but when current value is null,
> compareAndSet does not work:
> {code}
> IgniteAtomicReference atomic =
> ignite.atomicReference(atomicName, null, true);
> assertEquals(null, atomic.get());
> boolean res = atomic.compareAndSet(null, "x");
> assertTrue(res);// fail
> assertEquals("x", atomic.get());// fail
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1863) IgniteAtomicReference.compareAndSet does not work for nulls
Pavel Tupitsyn created IGNITE-1863:
---
Summary: IgniteAtomicReference.compareAndSet does not work for
nulls
Key: IGNITE-1863
URL: https://issues.apache.org/jira/browse/IGNITE-1863
Project: Ignite
Issue Type: Bug
Components: data structures
Affects Versions: 1.5
Reporter: Pavel Tupitsyn
Fix For: 1.5
IgniteAtomicReference allows null as a value, but when current value is null,
compareAndSet does not work:
{code}
IgniteAtomicReference atomic =
ignite.atomicReference(atomicName, null, true);
assertEquals(null, atomic.get());
boolean res = atomic.compareAndSet(null, "x");
assertEquals(null, atomic.get()); // ok
assertTrue(res);// fail
assertEquals("x", atomic.get());// fail
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1768) .Net: Review portable configuration on Java side.
[ https://issues.apache.org/jira/browse/IGNITE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14982228#comment-14982228 ] Pavel Tupitsyn edited comment on IGNITE-1768 at 10/30/15 9:35 AM: --- * LifecycleBean * CacheStore * TypeConfiguration * IdMapper/NameMapper * IPortables was (Author: ptupitsyn): * LifecycleBean * CacheStore * TypeConfiguration > .Net: Review portable configuration on Java side. > - > > Key: IGNITE-1768 > URL: https://issues.apache.org/jira/browse/IGNITE-1768 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > I am concerned why for some objects we pass assembly + type, while for others > type only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
