[jira] [Commented] (IGNITE-3700) CacheWriter implementations should remove updated entries from the input collection

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3700:
--

may be change ticket status ?

> CacheWriter implementations should remove updated entries from the input 
> collection
> ---
>
> Key: IGNITE-3700
> URL: https://issues.apache.org/jira/browse/IGNITE-3700
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
> Fix For: 2.0
>
>
> According to {{CacheWriter}} JavaDoc, bulk operations ({{writeAll}} and 
> {{deleteAll}}) should remove successful entries from the input collection:
> {code}
>* If this operation fails (by throwing an exception) after a partial 
> success,
>* the writer must remove any successfully written entries from the entries
>* collection so that the caching implementation knows what succeeded and 
> can
>* mutate the cache.
> {code}
> We properly handle this in the cache store manager and throw 
> {{CachePartialUpdateException}} with the list of keys not removed from the 
> original collection. However, the implementations provided by Ignite 
> ({{CacheStoreAdapter}}, {{CacheAbstractJdbcStore}}, etc.) ignore this and 
> simply iterate through entries without removing successful ones.
> Proper implementation should use {{Iterator}} and remove the entry after 
> successful update:
> {code}
> @Override public void writeAll(Collection> entries) throws CacheWriterException {
> Iterator it = 
> entries.iterator();
> while (it.hasNext()) {
> Cache.Entry entry = it.next();
> // Do actual write (can throw an exception).
> it.remove();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3885) .NET: Describe development process on Wiki

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3885:

Component/s: documentation

> .NET: Describe development process on Wiki
> --
>
> Key: IGNITE-3885
> URL: https://issues.apache.org/jira/browse/IGNITE-3885
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Prachi Garg
>Priority: Minor
>  Labels: .NET
> Fix For: 2.0
>
>
> Ignite wiki: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home
> Add .NET development process page:
> * Coding guidelines (naming conventions, etc)
> * Project structure
> * Code inspections, how to run locally and on TC
> * Test coverage
> * How to build (AnyCPU nuances, NuGet, embedded CPP part, Java, etc)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4369) ReentrantLock hangs on unlock when node is stopped.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-4369:
--

plz, actualize ticket status

> ReentrantLock hangs on unlock when node is stopped.
> ---
>
> Key: IGNITE-4369
> URL: https://issues.apache.org/jira/browse/IGNITE-4369
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Taras Ledkov
> Fix For: 2.0
>
>  Time Spent: 4m
>  Remaining Estimate: 0h
>
> The thread hangs on GridCacheLockImpl.unlock when other node is stopped.
> {code}
> at java.lang.Thread.yield(Native Method)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryRelease(GridCacheLockImpl.java:469)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1260)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl.unlock(GridCacheLockImpl.java:1296)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4534) Implement offheap eviction policies based on page memory

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-4534:
--

i've refactored eviction policies, so it might be helpful : 
https://github.com/voipp/ignite/pull/8/commits/48961834733d31bad6ec9ba9b642cea280ae04b3

> Implement offheap eviction policies based on page memory
> 
>
> Key: IGNITE-4534
> URL: https://issues.apache.org/jira/browse/IGNITE-4534
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
> Fix For: 2.0
>
>
> Since the internal structure of offheap storage has changed, we need to 
> re-implement Fifo, Lru and Sorted eviction policies



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4670) CPP: Implement LoadCache method

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4670:
-

Implemented {{LoadCache}} without predicates and added tests. Still need to 
implement {{LocalLoadCache}}.

> CPP: Implement LoadCache method
> ---
>
> Key: IGNITE-4670
> URL: https://issues.apache.org/jira/browse/IGNITE-4670
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Implement ability to load cache for C++ platform.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[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=15868216#comment-15868216
 ] 

Sergey Chugunov commented on IGNITE-4302:
-

Identified a bug with delivering continuous query handlers to new nodes on 
binary caches: keepBinary flag gets lost during the discovery process and next 
result delivered from the new node handled incorrectly.

> 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.15#6346)

[jira] [Comment Edited] (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=15868216#comment-15868216
 ] 

Sergey Chugunov edited comment on IGNITE-4302 at 2/15/17 5:30 PM:
--

Identified a bug with delivering continuous query handlers to new nodes on 
binary caches: *keepBinary* flag gets lost during the discovery process and 
next result delivered from the new node handled incorrectly.


was (Author: sergey-chugunov):
Identified a bug with delivering continuous query handlers to new nodes on 
binary caches: keepBinary flag gets lost during the discovery process and next 
result delivered from the new node handled incorrectly.

> 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.15#6346)

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4212:
-

[~oleg-ostanin], 

Please update the doc with this text below. I've edited it a bit.

*By default, all the necessary files will be automatically uploaded from the 
host in which you run the command above to every other host to the same path. 
If you prefer to do it manually set the AUTO_COPY variable in property file to 
`false`.*

//I've double checked project compilation and for me it worked fine. Sorry I 
did not mention it before. Please attach maven //building logs if you can.

I didn't build the project, I rather opened it with Intellij IDEA and Intellij 
IDEA showed me that it can't find these two methods

{code}
cc.setReadThrough(args.isStoreEnabled());
cc.setWriteThrough(args.isStoreEnabled());
{code}

> 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: 1.9
>
> Attachments: benchmark-remote.properties, 
> benchmark-remote-sample.properties, DEVNOTES.txt, ignite-remote-config.xml, 
> README.txt
>
>
> 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.15#6346)

[jira] [Commented] (IGNITE-1624) [Test failed] Ignite SPI: TcpClientDiscoverySpiSelfTest.testJoinError failed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1624:


GitHub user SharplEr opened a pull request:

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

IGNITE-1624 [not ready, just for testing]

Not ready. just for testing in CI.

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

$ git pull https://github.com/SharplEr/ignite ignite-1624

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

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


commit 4e38acf2757d76ed848adaa476aab0faba1a8fc0
Author: Alexander Menshikov 
Date:   2017-02-15T15:41:28Z

Add repeating to test




> [Test failed] Ignite SPI:  TcpClientDiscoverySpiSelfTest.testJoinError failed
> -
>
> Key: IGNITE-1624
> URL: https://issues.apache.org/jira/browse/IGNITE-1624
> Project: Ignite
>  Issue Type: Test
>Reporter: Andrey Gura
>Assignee: Alexander Menshikov
>Priority: Critical
>  Labels: Muted_test
> Fix For: 2.0
>
>
> The following test periodically fail on TC:
>  * {{TcpClientDiscoverySpiSelfTest.testJoinError}}
>  * {{TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinError}}
> {noformat}
> [18:07:52,332][ERROR][test-runner][IgniteKernal%client-0] Got exception while 
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:724)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:708)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.startClientNodes(TcpClientDiscoverySpiSelfTest.java:1850)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testJoinError(TcpClientDiscoverySpiSelfTest.java:1085)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1665)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:666)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1485)
> ... 17 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Join process timed 
> out, did not receive response for join request (consider increasing 
> 'joinTimeout' configuration property) [joinTimeout=8000, 
> sock=Socket[addr=/127.0.0.1,port=47500,localport=43551]]
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1324)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [18:07:52,357][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> 

[jira] [Created] (IGNITE-4707) Add documentation for HA IGFS client

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4707:
---

 Summary: Add documentation for HA IGFS client
 Key: IGNITE-4707
 URL: https://issues.apache.org/jira/browse/IGNITE-4707
 Project: Ignite
  Issue Type: Task
  Components: documentation, IGFS
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 2.0


We need to document HA feature added in IGNITE-2356.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-2703 at 2/15/17 3:32 PM:
-

IGNITE-4663 and IGNITE-4673 are unblocked. Merged from ignite-2.0.

ExecutableTest.TestConfig hangs, fixed.


was (Author: ptupitsyn):
IGNITE-4663 and IGNITE-4673 are unblocked. Merged from ignite-2.0.

ExecutableTest.TestConfig hangs, investigating.

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-4401) TouchedExpiryPolicy works incorrect

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4401:
--
Summary: TouchedExpiryPolicy works incorrect  (was: TouchedExpiryPolicy 
works incorrect in SQL.)

> TouchedExpiryPolicy works incorrect
> ---
>
> Key: IGNITE-4401
> URL: https://issues.apache.org/jira/browse/IGNITE-4401
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Kholodov
> Attachments: Expirypolicy.zip
>
>
> Test which reproduced the issue in attachment [^Expirypolicy.zip].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-4401) TouchedExpiryPolicy works incorrect in some cases

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4401:
--
Summary: TouchedExpiryPolicy works incorrect in some cases  (was: 
TouchedExpiryPolicy works incorrect)

> TouchedExpiryPolicy works incorrect in some cases
> -
>
> Key: IGNITE-4401
> URL: https://issues.apache.org/jira/browse/IGNITE-4401
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Kholodov
> Attachments: Expirypolicy.zip
>
>
> Test which reproduced the issue in attachment [^Expirypolicy.zip].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4611) Write IgniteUuid with BinaryMarshaller

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur reassigned IGNITE-4611:
--

Assignee: Vyacheslav Daradur

> Write IgniteUuid with BinaryMarshaller
> --
>
> Key: IGNITE-4611
> URL: https://issues.apache.org/jira/browse/IGNITE-4611
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Currently IgniteUuid is written with OptimizedMarshaller
> (it is not included in BinaryContext.BINARYLIZABLE_SYS_CLSS).
> This prevents it from being read on other platforms (.NET, C++).
> Use BinaryMarshaller instead.
> Dev list thread: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Write-IgniteUuid-with-BinaryMarshaller-td13971.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2703:


IGNITE-4663 and IGNITE-4673 are unblocked. Merged from ignite-2.0.

ExecutableTest.TestConfig hangs, investigating.

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[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=15867890#comment-15867890
 ] 

Taras Ledkov commented on IGNITE-2356:
--

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

> 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.15#6346)

[jira] [Assigned] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev reassigned IGNITE-3710:
-

Assignee: Evgenii Zhuravlev  (was: Anton Vinogradov)

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 1.9
>
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:498) 
> at 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1948:


GitHub user SharplEr opened a pull request:

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

IGNITE-1948

I divided ClusterTopologyCheckedException into two: 
ClusterTopologyCheckedException (with readyFut) and 
ClusterTopologyLocalException (without readyFut). 
ClusterTopologyCheckedException extends ClusterTopologyLocalException.

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

$ git pull https://github.com/SharplEr/ignite ignite-1948

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

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


commit 814c92620fd92cd9a245d71e8e310c4a5df0abe5
Author: Alexander Menshikov 
Date:   2017-02-14T11:11:53Z

Add ClusterGroupEmptyLocalException and ClusterTopologyLocalException

commit edf38a248011a56691605dfd7acaf8d2d51536e7
Author: Alexander Menshikov 
Date:   2017-02-14T12:00:23Z

Add license

commit 19fc62af997d54dcffcf8df84e76736018bbb7f8
Author: Alexander Menshikov 
Date:   2017-02-14T12:05:46Z

Remove some commented lines

commit 7a280a8c5253c94f7238f8078114494835f66957
Author: Alexander Menshikov 
Date:   2017-02-14T12:25:34Z

Remove some commented code and add asserts

commit 9015c9b3d54d266c12450a8c211dbb4531799b63
Author: Alexander Menshikov 
Date:   2017-02-14T12:29:41Z

Add assert for testing

commit 1cbd9bd9502ba534dd7ad6d8adad9bed447be669
Author: Alexander Menshikov 
Date:   2017-02-14T13:50:22Z

Cleanup code

commit b02be8fc99408aa0a12eb0ef355ea93b0173d7e0
Author: Alexander Menshikov 
Date:   2017-02-15T10:37:48Z

Expanded use of ClusterTopologyLocalException




> 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.15#6346)

[jira] [Comment Edited] (IGNITE-3558) Affinity task hangs when Collision SPI produces a lot of job rejections & Failover SPI produces many attempts

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3558 at 2/15/17 1:32 PM:
---

Pull request to run tests: 
[pull/1326|https://github.com/apache/ignite/pull/1326]
[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1326%2Fhead]


was (Author: tledkov-gridgain):
Pull request to run tests: 
[pull/1326|https://github.com/apache/ignite/pull/1326]

> Affinity task hangs when Collision SPI produces a lot of job rejections & 
> Failover SPI produces many attempts
> -
>
> Key: IGNITE-3558
> URL: https://issues.apache.org/jira/browse/IGNITE-3558
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> The test to reproduce:
> IgniteCacheLockPartitionOnAffinityRunWithCollisionSpiTest#testJobFinishing
> *Root cause*
> GridJobExecuteResponse isn't set from target node because there is a 
> confusion with GridJobWorker instances in the CollisionContext.
> *Suggestion*
> The method GridJobProcessor.CollisionJobContext.cancel()
> use passiveJobs.remove(jobWorker.getJobId(), jobWorker). 
> *passiveJobs* is a ConcurrentHashMap and GridJobWorker.equals() implements as 
> a equation of jobId.
> So, when two thread try to cancel the two workers with *the same jobIds* we 
> have the case:
> - thread0 remove jobWorker0 & cancel jobWorker0.
> - thread0 put jobWorker1 (because jobWorker0 already removed);
> - thread1: (has a copy of jobWorker0) and try to cancel it.
> - thread1: remove jobWorker1 instead of jobWorker0 (because jobId is used to 
> identify);
> - thread1: doesn't send ExecuteResponse because jobWorker0 has been canceled.
> *Proposal*
> Try to use system default equals for the GridJobWorker



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4693) Add possibility to wrap Java plugin exceptions to .NET plugin exceptions

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4693:


Merged to ignite-2.0

> Add possibility to wrap Java plugin exceptions to .NET plugin exceptions
> 
>
> Key: IGNITE-4693
> URL: https://issues.apache.org/jira/browse/IGNITE-4693
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugins with Java part can throw custom Java exceptions, which are mapped to 
> {{IgniteException}}. We should add a way for plugin authors to map their 
> custom Java exceptions to corresponding .NET exceptions.
> This can be done by adding {{IPluginProvider.ConvertException}} method and 
> iterating over plugins in {{ExceptionUtils.GetException}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4693) Add possibility to wrap Java plugin exceptions to .NET plugin exceptions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4693:


Github user ptupitsyn closed the pull request at:

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


> Add possibility to wrap Java plugin exceptions to .NET plugin exceptions
> 
>
> Key: IGNITE-4693
> URL: https://issues.apache.org/jira/browse/IGNITE-4693
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugins with Java part can throw custom Java exceptions, which are mapped to 
> {{IgniteException}}. We should add a way for plugin authors to map their 
> custom Java exceptions to corresponding .NET exceptions.
> This can be done by adding {{IPluginProvider.ConvertException}} method and 
> iterating over plugins in {{ExceptionUtils.GetException}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4481) Creating the scripts

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov commented on IGNITE-4481:
--

Script {{benchmark-manual-servers-start.sh}}:
We need to change:
1. Line 75 {{if [ -z "$1" ]; then}} to {{if [ -z "$CONFIG_INCLUDE" ]; then}}
2. Need to fix https://issues.apache.org/jira/browse/IGNITE-4668 (this task 
need to fix in the next release, not in 1.9.0)

> Creating the scripts
> 
>
> Key: IGNITE-4481
> URL: https://issues.apache.org/jira/browse/IGNITE-4481
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> The goal of this subtask is to resolve this part of original task:
> 1. Every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 2. For local runs (drivers and servers point out on localhost) ssh connection 
> must not be used



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4685) Propagate platform plugin configuration to Java

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4685:


Github user ptupitsyn closed the pull request at:

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


> Propagate platform plugin configuration to Java
> ---
>
> Key: IGNITE-4685
> URL: https://issues.apache.org/jira/browse/IGNITE-4685
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> {{IPluginConfiguration}} implementations should be able to propagate data to 
> Java side and update corresponding {{PluginConfiguration}} there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4685) Propagate platform plugin configuration to Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4685:


Merged to ignite-2.0

> Propagate platform plugin configuration to Java
> ---
>
> Key: IGNITE-4685
> URL: https://issues.apache.org/jira/browse/IGNITE-4685
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> {{IPluginConfiguration}} implementations should be able to propagate data to 
> Java side and update corresponding {{PluginConfiguration}} there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4577) Ensure that certain interface addresses can be excluded form node attributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4577:


GitHub user ezhuravl opened a pull request:

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

IGNITE-4577 Add sort for virtual interface addresses



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

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

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

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


commit 71f0e8335eab84e650b24f43daae009e96c56248
Author: Evgenii Zhuravlev 
Date:   2017-02-15T12:40:34Z

IGNITE-4577 Add sort for virtual interface addresses




> Ensure that certain interface addresses can be excluded form node attributes
> 
>
> Key: IGNITE-4577
> URL: https://issues.apache.org/jira/browse/IGNITE-4577
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.0
>
>
> *Problem*
> Consider a case when node has some network interface which is not accessible 
> from the outside (e.g. in Docker container). Ignite adds this address to 
> attributes, which are shared with other nodes. Now if remote want to 
> communicate with local node chances that he will try to establish connection 
> with invalid address. 
> In the worst case connection will be impossible. We use {{AddressResolver}} 
> to handle this situation.
> However, it appears that {{AddressResolver}} cannot prevent certain address 
> to appear in address list. As a result users may experience communication 
> delays as we establish peer-to-peer connection in one thread, iterating over 
> all available addresses.
> *Proposed solution*
> We need to examine what happens when address resolver is set. May be it is 
> necessary to rethink how we handle returned object. E.g. {{null}} or empty 
> collection might mean that this address should not be included into the list 
> of address. However, it may break existing applications, so chances that 
> other solution is needed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4481) Creating the scripts

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov edited comment on IGNITE-4481 at 2/15/17 12:08 PM:


[~oleg-ostanin]

I've reviewed your changes in {{benchmark-run-all.sh}}. Here is my comments:
1. Please use {{$(smth)}} instead of {{`smth`}}. It's appears here:  
{noformat}MAIN_DIR=`cd ${SCRIPT_DIR}/../; pwd`{noformat}

2. I got file {{gc132604.log}} in {{MAIN_DIR}} after run 3 benchmarks on 
localhost. All benchmarks from one properties file (default configuration - 
benchmark.properties)

3. Need to add actual help for {{benchmark-run-all.sh}}. Now when I'm typing 
{{benchmark-run-all.sh -h}} it shows only:
{noformat}
Usage: benchmark-run-all.sh [PROPERTIES_FILE_PATH]
Script that executes BenchmarkDriver locally and BenchmarkServers on remote 
machines.
{noformat}

4. Please change here separator. It is space, not comma. {noformat}IFS=',' read 
-ra local_ips_array <<< ${local_ip_addresses[@]}{noformat}

5. You are using {{uniq_ips}} array as global variable. I think it would be 
better to return this array from function {{define_ips}} as string and then  in 
{{ copy_to_hosts }} and {{collect_results}} split it by whitespace. Please look 
here: http://www.linuxjournal.com/content/return-values-bash-functions

6. In function  {{ copy_to_hosts }} need to add {{else}} part when something 
happens if {{MAIN_DIR}} already exist on remote host

7. Please change name of variable {{folder}} to {{results_folder}} 

8. Please remove this condition {{$ip != $local_ip_addr}} from function 
{{collect_results}} 

9. Please replace {noformat}if echo "${DRIVER_HOSTS}" | grep -i $ip 
>/dev/null{noformat} to {noformat}if [[ ${DRIVER_HOSTS}== *"$ip"* ]]{noformat}



was (Author: ustas):
[~oleg-ostanin]

I've reviewed your changes in {{benchmark-run-all.sh}}. Here is my comments:
1. Please use {{$(smth)}} instead {{`smth`}}. It's appears here:  
{noformat}MAIN_DIR=`cd ${SCRIPT_DIR}/../; pwd`{noformat}

2. I got file {{gc132604.log}} in {{MAIN_DIR}} after run 3 benchmarks on 
localhost. All benchmarks from one properties file (default configuration - 
benchmark.properties)

3. Need to add actual help for {{benchmark-run-all.sh}}. Now when I'm typing 
{{benchmark-run-all.sh -h}} it shows only:
{noformat}
Usage: benchmark-run-all.sh [PROPERTIES_FILE_PATH]
Script that executes BenchmarkDriver locally and BenchmarkServers on remote 
machines.
{noformat}

4. Please change here separator. It is space, not comma. {noformat}IFS=',' read 
-ra local_ips_array <<< ${local_ip_addresses[@]}{noformat}

5. You are using {{uniq_ips}} array as global variable. I think it would be 
better to return this array from function {{define_ips}} as string and then  in 
{{ copy_to_hosts }} and {{collect_results}} split it by whitespace. Please look 
here: http://www.linuxjournal.com/content/return-values-bash-functions

6. In function  {{ copy_to_hosts }} need to add {{else}} part when something 
happens if {{MAIN_DIR}} already exist on remote host

7. Please change name of variable {{folder}} to {{results_folder}} 

8. Please remove this condition {{$ip != $local_ip_addr}} from function 
{{collect_results}} 

9. Please replace {noformat}if echo "${DRIVER_HOSTS}" | grep -i $ip 
>/dev/null{noformat} to {noformat}if [[ ${DRIVER_HOSTS}== *"$ip"* ]]{noformat}


> Creating the scripts
> 
>
> Key: IGNITE-4481
> URL: https://issues.apache.org/jira/browse/IGNITE-4481
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> The goal of this subtask is to resolve this part of original task:
> 1. Every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 2. For local runs (drivers and servers point out on localhost) ssh connection 
> must not be used



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4693) Add possibility to wrap Java plugin exceptions to .NET plugin exceptions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4693:
-

[~ptupitsyn], LGTM.

> Add possibility to wrap Java plugin exceptions to .NET plugin exceptions
> 
>
> Key: IGNITE-4693
> URL: https://issues.apache.org/jira/browse/IGNITE-4693
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugins with Java part can throw custom Java exceptions, which are mapped to 
> {{IgniteException}}. We should add a way for plugin authors to map their 
> custom Java exceptions to corresponding .NET exceptions.
> This can be done by adding {{IPluginProvider.ConvertException}} method and 
> iterating over plugins in {{ExceptionUtils.GetException}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4481) Creating the scripts

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov commented on IGNITE-4481:
--

[~oleg-ostanin]

I've reviewed your changes in {{benchmark-run-all.sh}}. Here is my comments:
1. Please use {{$(smth)}} instead {{`smth`}}. It's appears here:  
{noformat}MAIN_DIR=`cd ${SCRIPT_DIR}/../; pwd`{noformat}

2. I got file {{gc132604.log}} in {{MAIN_DIR}} after run 3 benchmarks on 
localhost. All benchmarks from one properties file (default configuration - 
benchmark.properties)

3. Need to add actual help for {{benchmark-run-all.sh}}. Now when I'm typing 
{{benchmark-run-all.sh -h}} it shows only:
{noformat}
Usage: benchmark-run-all.sh [PROPERTIES_FILE_PATH]
Script that executes BenchmarkDriver locally and BenchmarkServers on remote 
machines.
{noformat}

4. Please change here separator. It is space, not comma. {noformat}IFS=',' read 
-ra local_ips_array <<< ${local_ip_addresses[@]}{noformat}

5. You are using {{uniq_ips}} array as global variable. I think it would be 
better to return this array from function {{define_ips}} as string and then  in 
{{ copy_to_hosts }} and {{collect_results}} split it by whitespace. Please look 
here: http://www.linuxjournal.com/content/return-values-bash-functions

6. In function  {{ copy_to_hosts }} need to add {{else}} part when something 
happens if {{MAIN_DIR}} already exist on remote host

7. Please change name of variable {{folder}} to {{results_folder}} 

8. Please remove this condition {{$ip != $local_ip_addr}} from function 
{{collect_results}} 

9. Please replace {noformat}if echo "${DRIVER_HOSTS}" | grep -i $ip 
>/dev/null{noformat} to {noformat}if [[ ${DRIVER_HOSTS}== *"$ip"* ]]{noformat}


> Creating the scripts
> 
>
> Key: IGNITE-4481
> URL: https://issues.apache.org/jira/browse/IGNITE-4481
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> The goal of this subtask is to resolve this part of original task:
> 1. Every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 2. For local runs (drivers and servers point out on localhost) ssh connection 
> must not be used



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4673) Object array element type is written as a user type

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4673 at 2/15/17 11:39 AM:


Fixed.
[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1512%2Fhead]
About tests results: I don't see real new failures. All failures marked as 
'new' look like fluky.


was (Author: tledkov-gridgain):
Fixed.
[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1512%2Fhead]

> Object array element type is written as a user type
> ---
>
> Key: IGNITE-4673
> URL: https://issues.apache.org/jira/browse/IGNITE-4673
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryWriterExImpl.doWriteObjectArray}} registers {{java.lang.Object}} 
> element type as a custom type instead of using {{OBJECT_TYPE_ID}}.
> As a result, platforms (.NET, C++) can not understand such an array.
> This is also suboptimal due to extra type registration and lookups.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4706) Rewrite test GridTaskExecutionSelfTest::testJobIdCollision to use multiple JVMs

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-4706:
---

 Summary: Rewrite test 
GridTaskExecutionSelfTest::testJobIdCollision to use multiple JVMs
 Key: IGNITE-4706
 URL: https://issues.apache.org/jira/browse/IGNITE-4706
 Project: Ignite
  Issue Type: Test
Reporter: Sergey Chugunov


h2. Notes
Test emulates ID collision by tricks with *IgniteUuid* local counter which 
leads to failures of important components like discovery messaging.
It makes test unstable; sometimes it hangs or fails in a various ways.

h2. Acceptance Criteria
Test exploits multiple JVMs to execute its logic, all tricks with IgniteUuid 
are removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-1624) [Test failed] Ignite SPI: TcpClientDiscoverySpiSelfTest.testJoinError failed

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-1624:
---

Assignee: Alexander Menshikov

> [Test failed] Ignite SPI:  TcpClientDiscoverySpiSelfTest.testJoinError failed
> -
>
> Key: IGNITE-1624
> URL: https://issues.apache.org/jira/browse/IGNITE-1624
> Project: Ignite
>  Issue Type: Test
>Reporter: Andrey Gura
>Assignee: Alexander Menshikov
>Priority: Critical
>  Labels: Muted_test
> Fix For: 2.0
>
>
> The following test periodically fail on TC:
>  * {{TcpClientDiscoverySpiSelfTest.testJoinError}}
>  * {{TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinError}}
> {noformat}
> [18:07:52,332][ERROR][test-runner][IgniteKernal%client-0] Got exception while 
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:724)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:708)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.startClientNodes(TcpClientDiscoverySpiSelfTest.java:1850)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testJoinError(TcpClientDiscoverySpiSelfTest.java:1085)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1665)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:666)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1485)
> ... 17 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Join process timed 
> out, did not receive response for join request (consider increasing 
> 'joinTimeout' configuration property) [joinTimeout=8000, 
> sock=Socket[addr=/127.0.0.1,port=47500,localport=43551]]
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1324)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [18:07:52,357][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:724)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:708)
> at 
> 

[jira] [Created] (IGNITE-4705) Atomic cache protocol change: notify client node from backups

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4705:


 Summary: Atomic cache protocol change: notify client node from 
backups
 Key: IGNITE-4705
 URL: https://issues.apache.org/jira/browse/IGNITE-4705
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
Assignee: Semen Boikov
 Fix For: 2.0


Currently in atomic cache backup nodes first reply to primary and then primary 
replies to client, need check if it is possible to notify client directly from 
backups.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-3727:
-
Fix Version/s: (was: 2.0)
   1.9

> Support local listeners async execution for IgniteMessage.send
> --
>
> Key: IGNITE-3727
> URL: https://issues.apache.org/jira/browse/IGNITE-3727
> Project: Ignite
>  Issue Type: Task
>  Components: messaging
>Affects Versions: 1.7
> Environment: windows 7
>Reporter: Yujue Li
>Assignee: Semen Boikov
> Fix For: 1.9
>
>
> ignite.message() method not support async mode,withAsync() is invalid.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4693) Add possibility to wrap Java plugin exceptions to .NET plugin exceptions

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4693:


1) Agree, fixed
2) {{ExceptionFactory}} is a delegate, not an interface. I think it is easier 
for plugin authors this way (they can use anonymous methods, etc). So we can't 
inject anything there. It is possible to cause another error in exception 
handler in any case.

> Add possibility to wrap Java plugin exceptions to .NET plugin exceptions
> 
>
> Key: IGNITE-4693
> URL: https://issues.apache.org/jira/browse/IGNITE-4693
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugins with Java part can throw custom Java exceptions, which are mapped to 
> {{IgniteException}}. We should add a way for plugin authors to map their 
> custom Java exceptions to corresponding .NET exceptions.
> This can be done by adding {{IPluginProvider.ConvertException}} method and 
> iterating over plugins in {{ExceptionUtils.GetException}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4694) Add tests to check there are no memory leaks in PageMemory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4694:


GitHub user gvvinblade opened a pull request:

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

IGNITE-4694 Add tests to check there are no memory leaks in PageMemory



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

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

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

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


commit 692cd6c8ec619001716e81a80001e9570cb154c5
Author: Igor Seliverstov 
Date:   2017-02-15T10:41:08Z

IGNITE-4694 Add tests to check there are no memory leaks in PageMemory




> Add tests to check there are no memory leaks in PageMemory
> --
>
> Key: IGNITE-4694
> URL: https://issues.apache.org/jira/browse/IGNITE-4694
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> Need add several tests running for 5-10 munites verifying there are no memory 
> leaks in new data structures based of PageMemory:
> - test various page size
> - test various objects size
> - test put/get/remove operations
> - test create cache/destroy cache operations
> - test cases when indexes enabled/disabled
> - test case when cache expiry policy is used
> New tests should be added in new test suite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4693) Add possibility to wrap Java plugin exceptions to .NET plugin exceptions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4693 at 2/15/17 10:31 AM:
---

[~ptupitsyn], my comments:
1) {{ExceptionFactory}} must have {{className}} argument. Without it user will  
have to define separate factories for every class even if they share the same 
code.
2) I would also remove {{IIgnite}} from {{ExceptionFactory}} and rather inject 
it through annotations. This will make interface easier provided that 
{{IIgnite}} will not be needed in general case. Moreover, what if user will 
perform a call to some {{IIgnite}} method and receive another error? I would 
put all these questions aside by simply removing {{IIgnite}} from the signature.




was (Author: vozerov):
[~ptupitsyn], my comments:
1) {{ExceptionFactory}} must have "className" argument. Without it user will  
have to define separate factories for every class even if they share the same 
code.
2) I would also remove {{IIgnite}} from {{ExceptionFactory}} and rather inject 
it through annotations. This will make interface easier provided that 
{{IIgnite}} will not be needed in general case. Moreover, what if user will 
perform a call to some {{IIgnite}} method and receive another error? I would 
put all these questions aside by simply removing {{IIgnite}} from the signature.



> Add possibility to wrap Java plugin exceptions to .NET plugin exceptions
> 
>
> Key: IGNITE-4693
> URL: https://issues.apache.org/jira/browse/IGNITE-4693
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugins with Java part can throw custom Java exceptions, which are mapped to 
> {{IgniteException}}. We should add a way for plugin authors to map their 
> custom Java exceptions to corresponding .NET exceptions.
> This can be done by adding {{IPluginProvider.ConvertException}} method and 
> iterating over plugins in {{ExceptionUtils.GetException}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4673) Object array element type is written as a user type

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4673 at 2/15/17 10:25 AM:


Fixed.
[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1512%2Fhead]


was (Author: tledkov-gridgain):
Fixed.
Waits for TC [tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1512%2Fhead]

> Object array element type is written as a user type
> ---
>
> Key: IGNITE-4673
> URL: https://issues.apache.org/jira/browse/IGNITE-4673
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryWriterExImpl.doWriteObjectArray}} registers {{java.lang.Object}} 
> element type as a custom type instead of using {{OBJECT_TYPE_ID}}.
> As a result, platforms (.NET, C++) can not understand such an array.
> This is also suboptimal due to extra type registration and lookups.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4685) Propagate platform plugin configuration to Java

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4685:
---

Assignee: Pavel Tupitsyn  (was: Vladimir Ozerov)

> Propagate platform plugin configuration to Java
> ---
>
> Key: IGNITE-4685
> URL: https://issues.apache.org/jira/browse/IGNITE-4685
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> {{IPluginConfiguration}} implementations should be able to propagate data to 
> Java side and update corresponding {{PluginConfiguration}} there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4685) Propagate platform plugin configuration to Java

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4685:
-

[~ptupitsyn], LGTM.

> Propagate platform plugin configuration to Java
> ---
>
> Key: IGNITE-4685
> URL: https://issues.apache.org/jira/browse/IGNITE-4685
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>  Labels: .NET
> Fix For: 2.0
>
>
> {{IPluginConfiguration}} implementations should be able to propagate data to 
> Java side and update corresponding {{PluginConfiguration}} there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4694) Add tests to check there are no memory leaks in PageMemory

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov commented on IGNITE-4694:
--

- test create cache/destroy cache operations - *already in place* 
{{org.apache.ignite.internal.processors.database.IgniteDbDynamicCacheSelfTest}}

> Add tests to check there are no memory leaks in PageMemory
> --
>
> Key: IGNITE-4694
> URL: https://issues.apache.org/jira/browse/IGNITE-4694
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> Need add several tests running for 5-10 munites verifying there are no memory 
> leaks in new data structures based of PageMemory:
> - test various page size
> - test various objects size
> - test put/get/remove operations
> - test create cache/destroy cache operations
> - test cases when indexes enabled/disabled
> - test case when cache expiry policy is used
> New tests should be added in new test suite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4501) Improvement of connection in a cluster of new node

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4501:
-

Work already done. I'm just waiting for code review.

> Improvement of connection in a cluster of new node
> --
>
> Key: IGNITE-4501
> URL: https://issues.apache.org/jira/browse/IGNITE-4501
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 1.8
>Reporter: Vyacheslav Daradur
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> h3. Main description:
> Cluster nodes connect a ring.
> For example: we have 6 nodes: A, B, C, D, E, F. 
> They can connect a ring in any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A, 
> etc.
> If some node leaves topology, adjacent nodes must reconnect. 
> If nodes A, B, C are in same physical place, nodes D, E, F are in other 
> place, and places lost connect each other, we will have many ways of 
> reconnections.
> At best case, if we had a ring: A-B-CxD-E-FxA ('x' means disconnect) -- then 
> we have only one reconnect (C
> will be connected to A or F will be connected to D -- depends on what part of 
> the cluster was alive.
> Also, if we had a not ring: AxFxBxExCxDxA -- then we have a lot of 
> reconnections (A to B, B to C, C to A -- in general n/2 reconnections, where 
> n -- number of nodes). 
> h3. Approach:
> It is necessary to develop approach of node insertion to the correct place 
> for creation of the correct ring-topology.
> h3. Solutions:
> Main idea is a sorting according to latency.
> * group nodes in arcs on an ARC_ID. (manualy?)
> * implement NodeComparator (nodes on the same host : nodes on the same subnet 
> : other nodes). We will use it when we connect a new node.
> * [dev list 
> thread|http://mail-archives.apache.org/mod_mbox/ignite-dev/201612.mbox/%3CCAN+WSNyWYXSXEBpGErVt72zTgi2pTQzUWLv8JY=ke83-5-r...@mail.gmail.com%3E]
> Update Dec, 29 Yakov Zhdanov:
> # introduce CLUSTER_REGION_ID node attribute. This can be done by adding 
> public static final constant to TcpDiscoverySpi.
> # Alter 
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing#nextNode(java.util.Collection)
>  to order basing on per node attribute value
> # Node comparison should be stable and consistent. E.g. if CLUSTER_REGION_IDs 
> are equal then we should compare nodes' IDs. This way we have consistent 
> order on all nodes in topology.
> # Also nextNode() has to group nodes on same host and in same subnet. This 
> can be postponed and implemented after we have other points done.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4650) Scan and SPI queries must go through dedicated query pool

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4650:
--

Waits for TC [tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1534%2Fhead]

> Scan and SPI queries must go through dedicated query pool
> -
>
> Key: IGNITE-4650
> URL: https://issues.apache.org/jira/browse/IGNITE-4650
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> In IGNITE-4105 we introduced separate thread pool for queries. Currently it 
> is used only for {{SQL}} queries. 
> Need to make sure that it is also used for {{SCAN}} and {{SPI}} queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (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=15867459#comment-15867459
 ] 

Oleg Ostanin edited comment on IGNITE-4212 at 2/15/17 8:43 AM:
---

[~dmagda]

Your version of README.txt says:
"1. These Ignite Yardstick Benchmarks have to be uploaded to every remote host. 
The path
to the uploaded benchmarks should be exactly the same on each host."

But now we added the functionality to help user upload Benchmarks from one 
remote host or from local machine to every other remote hosts. I think it would 
be better if we say:

By default all the necessary files will be automatically uploaded from the host 
in which you run the command above to every other host in exact same path. If 
you prefer to do it manually set the AUTO_COPY variable in property file to 
`false`.

I've double checked project compilation and for me it worked fine. Sorry I did 
not mention it before. Please attach maven building logs if you can.


was (Author: oleg-ostanin):
[~dmagda]

Your version of README.txt says:
"1. These Ignite Yardstick Benchmarks have to be uploaded to every remote host. 
The path
to the uploaded benchmarks should be exactly the same on each host."

But now we added the functionality to help user upload Benchmarks from one 
remote host or from local machine to every other remote hosts. I think it would 
be better if we say:

By default all the necessary files will be automatically uploaded from the host 
in which you run the command above to every other host in exact same path. If 
you prefer to do it manually set the AUTO_COPY variable in property file to 
`false`.

I've double checked compile the project and for me it worked fine. Sorry I did 
not mention it before. Please attach maven building logs if you can.

> 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: 1.9
>
> Attachments: benchmark-remote.properties, 
> benchmark-remote-sample.properties, DEVNOTES.txt, ignite-remote-config.xml, 
> README.txt
>
>
> 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.15#6346)

[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=15867459#comment-15867459
 ] 

Oleg Ostanin commented on IGNITE-4212:
--

[~dmagda]

Your version of README.txt says:
"1. These Ignite Yardstick Benchmarks have to be uploaded to every remote host. 
The path
to the uploaded benchmarks should be exactly the same on each host."

But now we added the functionality to help user upload Benchmarks from one 
remote host or from local machine to every other remote hosts. I think it would 
be better if we say:

By default all the necessary files will be automatically uploaded from the host 
in which you run the command above to every other host in exact same path. If 
you prefer to do it manually set the AUTO_COPY variable in property file to 
`false`.

I've double checked compile the project and for me it worked fine. Sorry I did 
not mention it before. Please attach maven building logs if you can.

> 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: 1.9
>
> Attachments: benchmark-remote.properties, 
> benchmark-remote-sample.properties, DEVNOTES.txt, ignite-remote-config.xml, 
> README.txt
>
>
> 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.15#6346)