[jira] [Created] (IGNITE-1785) .Net: Improve PlatformMemory/PortableStream performance and memory usage

2015-10-23 Thread Pavel Tupitsyn (JIRA) 
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] [Created] (IGNITE-1780) .Net: DateTime is seialized incorrectly.

2015-10-23 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1780:
---

 Summary: .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
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-1780) .Net: DateTime is seialized incorrectly.

2015-10-23 Thread Pavel Tupitsyn (JIRA) 

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

2015-10-23 Thread Pavel Tupitsyn (JIRA) 

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

2015-10-23 Thread Pavel Tupitsyn (JIRA) 

 [ 
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

2015-10-23 Thread Pavel Tupitsyn (JIRA) 

 [ 
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] [Resolved] (IGNITE-1597) Improve filtering behavior

2015-10-23 Thread Andrey Novikov (JIRA) 

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

Andrey Novikov resolved IGNITE-1597.

Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Andrey Novikov)

Notes fixed.

> Improve filtering behavior 
> ---
>
> Key: IGNITE-1597
> URL: https://issues.apache.org/jira/browse/IGNITE-1597
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.5
>
>
> Currently we do not hide content of current active item even if it doesn't 
> matching to the filter. We should improve this place.
> 1) print out placeholder in case when no one item is matched the filter
> something like "no items are matching to current filer"
> 2) hide content of active item if it not matching current filter



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

[jira] [Updated] (IGNITE-1225) HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always fails on public TC

2015-10-23 Thread Artem Shutak (JIRA) 

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

Artem Shutak updated IGNITE-1225:
-
Issue Type: Test  (was: Bug)

> HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always 
> fails on public TC
> -
>
> Key: IGNITE-1225
> URL: https://issues.apache.org/jira/browse/IGNITE-1225
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Ivan Veselovsky
> Fix For: 1.5
>
>
> HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always 
> fails on public TC.
> See
> HadoopCommandLineTest.testHadoopCommandLine   
> HadoopCommandLineTest.testHiveCommandLine 
> Need to investigate.



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

[jira] [Closed] (IGNITE-1718) ScalaPrimeExample fails with "Not enough data to read the value" error when it's running with portableMarshaller

2015-10-23 Thread Vasilisa Sidorova (JIRA) 

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

Vasilisa  Sidorova closed IGNITE-1718.
--

Fix verified for Ubuntu 14.04, Apache Ignite 1.5.0 build #42, rev. 
0bc1d6f42e637e5bfc45aa99fdcb68fc7896ef4e

> ScalaPrimeExample fails with "Not enough data to read the value" error when 
> it's running with portableMarshaller
> 
>
> Key: IGNITE-1718
> URL: https://issues.apache.org/jira/browse/IGNITE-1718
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5
> Environment: Ubuntu 14.04, community 1.5.0 build #319
>Reporter: Vasilisa  Sidorova
>Assignee: Vasilisa  Sidorova
> Fix For: 1.5
>
>
> -
> DESCRIPTION
> -
> When default optimizedMarshaller is changed into portableMarshaller in 
> example-ignite.xml then ScalarPrimeExample doesn't start with exception "Not 
> enough data to read the value"
> -
> STEPS FOR REPRODUCE
> -
> 1. Build examples project in IDE
> 2.In the example-ignite.xml change property from:
> {noformat}
> 
>  class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> -->
> 
>  ACTUAL RESULT
> -
> Example is failed with exception:
> {noformat}
> Exception in thread "ignite-#21%sys-null%" class 
> org.apache.ignite.internal.portable.api.PortableException: Not enough data to 
> read the value [position=18, requiredBytes=1, remainingBytes=0]
>   at 
> org.apache.ignite.internal.portable.streams.PortableAbstractInputStream.ensureEnoughData(PortableAbstractInputStream.java:288)
>   at 
> org.apache.ignite.internal.portable.streams.PortableAbstractInputStream.readByte(PortableAbstractInputStream.java:32)
>   at 
> org.apache.ignite.internal.portable.PortableReaderExImpl.doReadByte(PortableReaderExImpl.java:1895)
>   at 
> org.apache.ignite.internal.portable.PortableReaderExImpl.doReadClass(PortableReaderExImpl.java:2986)
>   at 
> org.apache.ignite.internal.portable.PortableReaderExImpl.readObjectTypeId(PortableReaderExImpl.java:211)
>   at 
> org.apache.ignite.internal.portable.PortableReaderExImpl.deserialize(PortableReaderExImpl.java:2142)
>   at 
> org.apache.ignite.internal.portable.GridPortableMarshaller.deserialize(GridPortableMarshaller.java:274)
>   at 
> org.apache.ignite.internal.portable.api.PortableMarshaller.unmarshal(PortableMarshaller.java:328)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:762)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:995)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1219)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
>   at java.lang.Thread.run(Thread.java:809)
> {noformat}
> -
> EXPECTED RESULT
> -
> Example is passed without any exceptions



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

[jira] [Commented] (IGNITE-1653) Need to remove lgpl-dependent examples from Ignite binaries

2015-10-23 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov commented on IGNITE-1653:
--

Current solution:

sources - lgpl off by default, but can be switched on without issues

apache-ignite-fabric-lgpl - lgpl on, causes no compilation issues in case 
Release released with lgpl profile (released by some other person/company, 
because community cannot provide lgpl release)
apache-ignite-fabric - lgpl off, swithing on causes compilation issues. 
README.txt explains how to solve this issues.

> Need to remove lgpl-dependent examples from Ignite binaries
> ---
>
> Key: IGNITE-1653
> URL: https://issues.apache.org/jira/browse/IGNITE-1653
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5
> Environment: Apache-Ignite-1.5.0 build #29
>Reporter: Vasilisa  Sidorova
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.5
>
>
> Examples project from Ignite binaries couldn't be compiled due to there is 
> lgpl-dependencies.
> Solution: lgpl-dependent examples should be removed from Ignite src and bin



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

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

2015-10-23 Thread Yakov Zhdanov (JIRA) 

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

Yakov Zhdanov commented on IGNITE-638:
--

Vlad,

Great job! I reviewed the code and I really liked it!

Couple of points though:

# I think we can should without 
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.Sync#threadMap.
 We need a bit another approach. Why do I need to increment waiters (globally 
in cache) for each thread in local JVM? Can we use JVM as a waiter and not to 
update global object for each thread? I think this can save a lot of cache 
operations.
# Please add failover tests - if they fail we can always disable them unless 
fixed.
# Please add tests for example you have added. See IgniteExamplesSelfTestSuite.
# GridCacheSemaphoreImpl.initCnt - what is this for? Can we just remove it?
# Do you think we really need {{fair}} semaphore? I doubt if this makes sense 
with distributed semaphore.
# Do not forget about Apache copyright - I added missing

I pushed my changes to {{ignite-638}} branch. Please review them and address my 
comments basing on mentioned branch.

Looking forward to getting an update and next contribution!

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



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

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

2015-10-23 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov closed IGNITE-1572.
---

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



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

[jira] [Comment Edited] (IGNITE-1597) Improve filtering behavior

2015-10-23 Thread Pavel Konstantinov (JIRA) 

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

Pavel Konstantinov edited comment on IGNITE-1597 at 10/23/15 10:43 AM:
---

1) Need to fix filtration in case when only invalid metadatas are displaying.
2) Metadata list is empty after last invalid item was deleted
- load valid + invalid metadata from DB
- switch to invalid
- remove each item

3) hide the content of current valid metadata after the list was switched to 
invalid items


was (Author: pkonstantinov):
1) Need to fix filtration in case when only invalid metadatas are displaying.
2) Metadata list is empty after last invalid item was deleted
- load valid + invalid metadata from DB
- switch to invalid
- remove each item
3) hide the content of current valid metadata after the list was switched to 
invalid items

> Improve filtering behavior 
> ---
>
> Key: IGNITE-1597
> URL: https://issues.apache.org/jira/browse/IGNITE-1597
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.5
>
>
> Currently we do not hide content of current active item even if it doesn't 
> matching to the filter. We should improve this place.
> 1) print out placeholder in case when no one item is matched the filter
> something like "no items are matching to current filer"
> 2) hide content of active item if it not matching current filter



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

[jira] [Created] (IGNITE-1782) IgniteKernal get wrong message in the log about set marshaller

2015-10-23 Thread Vasilisa Sidorova (JIRA) 
Vasilisa  Sidorova created IGNITE-1782:
--

 Summary: IgniteKernal get wrong message in the log about set 
marshaller
 Key: IGNITE-1782
 URL: https://issues.apache.org/jira/browse/IGNITE-1782
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
 Environment: Ubuntu 14.04, Apache Ignite 1.5.0 build #42, rev. 
0bc1d6f42e637e5bfc45aa99fdcb68fc7896ef4e
Reporter: Vasilisa  Sidorova
 Fix For: 1.5


-
DESCRIPTION
-
This issue have funny essence: when marshaller set into optimized IgniteKernal 
doesn't get any message about marshaller into log. But when marshaller set into 
another type IgniteKernal get message "set 'marshaller' to OptimizedMarshaller"
-
STEPS FOR REPRODUCE
-
# Build examples project
# Run, for example, ExampleNodeStartup with VM option "-DIGNITE_QUIET=false"  
# Actual result: there isn't any message about type of marshaller (Is it 
expected result?)
# Stop node
# In the example-ignite.xml change property from:
{noformat}

 -->

[jira] [Closed] (IGNITE-1782) IgniteKernal get wrong message in the log about set marshaller

2015-10-23 Thread Vasilisa Sidorova (JIRA) 

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

Vasilisa  Sidorova closed IGNITE-1782.
--

> IgniteKernal get wrong message in the log about set marshaller
> --
>
> Key: IGNITE-1782
> URL: https://issues.apache.org/jira/browse/IGNITE-1782
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5
> Environment: Ubuntu 14.04, Apache Ignite 1.5.0 build #42, rev. 
> 0bc1d6f42e637e5bfc45aa99fdcb68fc7896ef4e
>Reporter: Vasilisa  Sidorova
> Fix For: 1.5
>
>
> -
> DESCRIPTION
> -
> This issue have funny essence: when marshaller set into optimized 
> IgniteKernal doesn't get any message about marshaller into log. But when 
> marshaller set into another type IgniteKernal get message "set 'marshaller' 
> to OptimizedMarshaller"
> -
> STEPS FOR REPRODUCE
> -
> # Build examples project
> # Run, for example, ExampleNodeStartup with VM option "-DIGNITE_QUIET=false"  
> # Actual result: there isn't any message about type of marshaller (Is it 
> expected result?)
> # Stop node
> # In the example-ignite.xml change property from:
> {noformat}
> 
>  class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> -->
> 
>  ACTUAL RESULT
> -
> There is message in the log:
> {noformat}
> [15:57:45,260][INFO ][main][IgniteKernal]   ^-- Enable optimized marshaller 
> (set 'marshaller' to OptimizedMarshaller)
> {noformat}
> -
> EXPECTED RESULT
> -
> Undefined: there is shoudln't be any message in the log about marshaller? Or 
> there is should be message about optimized marshaller is disabled? Or 
> something else?



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

[jira] [Updated] (IGNITE-1760) .Net: Validate field type in PortableReaderImpl

2015-10-23 Thread Pavel Tupitsyn (JIRA) 

 [ 
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] [Created] (IGNITE-1781) Broken query header in case of long query name

2015-10-23 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-1781:
--

 Summary: Broken query header in case of long query name
 Key: IGNITE-1781
 URL: https://issues.apache.org/jira/browse/IGNITE-1781
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Please see attachment



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

[jira] [Commented] (IGNITE-1597) Improve filtering behavior

2015-10-23 Thread Pavel Konstantinov (JIRA) 

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

Pavel Konstantinov commented on IGNITE-1597:


Andrey, could you please clarify what exactly was fixed?

> Improve filtering behavior 
> ---
>
> Key: IGNITE-1597
> URL: https://issues.apache.org/jira/browse/IGNITE-1597
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.5
>
>
> Currently we do not hide content of current active item even if it doesn't 
> matching to the filter. We should improve this place.
> 1) print out placeholder in case when no one item is matched the filter
> something like "no items are matching to current filer"
> 2) hide content of active item if it not matching current filter



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

[jira] [Reopened] (IGNITE-1597) Improve filtering behavior

2015-10-23 Thread Pavel Konstantinov (JIRA) 

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

Pavel Konstantinov reopened IGNITE-1597:

  Assignee: Andrey Novikov  (was: Pavel Konstantinov)

> Improve filtering behavior 
> ---
>
> Key: IGNITE-1597
> URL: https://issues.apache.org/jira/browse/IGNITE-1597
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 1.5
>
>
> Currently we do not hide content of current active item even if it doesn't 
> matching to the filter. We should improve this place.
> 1) print out placeholder in case when no one item is matched the filter
> something like "no items are matching to current filer"
> 2) hide content of active item if it not matching current filter



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

[jira] [Closed] (IGNITE-1686) Autoscrolling to the newly created query

2015-10-23 Thread Pavel Konstantinov (JIRA) 

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

Pavel Konstantinov closed IGNITE-1686.
--
Assignee: (was: Pavel Konstantinov)

Tested.

> Autoscrolling to the newly created query
> 
>
> Key: IGNITE-1686
> URL: https://issues.apache.org/jira/browse/IGNITE-1686
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
> Attachments: ig-1686.png
>
>
> Currently user must scroll the page manually.



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

[jira] [Updated] (IGNITE-1225) HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always fails on public TC

2015-10-23 Thread Artem Shutak (JIRA) 

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

Artem Shutak updated IGNITE-1225:
-
Priority: Blocker  (was: Major)

> HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always 
> fails on public TC
> -
>
> Key: IGNITE-1225
> URL: https://issues.apache.org/jira/browse/IGNITE-1225
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.5
>
>
> HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always 
> fails on public TC.
> See
> HadoopCommandLineTest.testHadoopCommandLine   
> HadoopCommandLineTest.testHiveCommandLine 
> Need to investigate.



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

[jira] [Updated] (IGNITE-1225) HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always fails on public TC

2015-10-23 Thread Artem Shutak (JIRA) 

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

Artem Shutak updated IGNITE-1225:
-
Fix Version/s: 1.5

> HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always 
> fails on public TC
> -
>
> Key: IGNITE-1225
> URL: https://issues.apache.org/jira/browse/IGNITE-1225
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.5
>
>
> HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always 
> fails on public TC.
> See
> HadoopCommandLineTest.testHadoopCommandLine   
> HadoopCommandLineTest.testHiveCommandLine 
> Need to investigate.



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

[jira] [Updated] (IGNITE-1781) Broken query header in case of long query name

2015-10-23 Thread Pavel Konstantinov (JIRA) 

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

Pavel Konstantinov updated IGNITE-1781:
---
Attachment: ig-1781.png

> Broken query header in case of long query name
> --
>
> Key: IGNITE-1781
> URL: https://issues.apache.org/jira/browse/IGNITE-1781
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
> Attachments: ig-1781.png
>
>
> Please see attachment



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

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

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

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

ASF GitHub Bot commented on IGNITE-1644:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1644 .Net: DateTime.Kind is lost during serialization



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

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

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

https://github.com/apache/ignite/pull/173.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #173


commit a2ba025271ecbaa656aaa7d6028db49b62f494c7
Author: Pavel Tupitsyn 
Date:   2015-10-23T09:54:44Z

wip

commit bbd3fe83dd039348304132d47f77c34c4ccc0833
Author: Pavel Tupitsyn 
Date:   2015-10-23T09:59:38Z

wip

commit 1045c7db652166864b47aa525ee77a81a521e488
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:00:07Z

wip

commit 364a71dc1a5d48c19c10cd9ece76c278b364552a
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:07:36Z

Move serializable to handlers

commit 53a6635c33a7cf24c858aa602763f8af59170b29
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:23:12Z

wip tests

commit 0580580fa05b9e806dae925629d72a6c4b8be7fe
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:24:37Z

wip

commit dc348d1629fe152dafcb3f40bb7aec68960ca5e3
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:33:26Z

DateTimeHolder

commit 05a5319a9509a405f4a47a31e94fa45bb7a3bc8f
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:36:27Z

TypeDateTimeHolder

commit 1dea88a903fd76f71d4ba22a7c00bd76219dc566
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:42:28Z

wip

commit 3af414cd255ab1f2d0c70dbb4c0a74240d08c09b
Author: Pavel Tupitsyn 
Date:   2015-10-23T10:48:06Z

Fix DateTime arrays




> .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-1644) .Net: DateTime.Kind is lost during serialization

2015-10-23 Thread Pavel Tupitsyn (JIRA) 

[ 
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-1526) IBM JDK is not fully supported by the platfrom

2015-10-23 Thread Andrey Gura (JIRA) 

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

Andrey Gura commented on IGNITE-1526:
-

PR https://github.com/apache/ignite/pull/151 updated. Please review.

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

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

2015-10-23 Thread Andrey Gura (JIRA) 

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

Andrey Gura edited comment on IGNITE-1526 at 10/23/15 4:46 PM:
---

1) Agree. I'll revert this changes.

2) Yes, it is compatibility issue. 

Some additional changes should be done also:

1) When node join to topology we should comapre value of {{USE_DFLT_SUID}} on 
new node and other nodes of topology. If existing nodes have value of this flag 
that differs from new node then exception should be thrown and new node should 
no join to the cluster. If some nodes has no this attribute then we should 
treat it as {{true}}.

2) {{USE_DFLT_SUID}} flag in {{OptimizedMarshaller}} should be used only if 
class doesn't have {{serialVersionUID}}. If class has {{serialVersionUID}} 
field then we can safely use it. This solution fixes problems with 
{{BigInteger}}-like classes that have different implementation but are 
consistent with the serialization viewpoint.




was (Author: agura):
1) Agree. I'll revert this changes.

2) Yes, it is compatibility issue. 

Some additional changes should be done also:

1) When node join to topology we should comapre value of {{USE_DFLT_SUID}} on 
new node and other nodes of topology. If existing nodes have value of this flag 
that differs from new node then exception should be thrown and new node should 
no join to the cluster. If some nodes has no this attribute then we should 
treat it as {{false}}.

2) {{USE_DFLT_SUID}} flag in {{OptimizedMarshaller}} should be used only if 
class doesn't have {{serialVersionUID}}. If class has {{serialVersionUID}} 
field then we can safely use it. This solution fixes problems with 
{{BigInteger}}-like classes that have different implementation but are 
consistent with the serialization viewpoint.



> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some 
> functionality still doesn't work. As an example 
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi] 
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
>   at 
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
>   at 
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
>   at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
>   at 
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing 
> the stack trace below. Tested with JDK and Portable

[jira] [Updated] (IGNITE-606) [Test] Need to fix iterators for GridConcurrentLinkedHashMap in perSegment mode

2015-10-23 Thread Yakov Zhdanov (JIRA) 

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

Yakov Zhdanov updated IGNITE-606:
-
Fix Version/s: 1.5

> [Test] Need to fix iterators for GridConcurrentLinkedHashMap in perSegment 
> mode
> ---
>
> Key: IGNITE-606
> URL: https://issues.apache.org/jira/browse/IGNITE-606
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Yakov Zhdanov
>  Labels: Muted_test
> Fix For: 1.5
>
>
> Fix and uncomment test: 
> GridConcurrentLinkedHashMapMultiThreadedSelfTest.testEvictPerSegment()
> Remove all TODOs: 
> Fix all toString() methods:
> * GridBoundedConcurrentLinkedHashMap
> * GridBoundedConcurrentLinkedHashSet
> * GridConcurrentLinkedHashMap
> * GridConcurrentLinkedHashSet
> See GG-4788.



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

[jira] [Created] (IGNITE-1784) [Failed Test] GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes.

2015-10-23 Thread Artem Shutak (JIRA) 
Artem Shutak created IGNITE-1784:


 Summary: [Failed Test] 
GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes.
 Key: IGNITE-1784
 URL: https://issues.apache.org/jira/browse/IGNITE-1784
 Project: Ignite
  Issue Type: Test
Reporter: Artem Shutak
Priority: Blocker
 Fix For: 1.5


GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes.

Looks like after fail in the test all other tests hanged.

See logs.



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

[jira] [Updated] (IGNITE-1784) [Failed Test] GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes.

2015-10-23 Thread Artem Shutak (JIRA) 

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

Artem Shutak updated IGNITE-1784:
-
Attachment: Ignite_Tests_Ignite_Basic_3553.log.zip

Logs added.

> [Failed Test] GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails 
> on TC sometimes.
> --
>
> Key: IGNITE-1784
> URL: https://issues.apache.org/jira/browse/IGNITE-1784
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Priority: Blocker
>  Labels: Muted_test
> Fix For: 1.5
>
> Attachments: Ignite_Tests_Ignite_Basic_3553.log.zip
>
>
> GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC 
> sometimes.
> Looks like after fail in the test all other tests hanged.
> See logs.



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

[jira] [Created] (IGNITE-1783) Remove GridBoundedConcurrentLinkedHashMap and replace its usages with ConcurrentLinkedHashMap

2015-10-23 Thread Yakov Zhdanov (JIRA) 
Yakov Zhdanov created IGNITE-1783:
-

 Summary: Remove GridBoundedConcurrentLinkedHashMap and replace its 
usages with ConcurrentLinkedHashMap
 Key: IGNITE-1783
 URL: https://issues.apache.org/jira/browse/IGNITE-1783
 Project: Ignite
  Issue Type: Task
Reporter: Yakov Zhdanov
Priority: Trivial


>From what I see {{GridBoundedConcurrentLinkedHashMap}} is redundant and the 
>only difference from {{ConcurrentLinkedHashMap}} is in order of constructor 
>arguments.



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

[jira] [Resolved] (IGNITE-606) [Test] Need to fix iterators for GridConcurrentLinkedHashMap in perSegment mode

2015-10-23 Thread Yakov Zhdanov (JIRA) 

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

Yakov Zhdanov resolved IGNITE-606.
--
Resolution: Fixed

fixed in 1.4-slow-server-debug

will close after merge

> [Test] Need to fix iterators for GridConcurrentLinkedHashMap in perSegment 
> mode
> ---
>
> Key: IGNITE-606
> URL: https://issues.apache.org/jira/browse/IGNITE-606
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Yakov Zhdanov
>  Labels: Muted_test
> Fix For: 1.5
>
>
> Fix and uncomment test: 
> GridConcurrentLinkedHashMapMultiThreadedSelfTest.testEvictPerSegment()
> Remove all TODOs: 
> Fix all toString() methods:
> * GridBoundedConcurrentLinkedHashMap
> * GridBoundedConcurrentLinkedHashSet
> * GridConcurrentLinkedHashMap
> * GridConcurrentLinkedHashSet
> See GG-4788.



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

[jira] [Created] (IGNITE-1786) Need to implement ODBC driver for Ignite

2015-10-23 Thread Dmitriy Setrakyan (JIRA) 
Dmitriy Setrakyan created IGNITE-1786:
-

 Summary: Need to implement ODBC driver for Ignite
 Key: IGNITE-1786
 URL: https://issues.apache.org/jira/browse/IGNITE-1786
 Project: Ignite
  Issue Type: New Feature
  Components: clients
Reporter: Dmitriy Setrakyan
 Fix For: 1.6


# We have a C++ API for Ignite which starts JVM internally. Probably we can 
just add that ODBC API there.
# Another approach is to implement really separate driver and a network server 
on java side which will interact with each other.

The first one is simpler and probably more effective, but heavyweight. The 
second one is probably slower but but more lightweight.




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