[jira] [Commented] (IGNITE-4526) Add Spark Shared RDD examples

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4526:
-

[~manish__mishra], do you have any progress on this?

> Add Spark Shared RDD examples
> -
>
> Key: IGNITE-4526
> URL: https://issues.apache.org/jira/browse/IGNITE-4526
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Manish Mishra
> Fix For: 2.0
>
> Attachments: profiles.png, SuiteSnapShot.png
>
>
> Spark Shared RDD functionality doesn't have its own examples. We need to add 
> an example that will do the following:
> - First Spark Worker: creation of a shared RDD and filling it in with data.
> - First Spark Worker: performing some native spark transformation with the 
> RDD.
> - Second Spark Worker: connecting to the same shared RDD.
> - Second Spark Worker: execution of SQL query using Spark API and Ignite API. 
> Show that Ignite's query executes faster.
> The reason why the example should consist of two workers is to showcase one 
> of the main benefits of Ignite's RDDs - ability to share the state (RDD) amid 
> different Spark workers and processes.



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

[jira] [Commented] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4374:
-

Guys,

The report at the current state looks extensive for me because it's split into 
different sections visually.

I would suggest placing everything under the existing performance section 
controlled by the same single flag. For instance, this how the output might be 
presented to the user.

{code}
[15:09:14] Performance suggestions for grid  (fix if possible)
[15:09:14] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[15:09:14]   ^-- Disable grid events (remove 'includeEventTypes' from 
configuration)
[15:09:14]   ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' paramter to 
JVM options)
[15:09:14]   ^-- Enable server mode for JVM (add '-server' paramter to JVM 
options)
[15:09:14]   ^-- Reduce Java heap size to prevent long GC pauses (use off-heap 
caches and tune '-Xmx' parameter).
[15:09:14]   ^-- {another suggestion}
[15:09:14]   ^-- {another suggestion}
[15:09:14] Refer to this page for more performance suggestions: 
https://apacheignite.readme.io/docs/jvm-and-system-tuning
{code}

How do you like this output? I find it more user friendly and clearer.

Also, I thought over a bit and think that we don't need to show GC logs 
suggestions at all. They are not related to performance but to the debugging 
meaning that it's absolutely fine to go in production if you don't enable GC 
logs. 

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png, 
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Commented] (IGNITE-4212) Ignite Benchmarking Simplification and Automation

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-4212:
--

[~dmagda]

I've made some changes in the doc files. Please take a look when you have a 
moment.

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

> Ignite Benchmarking Simplification and Automation
> -
>
> Key: IGNITE-4212
> URL: https://issues.apache.org/jira/browse/IGNITE-4212
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> There is a plenty of useful Yardstick benchmarks located in ignite-yardstick 
> module that is used by the community to check Ignite performance across 
> deployments of different configurations.
> However, it's not easy to start with the benchmarking process because the 
> user needs to download Ignite, build and set up benchmarks and only after 
> that run them.
> The goal of this task is to simplify the process in the following way:
> 1) ignite-yardstick benchmarks have to be pre-compiled and available with 
> every Ignite deliverable.
> 2) every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 3) the executable has to use some default yardstick configuration. The first 
> configuration should be intented for local execution (multicast IP finder) 
> and the second needs to be AWS oriented.



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

[jira] [Commented] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-1948:
-

Alexander, please send this to the dev list. I'm not a maintainer of this 
module and don't know the best approach.

> ClusterTopologyCheckedException can return null for retryReadyFuture()
> --
>
> Key: IGNITE-1948
> URL: https://issues.apache.org/jira/browse/IGNITE-1948
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Denis Magda
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> It was noted that {{ClusterTopologyCheckedException}} ready future can be 
> null.
> Go though all the places where this kind of exception is being initialized 
> and check why the ready future is not set in some cases.



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

[jira] [Commented] (IGNITE-4570) Handle CREATE INDEX statements

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4570:
-

(after all and at last) working on custom parser for CREATE statements. 
Luckily, it looks feasible due to relative simplicity of  CREATE queries.

> Handle CREATE INDEX statements
> --
>
> Key: IGNITE-4570
> URL: https://issues.apache.org/jira/browse/IGNITE-4570
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
> introduced by IGNITE-4566



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

[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4106:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4106: SQL: parallelize sql queries over cache local partitions



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4106

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

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


commit 5d0417c8cb0f95bc5506a41028b830b831f19863
Author: AMRepo 
Date:   2017-01-19T20:35:06Z

Implemented

commit e638a91eaba80c1f71c0b8a74a59cd5e32122ac2
Author: Andrey V. Mashenkov 
Date:   2017-01-20T10:54:21Z

Minors: Styles & Javadoc

commit 14066d16d429a236ff7bde3e4b5b2653343709c7
Author: Andrey V. Mashenkov 
Date:   2017-01-27T17:02:02Z

Local queries over stripped indices fixed.




> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance
> Fix For: 1.9
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



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

[jira] [Closed] (IGNITE-3385) Improve schema import utility

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-3385.
---

> Improve schema import utility
> -
>
> Key: IGNITE-3385
> URL: https://issues.apache.org/jira/browse/IGNITE-3385
> Project: Ignite
>  Issue Type: Bug
>  Components: general, wizards
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> It would be useful to add more code generation capabilities to
> schema import utility to reduce amount of hand-written boilerplate code.
> * Affinity key mapping
> * SQL query fields and indexes



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

[jira] [Commented] (IGNITE-3385) Improve schema import utility

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3385:
-

Shema import utility is no longer relevant. It will be discontinued in 2.0 in 
favor of Web Console.

> Improve schema import utility
> -
>
> Key: IGNITE-3385
> URL: https://issues.apache.org/jira/browse/IGNITE-3385
> Project: Ignite
>  Issue Type: Bug
>  Components: general, wizards
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> It would be useful to add more code generation capabilities to
> schema import utility to reduce amount of hand-written boilerplate code.
> * Affinity key mapping
> * SQL query fields and indexes



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

[jira] [Resolved] (IGNITE-3385) Improve schema import utility

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-3385.
-
Resolution: Won't Fix

> Improve schema import utility
> -
>
> Key: IGNITE-3385
> URL: https://issues.apache.org/jira/browse/IGNITE-3385
> Project: Ignite
>  Issue Type: Bug
>  Components: general, wizards
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> It would be useful to add more code generation capabilities to
> schema import utility to reduce amount of hand-written boilerplate code.
> * Affinity key mapping
> * SQL query fields and indexes



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

[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4106:


Github user AMashenkov closed the pull request at:

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


> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance
> Fix For: 1.9
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



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

[jira] [Commented] (IGNITE-3793) Need to fix dependencies and it's licenses.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3793:


GitHub user asfedotov opened a pull request:

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

IGNITE-3793: Need to fix dependencies and it's licenses

1) Fix H2 license listed at LICENSE_FABRIC.
2) Fix invalid H2 version in examples.
3) Fix incorrect JCache the license generation after the license changed to 
Apache 2.0 
4) Enable Apache licenses to be shown at ignite-*-licenses.txt.


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

$ git pull https://github.com/gridgain/apache-ignite ignite-3793

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

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






> Need to fix dependencies and it's licenses.
> ---
>
> Key: IGNITE-3793
> URL: https://issues.apache.org/jira/browse/IGNITE-3793
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Alexandr Fedotov
>Priority: Blocker
>  Labels: important
> Fix For: 1.9
>
>
> 1) H2 license listed at LICENSE_FABRIC seems to be wrong.
> Need to make sure that correct one listed at ignite-indexing-licenses.txt and 
> remove wrong at LICENSE_FABRIC.
> 2) JCache changed the license to Apache 2.0 
> (https://raw.githubusercontent.com/jsr107/jsr107spec/master/LICENSE.txt). 
> Content of {{ignite-core-licenses.txt}} mustn't be mentioned there. JCache 
> has to be mentioned the file from 3)
> 3) Apache licenses should be always shown at ignite-*-licenses.txt.
> licenses.txt.vm should be fixed.
> 4)  Revert geronimo related changes merged into this branch. Geronimo is no 
> longer needed.



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

[jira] [Commented] (IGNITE-1495) Cache SQL query metadata index's fields have wrong register.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1495:


GitHub user skalashnikov opened a pull request:

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

IGNITE-1495 Uppercase index fields in metadata



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

$ git pull https://github.com/gridgain/apache-ignite ignite-1495

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

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


commit b184a5d6d19baea7eb572d7bed6ef679c52eea0a
Author: skalashnikov 
Date:   2017-01-27T17:15:48Z

IGNITE-1495 Uppercase index fields in metadata




> Cache SQL query metadata index's fields have wrong register.
> 
>
> Key: IGNITE-1495
> URL: https://issues.apache.org/jira/browse/IGNITE-1495
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.5.0.final
>Reporter: Vasiliy Sisko
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
> Attachments: #_IGNITE-1495_Test_for_index_s_fields.patch
>
>
> Index's fields should have register how in table fields (In upper case).



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

[jira] [Commented] (IGNITE-4589) Possible starvation during rebalancing for marshaller cache

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4589:
--

[~amashenkov]
Yes, it's make sense. Marshaller cache was removed for ignite-2.0 release and 
this issue not actual.

> Possible starvation during rebalancing for marshaller cache
> ---
>
> Key: IGNITE-4589
> URL: https://issues.apache.org/jira/browse/IGNITE-4589
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
>
> When Ignite processing supply messages (rebalancing) in marshaller threads 
> and calling marshaller cache from them, but responses also should be 
> proccessed in marshaller threadpool. It leads to starvation.
> {noformat}
> marshaller-cache-#26%test-node%" #117 prio=5 os_prio=0 tid=0x7f89e40c6000 
> nid=0x1dc waiting on condition [0x7f8a3fffc000]
>java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for <0xc206d318> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture)
>  at java.util.concurrent.locks.LockSupport.park(Unknown Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
>  Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown
>  Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown
>  Source)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getTopologySafe(GridCacheAdapter.java:1340)
>  at 
> org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:195)
>  at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:266)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:318)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:218)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1614)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1680)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
>  at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:298)
>  at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9722)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9751)
>  at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.unmarshal(IgniteCacheObjectProcessorImpl.java:111)
>  at 
> 

[jira] [Commented] (IGNITE-4444) Extend .NET plugin API to interact with Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-:


Java side already has a good API to use: {{PluginProvider.initExtensions()}}, 
which are available to us via {{IgnitePluginProcessor.extensions}}. This way 
many active plugins can each provide their instance of {{PlatformExtension}}. 
As long as ids are unique, there would be no conflicts.

> Extend .NET plugin API to interact with Java
> 
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugin authors should be able to interact with Java part of the plugin: call 
> .NET->Java and Java->.NET.



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

[jira] [Commented] (IGNITE-4302) Exchange binary metadata with discovery custom messages instead of system cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4302:
-

Refactored tests' code, implemented final version of test for node waiting 
on-going update case.

> Exchange binary metadata with discovery custom messages instead of system 
> cache
> ---
>
> Key: IGNITE-4302
> URL: https://issues.apache.org/jira/browse/IGNITE-4302
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> h4. Notes
> See [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] for more 
> details about context.
> h4. Acceptance Criteria
> # Binary metadata cache is deleted.
> # Binary metadata exchange is performed using *DiscoveryCustomMessage* events.



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

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3196:


GitHub user daradurvs opened a pull request:

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

IGNITE-3196

We shouldn't check sign at serialization, because the used approach:
BigInteger intVal = val.unscaledValue();
byte[] vals = intVal.toByteArray();
#toByteArray() - already including at least one sign bit, which is 
(ceil((this.bitLength() + 1)/8)). (This representation is compatible with the 
(byte[]) constructor.)

Therefore, at deserialization we just read  byte[] vals and scale, also we 
use default constructor which will define a sign from byte[] vals.


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

$ git pull https://github.com/daradurvs/ignite ignite-3196

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

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


commit 48fab04f4a8b48a1f6ff0a632d56075c855b62e5
Author: daradurvs 
Date:   2017-01-26T17:21:01Z

ignite-3196: serialization of BigDecimal is simplified

commit 91327c3797fb1ea8702cf8e2ce34998819c0c8c9
Author: daradurvs 
Date:   2017-01-27T09:50:32Z

ignite-3196: fix old serialization method (it is better, serialized object 
has the smaller size)

commit f3d2297d9db4e773003eeea800ae37843ce79f14
Author: daradurvs 
Date:   2017-01-27T11:48:53Z

ignite-3196: "negative scale with RoundingMode" tests are added




> Marshaling works wrong for the BigDecimals that have negative scale
> ---
>
> Key: IGNITE-3196
> URL: https://issues.apache.org/jira/browse/IGNITE-3196
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Current marshalling procedure of the {{BigDecimal}} assumes that the scale of 
> the {{BigDecimal}} value is always more than or equal to zero. However, scale 
> [can be 
> negative|https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#scale()].
> This leads to invalid results if we try to marshal-unmarshal {{BigDecimal}} 
> that has a negative scale.



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

[jira] [Comment Edited] (IGNITE-4558) Use BinaryArrayIdentityResolver by default

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev edited comment on IGNITE-4558 at 1/27/17 2:27 PM:


Done. [~vozerov], please review


was (Author: ezhuravl):
Done. [~vozerov]], please review

> Use BinaryArrayIdentityResolver by default
> --
>
> Key: IGNITE-4558
> URL: https://issues.apache.org/jira/browse/IGNITE-4558
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Reporter: Pavel Tupitsyn
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.0
>
>
> Currently if there is no configured 
> {{BinaryTypeConfiguration.IdentityResolver}}, we call Object.hashCode().
> This is not consistent with DML, and there is a warning:
> {code}
> Binary object's type does not have identity resolver explicitly set, 
> therefore BinaryArrayIdentityResolver is used to generate hash codes for its 
> instances, and therefore hash code of this binary object will most likely not 
> match that of its non serialized form. For finer control over identity of 
> this type, please update your BinaryConfiguration accordingly.
> {code}
> In 2.0 we should use {{BinaryArrayIdentityResolver}} by default.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Commented] (IGNITE-4558) Use BinaryArrayIdentityResolver by default

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev commented on IGNITE-4558:
---

Done. [~vozerov]], please review

> Use BinaryArrayIdentityResolver by default
> --
>
> Key: IGNITE-4558
> URL: https://issues.apache.org/jira/browse/IGNITE-4558
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Reporter: Pavel Tupitsyn
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.0
>
>
> Currently if there is no configured 
> {{BinaryTypeConfiguration.IdentityResolver}}, we call Object.hashCode().
> This is not consistent with DML, and there is a warning:
> {code}
> Binary object's type does not have identity resolver explicitly set, 
> therefore BinaryArrayIdentityResolver is used to generate hash codes for its 
> instances, and therefore hash code of this binary object will most likely not 
> match that of its non serialized form. For finer control over identity of 
> this type, please update your BinaryConfiguration accordingly.
> {code}
> In 2.0 we should use {{BinaryArrayIdentityResolver}} by default.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Created] (IGNITE-4625) .NET: MixedClusterTest leaves Java-only node running

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4625:
--

 Summary: .NET: MixedClusterTest leaves Java-only node running
 Key: IGNITE-4625
 URL: https://issues.apache.org/jira/browse/IGNITE-4625
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.9


MixedClusterTest causes consequent tests to fail in some situations because it 
leaves java-only "grid2" node running. Looks like ExecuteJavaTask does not stop 
node properly.



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

[jira] [Issue Comment Deleted] (IGNITE-4552) Optimize GridDhtLocalPartition.rmvQueue

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4552:
---
Comment: was deleted

(was: origin_1node
!Plot_ThroughputLatencyProbe_01_origin_1node.png|origin_1node!

ignite-4552_1node
!Plot_ThroughputLatencyProbe_01_mine_1node.png|mine_1node!

origin_3node
!Plot_ThroughputLatencyProbe_01_origin_3node.png|origin_3node!

ignite-4552_3node
!Plot_ThroughputLatencyProbe_01_mine_3node.png|mine_3node!)

> Optimize GridDhtLocalPartition.rmvQueue
> ---
>
> Key: IGNITE-4552
> URL: https://issues.apache.org/jira/browse/IGNITE-4552
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 2.0
>
> Attachments: benchmark-put-remove-simultaneously.properties, 
> Plot_ThroughputLatencyProbe_01_mine_1node.png, 
> Plot_ThroughputLatencyProbe_01_mine_3node.png, 
> Plot_ThroughputLatencyProbe_01_origin_1node.png, 
> Plot_ThroughputLatencyProbe_01_origin_3node.png, 
> Screenshot_20170124_155355.png
>
>
> Current implementation stores deferred entry removals in rmvQueue for 
> consistency guaranties.
> This can lead to significant heap over-usage(I observed several Gbs) in case 
> of many caches with removals, because currently queue is cleared lazily after 
> reaching max capacity(200_000 by default).
> This can be mitigated by using lower IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE, 
> but can lead to consistency issues in case of frequent cache updates.
> Possible optimizations:
> * Use single fixed size queue per all caches to overcome limitations of 
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE workaround.
> * Do queue cleaning in background
> * Move queue to an off-heap.



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

[jira] [Commented] (IGNITE-4552) Optimize GridDhtLocalPartition.rmvQueue

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-4552:


origin_1node
!Plot_ThroughputLatencyProbe_01_origin_1node.png|origin_1node!

ignite-4552_1node
!Plot_ThroughputLatencyProbe_01_mine_1node.png|mine_1node!

origin_3node
!Plot_ThroughputLatencyProbe_01_origin_3node.png|origin_3node!

ignite-4552_3node
!Plot_ThroughputLatencyProbe_01_mine_3node.png|mine_3node!

> Optimize GridDhtLocalPartition.rmvQueue
> ---
>
> Key: IGNITE-4552
> URL: https://issues.apache.org/jira/browse/IGNITE-4552
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 2.0
>
> Attachments: benchmark-put-remove-simultaneously.properties, 
> Plot_ThroughputLatencyProbe_01_mine_1node.png, 
> Plot_ThroughputLatencyProbe_01_mine_3node.png, 
> Plot_ThroughputLatencyProbe_01_origin_1node.png, 
> Plot_ThroughputLatencyProbe_01_origin_3node.png, 
> Screenshot_20170124_155355.png
>
>
> Current implementation stores deferred entry removals in rmvQueue for 
> consistency guaranties.
> This can lead to significant heap over-usage(I observed several Gbs) in case 
> of many caches with removals, because currently queue is cleared lazily after 
> reaching max capacity(200_000 by default).
> This can be mitigated by using lower IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE, 
> but can lead to consistency issues in case of frequent cache updates.
> Possible optimizations:
> * Use single fixed size queue per all caches to overcome limitations of 
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE workaround.
> * Do queue cleaning in background
> * Move queue to an off-heap.



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

[jira] [Commented] (IGNITE-4552) Optimize GridDhtLocalPartition.rmvQueue

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-4552:


origin_1node
!Plot_ThroughputLatencyProbe_01_origin_1node.png|origin_1node!

ignite-4552_1node
!Plot_ThroughputLatencyProbe_01_mine_1node.png|mine_1node!

origin_3node
!Plot_ThroughputLatencyProbe_01_origin_3node.png|origin_3node!

ignite-4552_3node
!Plot_ThroughputLatencyProbe_01_mine_3node.png|mine_3node!

> Optimize GridDhtLocalPartition.rmvQueue
> ---
>
> Key: IGNITE-4552
> URL: https://issues.apache.org/jira/browse/IGNITE-4552
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 2.0
>
> Attachments: benchmark-put-remove-simultaneously.properties, 
> Plot_ThroughputLatencyProbe_01_mine_1node.png, 
> Plot_ThroughputLatencyProbe_01_mine_3node.png, 
> Plot_ThroughputLatencyProbe_01_origin_1node.png, 
> Plot_ThroughputLatencyProbe_01_origin_3node.png, 
> Screenshot_20170124_155355.png
>
>
> Current implementation stores deferred entry removals in rmvQueue for 
> consistency guaranties.
> This can lead to significant heap over-usage(I observed several Gbs) in case 
> of many caches with removals, because currently queue is cleared lazily after 
> reaching max capacity(200_000 by default).
> This can be mitigated by using lower IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE, 
> but can lead to consistency issues in case of frequent cache updates.
> Possible optimizations:
> * Use single fixed size queue per all caches to overcome limitations of 
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE workaround.
> * Do queue cleaning in background
> * Move queue to an off-heap.



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

[jira] [Updated] (IGNITE-4552) Optimize GridDhtLocalPartition.rmvQueue

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4552:
---
Attachment: Plot_ThroughputLatencyProbe_01_mine_1node.png
Plot_ThroughputLatencyProbe_01_origin_1node.png
benchmark-put-remove-simultaneously.properties
Plot_ThroughputLatencyProbe_01_origin_3node.png
Plot_ThroughputLatencyProbe_01_mine_3node.png

> Optimize GridDhtLocalPartition.rmvQueue
> ---
>
> Key: IGNITE-4552
> URL: https://issues.apache.org/jira/browse/IGNITE-4552
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 2.0
>
> Attachments: benchmark-put-remove-simultaneously.properties, 
> Plot_ThroughputLatencyProbe_01_mine_1node.png, 
> Plot_ThroughputLatencyProbe_01_mine_3node.png, 
> Plot_ThroughputLatencyProbe_01_origin_1node.png, 
> Plot_ThroughputLatencyProbe_01_origin_3node.png, 
> Screenshot_20170124_155355.png
>
>
> Current implementation stores deferred entry removals in rmvQueue for 
> consistency guaranties.
> This can lead to significant heap over-usage(I observed several Gbs) in case 
> of many caches with removals, because currently queue is cleared lazily after 
> reaching max capacity(200_000 by default).
> This can be mitigated by using lower IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE, 
> but can lead to consistency issues in case of frequent cache updates.
> Possible optimizations:
> * Use single fixed size queue per all caches to overcome limitations of 
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE workaround.
> * Do queue cleaning in background
> * Move queue to an off-heap.



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

[jira] [Commented] (IGNITE-4571) Optimize futVer generations

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4571:
---

Yakov,

I've done recommended modifications, please review.

> Optimize futVer generations
> ---
>
> Key: IGNITE-4571
> URL: https://issues.apache.org/jira/browse/IGNITE-4571
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
>
> 1. Optimize futVer generations - need to get rid of using CacheVersion in 
> favor of long value.
> Example
> org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateFuture.java:633
> org.apache.ignite.internal.processors.cache.version.GridCacheVersionManager#next(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)
> Result:
> Need to replace cache version with random long (int), check compatibility and 
> messages sizes before & after and benchmark.
> How:
> Use thread local random. Generate ID on atomic future store and switch it to 
> putIfAbsent().



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

[jira] [Assigned] (IGNITE-4589) Possible starvation during rebalancing for marshaller cache

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-4589:


Assignee: Nikolay Tikhonov

> Possible starvation during rebalancing for marshaller cache
> ---
>
> Key: IGNITE-4589
> URL: https://issues.apache.org/jira/browse/IGNITE-4589
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
>
> When Ignite processing supply messages (rebalancing) in marshaller threads 
> and calling marshaller cache from them, but responses also should be 
> proccessed in marshaller threadpool. It leads to starvation.
> {noformat}
> marshaller-cache-#26%test-node%" #117 prio=5 os_prio=0 tid=0x7f89e40c6000 
> nid=0x1dc waiting on condition [0x7f8a3fffc000]
>java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for <0xc206d318> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture)
>  at java.util.concurrent.locks.LockSupport.park(Unknown Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
>  Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown
>  Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown
>  Source)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getTopologySafe(GridCacheAdapter.java:1340)
>  at 
> org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:195)
>  at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:266)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:318)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:218)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1614)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1680)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
>  at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:298)
>  at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9722)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9751)
>  at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.unmarshal(IgniteCacheObjectProcessorImpl.java:111)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.unmarshal(CacheObjectBinaryProcessorImpl.java:811)
>  at 
> 

[jira] [Updated] (IGNITE-4624) ScanQuery shows poor performance.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4624:
-
Attachment: Demo.java

> ScanQuery shows poor performance.
> -
>
> Key: IGNITE-4624
> URL: https://issues.apache.org/jira/browse/IGNITE-4624
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
> Attachments: 
> Change_keyIterator_to_entryIterator_for_local_scan_squery.patch, Demo.java
>
>
> I've found that ScanQuery use cache KeySet iterator which make cache 
> peek\entry calls for getting value.
> It is look like we can avoid this calls by using EntrySet iterator for 
> iterating over local partitions.
> Start point is GridCacheQueryManager.onheapIterator(). 



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

[jira] [Comment Edited] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-2356 at 1/27/17 1:02 PM:
---

1. We have to use remote node to check both {{InProc, Client}} modes for 
{{HadoopIgfsWrapper}}. e.g. {{InProc}} mode is default and client node is 
started never if the ignite node available at the same process.

2. Sure. The concurrency with {{synchronized}} become simpler then with 
lock-free (*Fixed*).

[Tests|http://195.239.208.174/project.html?projectId=IgniteTests_IgniteTests=pull%2F1251%2Fhead]
 are re-run


was (Author: tledkov-gridgain):
1. We have to use remote node to check both {{InProc, Client}} modes for 
{{HadoopIgfsWrapper}}. e.g. {{InProc}} mode is default and client node is 
started never if the ignite node available at the same process.

2. Sure. The concurrency with {{synchronized}} become simpler then with 
lock-free (*Fixed*).

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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

[jira] [Commented] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-1948:
-


I found a lot of using "ClusterTopologyCheckedException" exception. In most 
use-case these exceptions were just ignored. It's easier to see if issue-4612 
will be applied (I'm waiting for code review by my team leader) where I renamed 
all unused exceptions in the "ignored".

It means that in most case "retryReadyFuture" can left unset. But there are 
code where exception is being getting from "get()" method in some "future" 
class and don't ignored (exception is sending to method 
"GridFutureAdapter#onDone()" for example).

So I decided not to do a deep global analysis of code and make some simple 
rules.
1. If some method "X" throws ClusterTopologyCheckedException and ignores it (or 
converts to String, there are some variants to lose exception like object) in 
all methods that call the method "X", then we can don't set  "retryReadyFuture" 
for optimization. But this should be clarified in javadoc.
2. But if exception escapes at least once like object: we must set 
"retryReadyFuture" in that method.

A few times  when call tree was simple, I went deeper.

So I found three methods which can throw "ClusterTopologyCheckedException" 
without setting "retryReadyFuture":

1. IgfsFragmentizerManager#sendWithRetries(UUID nodeId, 
IgfsCommunicationMessage msg)
2. GridCacheIoManager#sendNoRetry(ClusterNode node, GridCacheMessage msg, byte 
plc)
3. GridCacheIoManager#sendOrderedMessage(ClusterNode node, Object topic, 
GridCacheMessage msg, byte plc, long timeout)

In all other methods "ClusterTopologyCheckedException" escapes away too far.

What do you think about this approach to make compromise between optimization 
and correctness?

> ClusterTopologyCheckedException can return null for retryReadyFuture()
> --
>
> Key: IGNITE-1948
> URL: https://issues.apache.org/jira/browse/IGNITE-1948
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Denis Magda
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> It was noted that {{ClusterTopologyCheckedException}} ready future can be 
> null.
> Go though all the places where this kind of exception is being initialized 
> and check why the ready future is not set in some cases.



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

[jira] [Updated] (IGNITE-4624) ScanQuery shows poor performance.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4624:
-
Attachment: Change_keyIterator_to_entryIterator_for_local_scan_squery.patch

I've make a simple fix and get a 30% speed up with iterating over partitions 
with ScanQuery.

Fix is not complete as it does not affect OffHeap cache and not bothered  with 
transactions.

> ScanQuery shows poor performance.
> -
>
> Key: IGNITE-4624
> URL: https://issues.apache.org/jira/browse/IGNITE-4624
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
> Attachments: 
> Change_keyIterator_to_entryIterator_for_local_scan_squery.patch
>
>
> I've found that ScanQuery use cache KeySet iterator which make cache 
> peek\entry calls for getting value.
> It is look like we can avoid this calls by using EntrySet iterator for 
> iterating over local partitions.
> Start point is GridCacheQueryManager.onheapIterator(). 



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

[jira] [Commented] (IGNITE-4590) Lock/unlock operations are hanging when topology changed

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4590:
--

Looks the changes fixed IGNITE-2204 issue.

> Lock/unlock operations are hanging when topology changed
> 
>
> Key: IGNITE-4590
> URL: https://issues.apache.org/jira/browse/IGNITE-4590
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
>Priority: Critical
> Attachments: 4590-test.patch
>
>
> Lock/unlock operations are hanging when topology changed. See attached test.



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

[jira] [Comment Edited] (IGNITE-4590) Lock/unlock operations are hanging when topology changed

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-4590 at 1/27/17 11:45 AM:


Looks the changes should fix IGNITE-2204 issue.


was (Author: ntikhonov):
Looks the changes fixed IGNITE-2204 issue.

> Lock/unlock operations are hanging when topology changed
> 
>
> Key: IGNITE-4590
> URL: https://issues.apache.org/jira/browse/IGNITE-4590
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
>Priority: Critical
> Attachments: 4590-test.patch
>
>
> Lock/unlock operations are hanging when topology changed. See attached test.



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

[jira] [Commented] (IGNITE-3385) Improve schema import utility

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3385:
--

I think it is better implement this functionality in Web Console.

> Improve schema import utility
> -
>
> Key: IGNITE-3385
> URL: https://issues.apache.org/jira/browse/IGNITE-3385
> Project: Ignite
>  Issue Type: Bug
>  Components: general, wizards
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> It would be useful to add more code generation capabilities to
> schema import utility to reduce amount of hand-written boilerplate code.
> * Affinity key mapping
> * SQL query fields and indexes



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

[jira] [Updated] (IGNITE-3385) Improve schema import utility

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-3385:
-
Component/s: wizards

> Improve schema import utility
> -
>
> Key: IGNITE-3385
> URL: https://issues.apache.org/jira/browse/IGNITE-3385
> Project: Ignite
>  Issue Type: Bug
>  Components: general, wizards
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> It would be useful to add more code generation capabilities to
> schema import utility to reduce amount of hand-written boilerplate code.
> * Affinity key mapping
> * SQL query fields and indexes



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

[jira] [Updated] (IGNITE-3385) Improve schema import utility

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-3385:
-
Labels:   (was: newbie)

> Improve schema import utility
> -
>
> Key: IGNITE-3385
> URL: https://issues.apache.org/jira/browse/IGNITE-3385
> Project: Ignite
>  Issue Type: Bug
>  Components: general, wizards
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> It would be useful to add more code generation capabilities to
> schema import utility to reduce amount of hand-written boilerplate code.
> * Affinity key mapping
> * SQL query fields and indexes



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

[jira] [Commented] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-3542:
-

Vladimir, these failures happen because the build ran on a Windows agent. 
Similar failures can be observed on pure "ignite-2.0" branch : 
http://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests_IgniteGgfs=buildTypeStatusDiv_IgniteTests=ignite-2.0
 .
We created https://issues.apache.org/jira/browse/IGNITE-4623 to address that -- 
these failures are not related to the changes discussed in this ticket.


> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 1.9
>
>
> If integrity check failed, it means that some concurrent file system update 
> occurred. We should always perform re-try in this case.



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

[jira] [Updated] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-3542:

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.9
>
>
> If integrity check failed, it means that some concurrent file system update 
> occurred. We should always perform re-try in this case.



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

[jira] [Resolved] (IGNITE-4567) Design and implement means for distributed DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4567.
-
Resolution: Won't Fix

> Design and implement means for distributed DDL statements
> -
>
> Key: IGNITE-4567
> URL: https://issues.apache.org/jira/browse/IGNITE-4567
> Project: Ignite
>  Issue Type: Sub-task
>  Components: messaging, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> We need some kind of common way to handle stuff like CREATE INDEX/CREATE 
> TABLE statements - in other words, run potentially long-running (and possibly 
> cache locking) DDL operations on cluster nodes that would allow using new 
> tables/indexes only when all nodes have performed requested operations and 
> data modifications.



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

[jira] [Updated] (IGNITE-4621) Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4621:
-
Priority: Critical  (was: Major)

> Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true
> --
>
> Key: IGNITE-4621
> URL: https://issues.apache.org/jira/browse/IGNITE-4621
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
>
> Reproducer:
> {noformat}
> assert BinaryUtils.FIELDS_SORTED_ORDER; // should be set by ENV 
> variable.
> startGrids(GRIDS);
> //awaitPartitionMapExchange();
> Ignite ignite = grid(0);
> ignite.compute(ignite.cluster().forServers()).broadcast(new 
> JustAnotherCallable()); // hang here
> stopAllGrids();
> {noformat}
> where cache configuration is 
> {noformat}
> ...
> cfg.setMarshaller(new BinaryMarshaller());
> final BinaryConfiguration binaryCfg = new BinaryConfiguration();
> binaryCfg.setCompactFooter(false);
> cfg.setBinaryConfiguration(binaryCfg);
> ...
> {noformat}
> Stacktrace:
> {noformat}
>   - parking to wait for  <0x00076fce15c8> (a 
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:158)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2369)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4385)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2326)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1814)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:585)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$3.addMeta(CacheObjectBinaryProcessorImpl.java:218)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1215)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:753)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:200)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:459)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1092)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:623)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:782)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:239)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:83)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> 

[jira] [Updated] (IGNITE-4567) Design and implement means for distributed DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4567:

Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-4565)

> Design and implement means for distributed DDL statements
> -
>
> Key: IGNITE-4567
> URL: https://issues.apache.org/jira/browse/IGNITE-4567
> Project: Ignite
>  Issue Type: Task
>  Components: messaging, SQL
>Reporter: Alexander Paschenko
> Fix For: 1.9
>
>
> We need some kind of common way to handle stuff like CREATE INDEX/CREATE 
> TABLE statements - in other words, run potentially long-running (and possibly 
> cache locking) DDL operations on cluster nodes that would allow using new 
> tables/indexes only when all nodes have performed requested operations and 
> data modifications.



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

[jira] [Closed] (IGNITE-4567) Design and implement means for distributed DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4567.
---

> Design and implement means for distributed DDL statements
> -
>
> Key: IGNITE-4567
> URL: https://issues.apache.org/jira/browse/IGNITE-4567
> Project: Ignite
>  Issue Type: Sub-task
>  Components: messaging, SQL
>Reporter: Alexander Paschenko
> Fix For: 1.9
>
>
> We need some kind of common way to handle stuff like CREATE INDEX/CREATE 
> TABLE statements - in other words, run potentially long-running (and possibly 
> cache locking) DDL operations on cluster nodes that would allow using new 
> tables/indexes only when all nodes have performed requested operations and 
> data modifications.



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

[jira] [Commented] (IGNITE-4492) Add MBean for StripedExecutor

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-4492:
--

working

> Add MBean for StripedExecutor
> -
>
> Key: IGNITE-4492
> URL: https://issues.apache.org/jira/browse/IGNITE-4492
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Yakov Zhdanov
>Priority: Minor
>  Labels: newbie
> Fix For: 2.0
>
>
> # Add MBean interface and implementation as we have for 
> org.apache.ignite.internal.ThreadPoolMXBeanAdapter
> # Register MBean together with other pools MBeans
> # Unregister MBean on Ignite stop.



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

[jira] [Commented] (IGNITE-4105) Create separate thread pool for SQL queries.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-4105:


[~vozerov], please take a look

> Create separate thread pool for SQL queries.
> 
>
> Key: IGNITE-4105
> URL: https://issues.apache.org/jira/browse/IGNITE-4105
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.0
>
>
> If several long-running queries are executed, all concurrent cache operations 
> will be blocked because there will be no threads in system pool to server 
> cache requests/responses.
> Let's introduce separate thread pool for SQL queries execution.



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

[jira] [Created] (IGNITE-4623) IGFS test suite should run successfully on Windows agents

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-4623:
---

 Summary: IGFS test suite should run successfully on Windows agents
 Key: IGNITE-4623
 URL: https://issues.apache.org/jira/browse/IGNITE-4623
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Veselovsky
Assignee: Taras Ledkov


Currently on Windows agents (*_*_*_9090) there are ~560 failures related to 
local file system behavior difference on Windows systems.
E.g. see 1.8.3: 
http://ci.ignite.apache.org/viewLog.html?buildId=435288=buildResultsDiv=IgniteTests_IgniteGgfs
 
2.0: 
http://ci.ignite.apache.org/viewLog.html?buildId=435289=buildResultsDiv=IgniteTests_IgniteGgfs
 .

Most of the failures are caused by NPE in 
org.apache.ignite.igfs.secondary.local.LocalIgfsSecondaryFileSystem#info (line 
370).



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

[jira] [Assigned] (IGNITE-4621) Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-4621:


Assignee: Anton Vinogradov

> Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true
> --
>
> Key: IGNITE-4621
> URL: https://issues.apache.org/jira/browse/IGNITE-4621
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>
> Reproducer:
> {noformat}
> assert BinaryUtils.FIELDS_SORTED_ORDER; // should be set by ENV 
> variable.
> startGrids(GRIDS);
> //awaitPartitionMapExchange();
> Ignite ignite = grid(0);
> ignite.compute(ignite.cluster().forServers()).broadcast(new 
> JustAnotherCallable()); // hang here
> stopAllGrids();
> {noformat}
> where cache configuration is 
> {noformat}
> ...
> cfg.setMarshaller(new BinaryMarshaller());
> final BinaryConfiguration binaryCfg = new BinaryConfiguration();
> binaryCfg.setCompactFooter(false);
> cfg.setBinaryConfiguration(binaryCfg);
> ...
> {noformat}
> Stacktrace:
> {noformat}
>   - parking to wait for  <0x00076fce15c8> (a 
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:158)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2369)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4385)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2326)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1814)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:585)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$3.addMeta(CacheObjectBinaryProcessorImpl.java:218)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1215)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:753)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:200)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:459)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1092)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:623)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:782)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:239)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:83)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:9861)
>   at 
> 

[jira] [Updated] (IGNITE-4566) Introduce IgniteCacheEx.createQueryIndex

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4566:

Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-4565)

> Introduce IgniteCacheEx.createQueryIndex
> 
>
> Key: IGNITE-4566
> URL: https://issues.apache.org/jira/browse/IGNITE-4566
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Resolved] (IGNITE-4566) Introduce IgniteCacheEx.createQueryIndex

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4566.
-
Resolution: Won't Fix

> Introduce IgniteCacheEx.createQueryIndex
> 
>
> Key: IGNITE-4566
> URL: https://issues.apache.org/jira/browse/IGNITE-4566
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Closed] (IGNITE-4566) Introduce IgniteCacheEx.createQueryIndex

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4566.
---
Assignee: (was: Alexander Paschenko)

> Introduce IgniteCacheEx.createQueryIndex
> 
>
> Key: IGNITE-4566
> URL: https://issues.apache.org/jira/browse/IGNITE-4566
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Assigned] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4575:
---

Assignee: Vladimir Ozerov  (was: Alexander Paschenko)

> Implement in Ignite wrapper for enums based on H2 user value type
> -
>
> Key: IGNITE-4575
> URL: https://issues.apache.org/jira/browse/IGNITE-4575
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
> Fix For: 1.9
>
>




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

[jira] [Updated] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4575:

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

> Implement in Ignite wrapper for enums based on H2 user value type
> -
>
> Key: IGNITE-4575
> URL: https://issues.apache.org/jira/browse/IGNITE-4575
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Updated] (IGNITE-4268) Allow UPDATEs of the key and its fields in DML statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4268:

Priority: Major  (was: Minor)

> Allow UPDATEs of the key and its fields in DML statements
> -
>
> Key: IGNITE-4268
> URL: https://issues.apache.org/jira/browse/IGNITE-4268
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> Initial DML implementation does not allow to UPDATE columns that correspond 
> to key or its fields - direct modification would probably damage the index as 
> well as hash map integrity, so UPDATE for such cases would need to do first 
> {{remove}}, then {{put}}.
> In the course of review, it has been agreed that this feature will be 
> implemented in later releases shortly to deliver initial implementation on 
> time.



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

[jira] [Updated] (IGNITE-4268) Allow UPDATEs of the key and its fields in DML statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4268:

Assignee: (was: Alexander Paschenko)

> Allow UPDATEs of the key and its fields in DML statements
> -
>
> Key: IGNITE-4268
> URL: https://issues.apache.org/jira/browse/IGNITE-4268
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Priority: Minor
> Fix For: 2.0
>
>
> Initial DML implementation does not allow to UPDATE columns that correspond 
> to key or its fields - direct modification would probably damage the index as 
> well as hash map integrity, so UPDATE for such cases would need to do first 
> {{remove}}, then {{put}}.
> In the course of review, it has been agreed that this feature will be 
> implemented in later releases shortly to deliver initial implementation on 
> time.



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

[jira] [Updated] (IGNITE-4268) Allow UPDATEs of the key and its fields in DML statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4268:

Priority: Minor  (was: Major)

> Allow UPDATEs of the key and its fields in DML statements
> -
>
> Key: IGNITE-4268
> URL: https://issues.apache.org/jira/browse/IGNITE-4268
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>Priority: Minor
> Fix For: 2.0
>
>
> Initial DML implementation does not allow to UPDATE columns that correspond 
> to key or its fields - direct modification would probably damage the index as 
> well as hash map integrity, so UPDATE for such cases would need to do first 
> {{remove}}, then {{put}}.
> In the course of review, it has been agreed that this feature will be 
> implemented in later releases shortly to deliver initial implementation on 
> time.



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

[jira] [Updated] (IGNITE-4490) Optimize DML for fast INSERT and MERGE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4490:

Fix Version/s: (was: 1.9)
   2.0

> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE 
> statements to cache operations in a way similar to that of UPDATE and DELETE 
> - i.e. don't make queries when there are no expressions to evaluate in the 
> query and enhance update plans to perform direct cache operations when INSERT 
> and MERGE affect columns {{_key}} and {{_val}} only.



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

[jira] [Assigned] (IGNITE-3793) Need to fix dependencies and it's licenses.

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov reassigned IGNITE-3793:


Assignee: Alexandr Fedotov

> Need to fix dependencies and it's licenses.
> ---
>
> Key: IGNITE-3793
> URL: https://issues.apache.org/jira/browse/IGNITE-3793
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Alexandr Fedotov
>Priority: Blocker
>  Labels: important
> Fix For: 1.9
>
>
> 1) H2 license listed at LICENSE_FABRIC seems to be wrong.
> Need to make sure that correct one listed at ignite-indexing-licenses.txt and 
> remove wrong at LICENSE_FABRIC.
> 2) JCache changed the license to Apache 2.0 
> (https://raw.githubusercontent.com/jsr107/jsr107spec/master/LICENSE.txt). 
> Content of {{ignite-core-licenses.txt}} mustn't be mentioned there. JCache 
> has to be mentioned the file from 3)
> 3) Apache licenses should be always shown at ignite-*-licenses.txt.
> licenses.txt.vm should be fixed.
> 4)  Revert geronimo related changes merged into this branch. Geronimo is no 
> longer needed.



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

[jira] [Commented] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-2356:
--

1. We have to use remote node to check both {{InProc, Client}} modes for 
{{HadoopIgfsWrapper}}. e.g. {{InProc}} mode is default and client node is 
started never if the ignite node available at the same process.

2. Sure. The concurrency with {{synchronized}} become simpler then with 
lock-free (*Fixed*).

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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

[jira] [Updated] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4565:

Component/s: (was: messaging)

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Updated] (IGNITE-4105) Create separate thread pool for SQL queries.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4105:

Assignee: Sergey Kalashnikov  (was: Andrew Mashenkov)

> Create separate thread pool for SQL queries.
> 
>
> Key: IGNITE-4105
> URL: https://issues.apache.org/jira/browse/IGNITE-4105
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>Priority: Critical
> Fix For: 2.0
>
>
> If several long-running queries are executed, all concurrent cache operations 
> will be blocked because there will be no threads in system pool to server 
> cache requests/responses.
> Let's introduce separate thread pool for SQL queries execution.



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

[jira] [Comment Edited] (IGNITE-4105) Create separate thread pool for SQL queries.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4105 at 1/27/17 9:19 AM:
--

Sergey, my comments:
1) Test was not reliable - relying to thread name is bad practice. I reworked 
it to policy checks.
2) Please remove {{sql}} prefix. We creating pool for queries, not for SQL 
queries.
3) {{IgniteSqlQueryDedicatedPoolTest}} is not added to query suite.


was (Author: vozerov):
Andrew, my comments:
1) Test was not reliable - relying to thread name is bad practice. I reworked 
it to policy checks.
2) Please remove {{sql}} prefix. We creating pool for queries, not for SQL 
queries.
3) {{IgniteSqlQueryDedicatedPoolTest}} is not added to query suite.

> Create separate thread pool for SQL queries.
> 
>
> Key: IGNITE-4105
> URL: https://issues.apache.org/jira/browse/IGNITE-4105
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>Priority: Critical
> Fix For: 2.0
>
>
> If several long-running queries are executed, all concurrent cache operations 
> will be blocked because there will be no threads in system pool to server 
> cache requests/responses.
> Let's introduce separate thread pool for SQL queries execution.



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

[jira] [Commented] (IGNITE-4558) Use BinaryArrayIdentityResolver by default

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev commented on IGNITE-4558:
---

Hashcode setted to BinaryObject overwriting with hashcode from 
BinaryTypeConfiguration.IdentityResolver, if it exists. Need to fix it

> Use BinaryArrayIdentityResolver by default
> --
>
> Key: IGNITE-4558
> URL: https://issues.apache.org/jira/browse/IGNITE-4558
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Reporter: Pavel Tupitsyn
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.0
>
>
> Currently if there is no configured 
> {{BinaryTypeConfiguration.IdentityResolver}}, we call Object.hashCode().
> This is not consistent with DML, and there is a warning:
> {code}
> Binary object's type does not have identity resolver explicitly set, 
> therefore BinaryArrayIdentityResolver is used to generate hash codes for its 
> instances, and therefore hash code of this binary object will most likely not 
> match that of its non serialized form. For finer control over identity of 
> this type, please update your BinaryConfiguration accordingly.
> {code}
> In 2.0 we should use {{BinaryArrayIdentityResolver}} by default.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Comment Edited] (IGNITE-4214) "Failed to wait for partition map exchange" warnings during different load tests

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova edited comment on IGNITE-4214 at 1/27/17 9:05 AM:
--

"Failed to wait for partition map exchange"  and "Failed to wait for partition 
release future" are reproduced during failover test with the following config:
Benchmark: CacheRandomOperation
Operations: put, put_all, get, get_all, invoke, invoke_all, remove, remove_all, 
put_if_absent, replace
Heap: 8Gb for servers, 4Gb for clients
4 clients, 12 servers
Number of caches: 12
Types of caches (atomicity mode): different (atomic, transactional)
Types of caches (tiered storage mode): different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
Types of caches (indexing): different (with and without indexes)
Types of caches (cache mode): partitioned
Backups count: 5
Restart option: first bunch of 4 servers are restarted one by one, when they 
return to grid the second bunch of 4 servers are restarted one by one and so on.
Corresponding Yardstick configs, property file and logs (all servers and one of 
the drivers) are attached.



was (Author: krybakova):
"Failed to wait for partition map exchange"  and "Failed to wait for partition 
release feature" are reproduced during failover test with the following config:
Benchmark: CacheRandomOperation
Operations: put, put_all, get, get_all, invoke, invoke_all, remove, remove_all, 
put_if_absent, replace
Heap: 8Gb for servers, 4Gb for clients
4 clients, 12 servers
Number of caches: 12
Types of caches (atomicity mode): different (atomic, transactional)
Types of caches (tiered storage mode): different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
Types of caches (indexing): different (with and without indexes)
Types of caches (cache mode): partitioned
Backups count: 5
Restart option: first bunch of 4 servers are restarted one by one, when they 
return to grid the second bunch of 4 servers are restarted one by one and so on.
Corresponding Yardstick configs, property file and logs (all servers and one of 
the drivers) are attached.


> "Failed to wait for partition map exchange" warnings during different load 
> tests
> 
>
> Key: IGNITE-4214
> URL: https://issues.apache.org/jira/browse/IGNITE-4214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: IGNITE-4214-failover-case.logs.zip, 
> IGNITE-4214.logs.zip, ignite-base-load-config.xml, run-load.properties, 
> run-load.xml
>
>
> "Failed to wait for partition map exchange" warnings appears during different 
> load tests. Grid doesn't hang though and operations are performed 
> successfully.
> Example of load test config:
> - Benchmark: CacheRandomOperation
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 12
>  Corresponding Yardstick configs and property file are attached.
> Some logs with the error are attached. Complete logs will be provided by 
> request.



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

[jira] [Comment Edited] (IGNITE-4214) "Failed to wait for partition map exchange" warnings during different load tests

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova edited comment on IGNITE-4214 at 1/27/17 9:04 AM:
--

"Failed to wait for partition map exchange"  and "Failed to wait for partition 
release feature" are reproduced during failover test with the following config:
Benchmark: CacheRandomOperation
Operations: put, put_all, get, get_all, invoke, invoke_all, remove, remove_all, 
put_if_absent, replace
Heap: 8Gb for servers, 4Gb for clients
4 clients, 12 servers
Number of caches: 12
Types of caches (atomicity mode): different (atomic, transactional)
Types of caches (tiered storage mode): different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
Types of caches (indexing): different (with and without indexes)
Types of caches (cache mode): partitioned
Backups count: 5
Restart option: first bunch of 4 servers are restarted one by one, when they 
return to grid the second bunch of 4 servers are restarted one by one and so on.
Corresponding Yardstick configs, property file and logs (all servers and one of 
the drivers) are attached.



was (Author: krybakova):
Reproduced during failover test with the following config:
Benchmark: CacheRandomOperation
Operations: put, put_all, get, get_all, invoke, invoke_all, remove, remove_all, 
put_if_absent, replace
Heap: 8Gb for servers, 4Gb for clients
4 clients, 12 servers
Number of caches: 12
Types of caches (atomicity mode): different (atomic, transactional)
Types of caches (tiered storage mode): different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
Types of caches (indexing): different (with and without indexes)
Types of caches (cache mode): partitioned
Backups count: 5
Restart option: first bunch of 4 servers are restarted one by one, when they 
return to grid the second bunch of 4 servers are restarted one by one and so on.
Corresponding Yardstick configs, property file and logs (all servers and one of 
the drivers) are attached.


> "Failed to wait for partition map exchange" warnings during different load 
> tests
> 
>
> Key: IGNITE-4214
> URL: https://issues.apache.org/jira/browse/IGNITE-4214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: IGNITE-4214-failover-case.logs.zip, 
> IGNITE-4214.logs.zip, ignite-base-load-config.xml, run-load.properties, 
> run-load.xml
>
>
> "Failed to wait for partition map exchange" warnings appears during different 
> load tests. Grid doesn't hang though and operations are performed 
> successfully.
> Example of load test config:
> - Benchmark: CacheRandomOperation
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 12
>  Corresponding Yardstick configs and property file are attached.
> Some logs with the error are attached. Complete logs will be provided by 
> request.



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

[jira] [Updated] (IGNITE-4214) "Failed to wait for partition map exchange" warnings during different load tests

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-4214:

Attachment: IGNITE-4214-failover-case.logs.zip

> "Failed to wait for partition map exchange" warnings during different load 
> tests
> 
>
> Key: IGNITE-4214
> URL: https://issues.apache.org/jira/browse/IGNITE-4214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: IGNITE-4214-failover-case.logs.zip, 
> IGNITE-4214.logs.zip, ignite-base-load-config.xml, run-load.properties, 
> run-load.xml
>
>
> "Failed to wait for partition map exchange" warnings appears during different 
> load tests. Grid doesn't hang though and operations are performed 
> successfully.
> Example of load test config:
> - Benchmark: CacheRandomOperation
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 12
>  Corresponding Yardstick configs and property file are attached.
> Some logs with the error are attached. Complete logs will be provided by 
> request.



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

[jira] [Commented] (IGNITE-4214) "Failed to wait for partition map exchange" warnings during different load tests

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova commented on IGNITE-4214:
-

Reproduced during failover test with the following config:
Benchmark: CacheRandomOperation
Operations: put, put_all, get, get_all, invoke, invoke_all, remove, remove_all, 
put_if_absent, replace
Heap: 8Gb for servers, 4Gb for clients
4 clients, 12 servers
Number of caches: 12
Types of caches (atomicity mode): different (atomic, transactional)
Types of caches (tiered storage mode): different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
Types of caches (indexing): different (with and without indexes)
Types of caches (cache mode): partitioned
Backups count: 5
Restart option: first bunch of 4 servers are restarted one by one, when they 
return to grid the second bunch of 4 servers are restarted one by one and so on.
Corresponding Yardstick configs, property file and logs (all servers and one of 
the drivers) are attached.


> "Failed to wait for partition map exchange" warnings during different load 
> tests
> 
>
> Key: IGNITE-4214
> URL: https://issues.apache.org/jira/browse/IGNITE-4214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: IGNITE-4214.logs.zip, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> "Failed to wait for partition map exchange" warnings appears during different 
> load tests. Grid doesn't hang though and operations are performed 
> successfully.
> Example of load test config:
> - Benchmark: CacheRandomOperation
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 12
>  Corresponding Yardstick configs and property file are attached.
> Some logs with the error are attached. Complete logs will be provided by 
> request.



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

[jira] [Assigned] (IGNITE-4473) Client should re-try connection attempt in case of concurrent network failure

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-4473:
---

Assignee: Dmitry Karachentsev

> Client should re-try connection attempt in case of concurrent network failure
> -
>
> Key: IGNITE-4473
> URL: https://issues.apache.org/jira/browse/IGNITE-4473
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> *Problem*
> Consider the following scenario:
> 1) Client started, but there are no servers, so it hangs somewhere inside 
> start routine.
> 2) Server appears, and discovery finishes successfully.
> 3) Nodes start talking to each other through communication SPI to finish 
> start process (e.g. to complete exchange).
> 4) But network glitch occurs and server becomes unreachable.
> *Expected behavior*
> Client disconnects and hangs waiting for reconnect.
> *Actual behavior*
> Client throws an exception and never tries to reconnect.



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