[jira] [Updated] (IGNITE-4856) .NET: StopAll on AppDomain unload

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4856:
---
Description: 
In certain scenarios .NET {{AppDomain}} can be unloaded and started again. Java 
part of Ignite continues to run, but .NET part (including Ignite instances) is 
lost. User can no longer work with started nodes, .NET callback pointers are 
lost, etc.

1) Track AppDomain unload and stop all Ignite instances.
2) When starting Ignite, wait for node with specified name to stop.
3) Make it possible to auto-generate a unique grid name automatically? This may 
be useful in app.config.

IIS issues example: 
http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183

  was:
In certain scenarios .NET {{AppDomain}} can be unloaded and started again. Java 
part of Ignite continues to run, but .NET part (including Ignite instances) is 
lost. User can no longer work with started nodes, .NET callback pointers are 
lost, etc.

1) Track AppDomain unload and stop all Ignite instances.
2) When starting Ignite, wait for node with specified name to stop.
3) Make it possible to auto-generate a unique grid name automatically?

IIS issues example: 
http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183


> .NET: StopAll on AppDomain unload
> -
>
> Key: IGNITE-4856
> URL: https://issues.apache.org/jira/browse/IGNITE-4856
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> In certain scenarios .NET {{AppDomain}} can be unloaded and started again. 
> Java part of Ignite continues to run, but .NET part (including Ignite 
> instances) is lost. User can no longer work with started nodes, .NET callback 
> pointers are lost, etc.
> 1) Track AppDomain unload and stop all Ignite instances.
> 2) When starting Ignite, wait for node with specified name to stop.
> 3) Make it possible to auto-generate a unique grid name automatically? This 
> may be useful in app.config.
> IIS issues example: 
> http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183



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

[jira] [Assigned] (IGNITE-4856) .NET: StopAll on AppDomain unload

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4856:
--

Assignee: Pavel Tupitsyn

> .NET: StopAll on AppDomain unload
> -
>
> Key: IGNITE-4856
> URL: https://issues.apache.org/jira/browse/IGNITE-4856
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> In certain scenarios .NET {{AppDomain}} can be unloaded and started again. 
> Java part of Ignite continues to run, but .NET part (including Ignite 
> instances) is lost. User can no longer work with started nodes, .NET callback 
> pointers are lost, etc.
> 1) Track AppDomain unload and stop all Ignite instances.
> 2) When starting Ignite, wait for node with specified name to stop.
> 3) Make it possible to auto-generate a unique grid name automatically? This 
> may be useful in app.config.
> IIS issues example: 
> http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183



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

[jira] [Commented] (IGNITE-4554) Optimize integer sets.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4554:
---

Completed compressed bitset implementation based on roaring bitmaps [1]

Next is to replace Set with new data structure and measure heap 
usage/perfomance.

[1] http://roaringbitmap.org/

> Optimize integer sets.
> --
>
> Key: IGNITE-4554
> URL: https://issues.apache.org/jira/browse/IGNITE-4554
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.1
>
>
> Ignite has many uses of data structures like Set, IntArray etc.
> This is not most efficient way to represent integer sets. The best way is to 
> use compressed bit sets. This should save a lot of heap space.
> We should optimize integer sets whenever possible.
> The most obvious place to start is GridAffinityAssignment.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4534:


GitHub user glukos opened a pull request:

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

IGNITE-4534, up-to-date with ignite-3477-master

All changes from IGNITE-4534 applied over ignite-3477-master.

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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-4534-from-3477-master

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

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


commit b127153b2d2733aab1881b056d2dd2bd7f374d81
Author: Sergey Chugunov 
Date:   2017-04-03T15:29:52Z

Merge mistake was corrected, obsolete tests were removed

commit 281efd4b9f0577d55260c7ea53c450e6182085c6
Author: Ilya Lantukh 
Date:   2017-04-03T16:19:30Z

Fixed GridCacheRebalancingUnmarshallingFailedSelfTest.

commit dce205fe288e048707596bb0b467fe562e93e845
Author: Ilya Lantukh 
Date:   2017-04-03T16:20:41Z

Merge branch 'ignite-3477-master' of 
https://github.com/gridgain/apache-ignite into ignite-3477-master

commit 98d92d89d69497172a6d33d88c17c1b05396ae04
Author: Ivan Rakov 
Date:   2017-04-04T18:53:35Z

IGNITE-4534: Implement offheap eviction policies based on page memory




> 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
>  Labels: important
> 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-4795) Inherit TransactionException and update Javadoc

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-4795:
-

[~SomeFire],

Yes, I think that {{TransactionCheckedException}} should be removed. From my 
point of view it is redundant entity.

About 3 item. I think we should emphasize that all methods that throw 
{{TransactionException}} have transactional behaviour in case of cache with 
atomicity mode {{TRANSACTIONAL}}.

> Inherit TransactionException and update Javadoc
> ---
>
> Key: IGNITE-4795
> URL: https://issues.apache.org/jira/browse/IGNITE-4795
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL, website
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Ryabov Dmitrii
>  Labels: documentation, important
> Fix For: 2.0
>
>
> Understanding transactional behaviour is not clear in Javadoc at this point 
> of time. Even after reading website some doubt remain.
> Proposal.
> 1. Create {{TransactionException}} as the marker of transactional methods and 
> inherit from it all the existed transactional exceptions like 
> {{TransactionTimeoutException}}, {{TransactionRollbackException}}, 
> {{TransactionHeuristicException}}, {{TransactionOptimisticException}}, etc.
> 2. Update all the transactional methods ({{get}}, {{put}}, {{invoke}}, etc) 
> as throwing the base {{TransactionException}}. Comment all the 
> {{IgniteCache}} methods whether they are transactional or not, add {{@see 
> TransactionException}} annotation.
> 3. Make extensive documentation in the header of {{TransactionException}} to 
> get understanding of transactional and non-transactional methods behaviour.
> 4. Update website and Javadoc to clarify the fact that {{put}} value is 
> cached within the transaction and affects successive {{get}}.



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

[jira] [Commented] (IGNITE-3583) CPP: Replace passing by value with passing by reference where it is possible.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3583:


[~isapego] looks good.

> CPP: Replace passing by value with passing by reference where it is possible.
> -
>
> Key: IGNITE-3583
> URL: https://issues.apache.org/jira/browse/IGNITE-3583
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> Places to look at: {{BinaryWriter::WriteObject}} and 
> {{BinaryRawWriter::WriteObject}}.



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

[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-3682:
-

[~daradurvs],

{{ignite-scalar}} module has compilation error.

> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization 
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change 
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.



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

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

Alexander Menshikov edited comment on IGNITE-1624 at 4/4/17 3:38 PM:
-

Issue cannot reproduce for me. No any reaction from other developer or users 
more than a month. Close.


was (Author: sharpler):
Issue Cannot reproduce for me. No any reaction from other developer or users 
more than a month. Close.

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

[jira] [Resolved] (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 resolved IGNITE-1624.
-
Resolution: Cannot Reproduce

Issue Cannot reproduce for me. No any reaction from other developer or users 
more than a month. Close.

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

[jira] [Commented] (IGNITE-1267) JobStealingCollisionSpi never sends jobs to a node that joined after task was executed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1267:


GitHub user AMashenkov opened a pull request:

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

IGNITE-1267: JobStealingCollisionSpi never sends jobs to a node that joined 
after task was executed

(cherry picked from commit 7059d8e)

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

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

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

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


commit 6eae8dd0bc3e696878cf66e0fa2be607846fbe64
Author: Andrey V. Mashenkov 
Date:   2017-04-04T15:10:20Z

Fixed.

(cherry picked from commit 7059d8e)




> JobStealingCollisionSpi never sends jobs to a node that joined after task was 
> executed
> --
>
> Key: IGNITE-1267
> URL: https://issues.apache.org/jira/browse/IGNITE-1267
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
>  Labels: user-request
> Fix For: 2.0
>
>
> Corresponding user thread (contains detailed description of the scenario that 
> doesn't work): 
> http://apache-ignite-users.70518.x6.nabble.com/Dynamic-ComputeTask-distribution-with-new-nodes-td997.html
> Essentially, {{JobStealingCollisionSpi}} always skips jobs that are not in 
> task topology (see line 713). Task topology is static and created when task 
> is executed, so newly joined node can't steal jobs. I think it should be able 
> to do this if it satisfies initial cluster group predicate.



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

[jira] [Commented] (IGNITE-4535) Add option to store deserialized values on-heap

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-4535:
--

Hi [~sboikov],

Thanks for your review!

I've opened a discussion on dev list.

> Add option to store deserialized values on-heap
> ---
>
> Key: IGNITE-4535
> URL: https://issues.apache.org/jira/browse/IGNITE-4535
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>  Labels: important
> Fix For: 2.0
>
>
> Now cache data is always stored in offheap (pagememory). Need implement 
> option to also store deserialised values in heap memory, this should be 
> replacement for existing CacheConfiguration.memoryMode configuration.



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

[jira] [Commented] (IGNITE-4795) Inherit TransactionException and update Javadoc

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-4795:


[~agura], I made fix, can you look it?

About third item - I have no idea how to describe it more. Is it enough or can 
you orient me with advice?

About {{TransactionCheckedException}} - Avoid? Do you mean remove it completely?

> Inherit TransactionException and update Javadoc
> ---
>
> Key: IGNITE-4795
> URL: https://issues.apache.org/jira/browse/IGNITE-4795
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL, website
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Ryabov Dmitrii
>  Labels: documentation, important
> Fix For: 2.0
>
>
> Understanding transactional behaviour is not clear in Javadoc at this point 
> of time. Even after reading website some doubt remain.
> Proposal.
> 1. Create {{TransactionException}} as the marker of transactional methods and 
> inherit from it all the existed transactional exceptions like 
> {{TransactionTimeoutException}}, {{TransactionRollbackException}}, 
> {{TransactionHeuristicException}}, {{TransactionOptimisticException}}, etc.
> 2. Update all the transactional methods ({{get}}, {{put}}, {{invoke}}, etc) 
> as throwing the base {{TransactionException}}. Comment all the 
> {{IgniteCache}} methods whether they are transactional or not, add {{@see 
> TransactionException}} annotation.
> 3. Make extensive documentation in the header of {{TransactionException}} to 
> get understanding of transactional and non-transactional methods behaviour.
> 4. Update website and Javadoc to clarify the fact that {{put}} value is 
> cached within the transaction and affects successive {{get}}.



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

[jira] [Assigned] (IGNITE-4535) Add option to store deserialized values on-heap

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-4535:


Assignee: Ilya Lantukh  (was: Alexey Goncharuk)

Hi Ilya,

I reviewed your changes, have some comments:
- currently to enable on-heap cache user need to set eviction policy in config, 
this is not very intuitive, please discuss this on dev list
- some logic for sync evicts was removed, but still there is unused code 
related to sync evictions (in eviction manager) + related messages + related 
properties in CacheConfiguration, please remove all this as well
- you removed tests with various memory modes, but instead these tests should 
be changed to work in default mode and in mode when on-heap cache is enabled 
(the same for config variations tests and configuration options for yardstick 
benchmarks)
- please remove unused imports in files you change

Thanks!

> Add option to store deserialized values on-heap
> ---
>
> Key: IGNITE-4535
> URL: https://issues.apache.org/jira/browse/IGNITE-4535
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>  Labels: important
> Fix For: 2.0
>
>
> Now cache data is always stored in offheap (pagememory). Need implement 
> option to also store deserialised values in heap memory, this should be 
> replacement for existing CacheConfiguration.memoryMode configuration.



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

[jira] [Created] (IGNITE-4910) Add copyOnRead property for near cache.

[Maksim Kozlov (JIRA)]

Maksim Kozlov created IGNITE-4910:
-

 Summary: Add copyOnRead property for near cache.
 Key: IGNITE-4910
 URL: https://issues.apache.org/jira/browse/IGNITE-4910
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Maksim Kozlov
Assignee: Maksim Kozlov


Add {{setCopyOnRead}} to {{NearCacheConfiguration}} class.
Continuation of the task from the ticket 
[https://issues.apache.org/jira/browse/IGNITE-2558].



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

[jira] [Commented] (IGNITE-4022) IgniteServices soesn't throw an exception if there are no server nodes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4022:


GitHub user vldpyatkov opened a pull request:

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

IGNITE-4022

IgniteServices soesn't throw an exception if there are no server nodes

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

$ git pull https://github.com/vldpyatkov/ignite ignite-4022

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

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






> IgniteServices soesn't throw an exception if there are no server nodes
> --
>
> Key: IGNITE-4022
> URL: https://issues.apache.org/jira/browse/IGNITE-4022
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Alexander Belyak
>Assignee: Vladislav Pyatkov
>
> If you call deployNodeSingleton method, but there are no server nodes in 
> IgniteServices base ClusterGroup - you will never know about it and can't 
> find deployed service instance. Probably we should print out these errors in 
> logs as well.



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

[jira] [Commented] (IGNITE-4022) IgniteServices soesn't throw an exception if there are no server nodes

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov commented on IGNITE-4022:
---

I think, WAN message will be enough, because a service can be reassigned (when 
particular node/group appears on cluster) before it will be invoke.

> IgniteServices soesn't throw an exception if there are no server nodes
> --
>
> Key: IGNITE-4022
> URL: https://issues.apache.org/jira/browse/IGNITE-4022
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Alexander Belyak
>Assignee: Vladislav Pyatkov
>
> If you call deployNodeSingleton method, but there are no server nodes in 
> IgniteServices base ClusterGroup - you will never know about it and can't 
> find deployed service instance. Probably we should print out these errors in 
> logs as well.



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

[jira] [Commented] (IGNITE-3487) _key and _val fields should be excluded from 'select * from' queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3487:


Github user skalashnikov closed the pull request at:

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


> _key and _val fields should be excluded from 'select * from' queries
> 
>
> Key: IGNITE-3487
> URL: https://issues.apache.org/jira/browse/IGNITE-3487
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Sergey Kalashnikov
>  Labels: important
> Fix For: 2.0
>
>
> We have a pretty serious usability issue - predefined {{_key}} and {{_val}} 
> fields are returned when query like {{select * from}} is executed. First of 
> all, this is counterintuitive because user never defines or configures these 
> fields. Second of all, they actually duplicate all other fields. And finally, 
> they cause serialization exceptions because classes for key and value are not 
> always available.
> We should exclude these fields from {{select * from}} queries, but this is a 
> compatibility breaking change. It should be done in 2.0.



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

[jira] [Assigned] (IGNITE-3584) CPP: Refactor BinaryType class template.

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-3584:
---

Assignee: Igor Sapego

> CPP: Refactor BinaryType class template.
> 
>
> Key: IGNITE-3584
> URL: https://issues.apache.org/jira/browse/IGNITE-3584
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> 1. All methods should be 'static'.
> 2. Methods {{GetTypeName()}}, {{Read()}} and {{GetNull()}} should pass result 
> to caller by reference argument and not by return value to avoid copying and 
> temporary objects creation.
> 3. For the {{BinaryType}}: additionally to the mentioned above, remove 
> field {{typ}} and add type alias for the non-pointer type instead.
> Explanation:
> Current role of the {{BinaryType}} in C++ is to provide Ignite with the 
> information about its template type, to be used during serialization and 
> deserialization. Unlike Java version, C++ {{BinaryType}} also used for user 
> to provide implementation of {{Read}} and {{Write}} methods, i.e. methods 
> that used to serialize and deserialize objects.
> We can not have non-template interface for this class as Write and Read 
> methods have templated type in theirs signatures:
> {code}
> void Write(BinaryWriter& writer, const T& obj); 
> T Read(BinaryReader& reader);
> {code}
> We can not change template type {{T}} with non-template type as we don't have 
> single root class in C++ like {{Object}} class in Java and we also don't have 
> any type information at runtime.
> Thus we always need to know template type for the {{BinaryType}} when we 
> are instantiating it, thus we can not have any fabrics or any polymorphism 
> for this class in C++ and internally we always use default constructor to get 
> new instance of such a class.
> So, currently I can not see how having non static methods could be useful for 
> this class.



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

[jira] [Assigned] (IGNITE-3583) CPP: Replace passing by value with passing by reference where it is possible.

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-3583:
---

Assignee: Igor Sapego

> CPP: Replace passing by value with passing by reference where it is possible.
> -
>
> Key: IGNITE-3583
> URL: https://issues.apache.org/jira/browse/IGNITE-3583
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> Places to look at: {{BinaryWriter::WriteObject}} and 
> {{BinaryRawWriter::WriteObject}}.



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

[jira] [Commented] (IGNITE-3583) CPP: Replace passing by value with passing by reference where it is possible.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3583:


GitHub user isapego opened a pull request:

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

IGNITE-3583: Replaced passing by value with passing by reference



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

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

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

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


commit b6d1eecdb4aa6a4713e9e63dee0751e7b4515dbc
Author: Igor Sapego 
Date:   2017-04-04T12:18:49Z

IGNITE-3583: Replaced passing by value with passing by reference




> CPP: Replace passing by value with passing by reference where it is possible.
> -
>
> Key: IGNITE-3583
> URL: https://issues.apache.org/jira/browse/IGNITE-3583
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> Places to look at: {{BinaryWriter::WriteObject}} and 
> {{BinaryRawWriter::WriteObject}}.



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

[jira] [Comment Edited] (IGNITE-4839) Remove CacheTypeMetadata

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4839 at 4/4/17 11:34 AM:
---

Fixed. Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1667%2Fhead]
 are OK with me.


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

> Remove CacheTypeMetadata
> 
>
> Key: IGNITE-4839
> URL: https://issues.apache.org/jira/browse/IGNITE-4839
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>




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

[jira] [Comment Edited] (IGNITE-4849) Review and refactoring the versioned classes

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4849 at 4/4/17 11:33 AM:
---

Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1697%2Fhead]
 are OK with me.


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

> Review and refactoring the versioned classes
> 
>
> Key: IGNITE-4849
> URL: https://issues.apache.org/jira/browse/IGNITE-4849
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> There are some classes without and with {{V2}} suffix. Usually they are used 
> to backward compatibility.
> These classes must be reviewed and refactored if it is necessary. 



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

[jira] [Updated] (IGNITE-4909) Get rid of AssertionError as a positive warnings

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4909:
-
Summary: Get rid of AssertionError as a positive warnings  (was: Get кid of 
AssertionError as a positive warnings)

> Get rid of AssertionError as a positive warnings
> 
>
> Key: IGNITE-4909
> URL: https://issues.apache.org/jira/browse/IGNITE-4909
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.0
>
>
> I found that some tests can cause AssertionError even in case everything is 
> ok.
> Examples:
> 1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed 
> with unhandled error (normal behaviour): java.lang.AssertionError: Test 
> assertion (should be ignored).
> 2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught 
> expected error: java.lang.AssertionError



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

[jira] [Updated] (IGNITE-4909) Get кid of AssertionError as a positive warnings

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4909:
-
Summary: Get кid of AssertionError as a positive warnings  (was: Get Rid of 
AssertionError as a positive warnings)

> Get кid of AssertionError as a positive warnings
> 
>
> Key: IGNITE-4909
> URL: https://issues.apache.org/jira/browse/IGNITE-4909
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.0
>
>
> I found that some tests can cause AssertionError even in case everything is 
> ok.
> Examples:
> 1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed 
> with unhandled error (normal behaviour): java.lang.AssertionError: Test 
> assertion (should be ignored).
> 2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught 
> expected error: java.lang.AssertionError



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

[jira] [Commented] (IGNITE-4909) Get Rid of AssertionError as a positive warnings

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4909:
--

Possible case is to change such AssertionErrors to RuntimeExceptions.

> Get Rid of AssertionError as a positive warnings
> 
>
> Key: IGNITE-4909
> URL: https://issues.apache.org/jira/browse/IGNITE-4909
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.0
>
>
> I found that some tests can cause AssertionError even in case everything is 
> ok.
> Examples:
> 1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed 
> with unhandled error (normal behaviour): java.lang.AssertionError: Test 
> assertion (should be ignored).
> 2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught 
> expected error: java.lang.AssertionError



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

[jira] [Commented] (IGNITE-4895) TC should fail suite if AssertionError is output to logs

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4895:
--

Blocked by IGNITE-4909

> TC should fail suite if AssertionError is output to logs
> 
>
> Key: IGNITE-4895
> URL: https://issues.apache.org/jira/browse/IGNITE-4895
> Project: Ignite
>  Issue Type: Test
>Reporter: Yakov Zhdanov
>Priority: Blocker
> Fix For: 2.0
>
>
> AssertionError is never thrown on purpose during the tests opposite to 
> exceptions which are normal for plenty of scenarios.
> TC should fail if assertion error is output to logs.



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

[jira] [Updated] (IGNITE-4909) Get Rid of AssertionError as a positive warnings

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4909:
-
Fix Version/s: 2.0

> Get Rid of AssertionError as a positive warnings
> 
>
> Key: IGNITE-4909
> URL: https://issues.apache.org/jira/browse/IGNITE-4909
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.0
>
>
> I found that some tests can cause AssertionError even in case everything is 
> ok.
> Examples:
> 1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed 
> with unhandled error (normal behaviour): java.lang.AssertionError: Test 
> assertion (should be ignored).
> 2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught 
> expected error: java.lang.AssertionError



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

[jira] [Reopened] (IGNITE-4895) TC should fail suite if AssertionError is output to logs

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reopened IGNITE-4895:
--
  Assignee: (was: Anton Vinogradov)

> TC should fail suite if AssertionError is output to logs
> 
>
> Key: IGNITE-4895
> URL: https://issues.apache.org/jira/browse/IGNITE-4895
> Project: Ignite
>  Issue Type: Test
>Reporter: Yakov Zhdanov
>Priority: Blocker
> Fix For: 2.0
>
>
> AssertionError is never thrown on purpose during the tests opposite to 
> exceptions which are normal for plenty of scenarios.
> TC should fail if assertion error is output to logs.



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

[jira] [Created] (IGNITE-4909) Get Rid of AssertionError as a positive warnings

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-4909:


 Summary: Get Rid of AssertionError as a positive warnings
 Key: IGNITE-4909
 URL: https://issues.apache.org/jira/browse/IGNITE-4909
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov


I found that some tests can cause AssertionError even in case everything is ok.

Examples:
1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed 
with unhandled error (normal behaviour): java.lang.AssertionError: Test 
assertion (should be ignored).
2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught 
expected error: java.lang.AssertionError



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

Alexander Menshikov commented on IGNITE-4501:
-

[~yzhdanov]

I create upsource review. 
http://reviews.ignite.apache.org/ignite/review/IGNT-CR-158
Please look at code and my answer in github. I want to include these changes in 
2.0 release, but time is running out.

> 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] [Updated] (IGNITE-4667) Throw exception on starting client cache when indexed types cannot be loaded

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-4667:

Fix Version/s: 2.0

> Throw exception on starting client cache when indexed types cannot be loaded
> 
>
> Key: IGNITE-4667
> URL: https://issues.apache.org/jira/browse/IGNITE-4667
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> Assume following situation:
> 1. Server node configured cache indexed types with classes that client node 
> doesn't have.
> 2. Start server.
> 3. Start client. Client successfully connected.
> 4. Try to get cache on client node.
> 5. Was thrown exception in GridQueryProcessor and request for cache on client 
> node hangs forever.
> If on some reason cache couldn't be initialized, exception must be thrown on 
> Ignite.cache() operation.



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

[jira] [Comment Edited] (IGNITE-4891) Key is deserialized during transactional get() even if withKeepBinary is set

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev edited comment on IGNITE-4891 at 4/4/17 9:42 AM:
-

Valentin, please review the fix: [PR 
1715|https://github.com/apache/ignite/pull/1715]
Upsource: 
[IGNT-CR-157|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-157]


was (Author: dkarachentsev):
Valentin, please review the fix: [PR 
1715|https://github.com/apache/ignite/pull/1715]

> Key is deserialized during transactional get() even if withKeepBinary is set
> 
>
> Key: IGNITE-4891
> URL: https://issues.apache.org/jira/browse/IGNITE-4891
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.0
>
>
> This test reproduces the issue: https://github.com/olegskoblya/tx-binary-bug



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

[jira] [Comment Edited] (IGNITE-4839) Remove CacheTypeMetadata

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4839 at 4/4/17 9:05 AM:
--

Fixed. Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1667%2Fhead]
 is OK with me.


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

> Remove CacheTypeMetadata
> 
>
> Key: IGNITE-4839
> URL: https://issues.apache.org/jira/browse/IGNITE-4839
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4906) .NET: Examples tests hang

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4906:


* {{ClientReconnectExample}} fixed to use {{TcpDiscoveryStaticIpFinder}}, it 
does not need external nodes
* Other examples keep {{TcpDiscoveryMulticastIpFinder}}, but are tested under 
{{TcpDiscoveryStaticIpFinder}}

There are still hangs caused by dynamic type registration, investigating.

> .NET: Examples tests hang
> -
>
> Key: IGNITE-4906
> URL: https://issues.apache.org/jira/browse/IGNITE-4906
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> {{ExamplesTest}} hangs on various stages: 
> http://195.239.208.174/viewType.html?buildTypeId=IgniteTests_IgnitePlatformNetLongRunnin
> Logs show many multicast-related exceptions. We should probably avoid 
> multicast in tests.



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

[jira] [Comment Edited] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev edited comment on IGNITE-4477 at 4/4/17 8:21 AM:
-

Vladimir, please review the fix: [PR 
1721|https://github.com/apache/ignite/pull/1721]

Instead of two async methods for listen and chain I've added one with nullable 
Executor. I don't think we need to duplicate methods just without last argument.

Here is a link to upsource: 
[IGNT-CR-156|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-156]


was (Author: dkarachentsev):
Vladimir, please review the fix: [PR 
1710|https://github.com/apache/ignite/pull/1710]

Instead of two async methods for listen and chain I've added one with nullable 
Executor. I don't think we need to duplicate methods just without last argument.

Here is a link to upsource: 
[IGNT-CR-151|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-151]

> Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
> 
>
> Key: IGNITE-4477
> URL: https://issues.apache.org/jira/browse/IGNITE-4477
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> *Problem*
> We allow users to pass continuations to {{IgniteFuture}} which will be 
> executed on future completion. This can be done through {{listen}} or 
> {{chain}} methods.
> However, continuation semantics is broken intrinsically:
> 1) If future is already completed, user code executed in the same thread;
> 2) If future is not completed yet, it will be executed in completion thread.
> Neither of this options are valid because it easily leads to starvation. E.g.:
> {code}
> IgniteFuture fut = cache.getAsync(key2);
> fut.listen(fut0 -> {
>  cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
> });
> {code}
> *Solution*
> 1) By default callbacks must be executed asynchronously in some common pool 
> (public pool? new "callback pool"? FJP?)
> 2) It should be possible to specify where to execute a callback explicitly:
> {code}
> IgniteFuture.listen(IgniteClosure, ExecutorService);
> {code}
> 3) We may want to expose our public pool on API for convenience.



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

[jira] [Assigned] (IGNITE-4871) Web console: Implement possibility to configure Kubernetes IP finder

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-4871:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Web console: Implement possibility to configure Kubernetes IP finder
> 
>
> Key: IGNITE-4871
> URL: https://issues.apache.org/jira/browse/IGNITE-4871
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4871) Web console: Implement possibility to configure Kubernetes IP finder

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4871:


Please fix version of kubernetes dependency

> Web console: Implement possibility to configure Kubernetes IP finder
> 
>
> Key: IGNITE-4871
> URL: https://issues.apache.org/jira/browse/IGNITE-4871
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>




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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4625:


Github user ptupitsyn closed the pull request at:

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


> .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
>  Labels: .NET
> Fix For: 2.0
>
>
> 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.15#6346)

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4625.

Resolution: Fixed

> .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
>  Labels: .NET
> Fix For: 2.0
>
>
> 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.15#6346)

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4625:


* Fix {{PlatformStopIgniteTask}} to prefer local node
* Fix nodes stop in {{AbstractTaskTest}}
* Remove {{MixedClusterTest.TestScanQuery}} since it does not provide much 
value and can cause failed node shutdown

> .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
>  Labels: .NET
> Fix For: 2.0
>
>
> 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.15#6346)

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4625 at 4/4/17 8:05 AM:


* Fix {{PlatformStopIgniteTask}} to prefer local node
* Fix nodes stop in {{AbstractTaskTest}}
* Remove {{MixedClusterTest.TestScanQuery}} since it does not provide much 
value and can cause failed node shutdown

Merged to master.


was (Author: ptupitsyn):
* Fix {{PlatformStopIgniteTask}} to prefer local node
* Fix nodes stop in {{AbstractTaskTest}}
* Remove {{MixedClusterTest.TestScanQuery}} since it does not provide much 
value and can cause failed node shutdown

> .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
>  Labels: .NET
> Fix For: 2.0
>
>
> 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.15#6346)

[jira] [Commented] (IGNITE-3582) CPP: Replace pointers with references in function signatures where it's possible.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3582:


Looks good. Seems like a proper API update.

> CPP: Replace pointers with references in function signatures where it's 
> possible.
> -
>
> Key: IGNITE-3582
> URL: https://issues.apache.org/jira/browse/IGNITE-3582
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> Replace passing arguments by pointers with passing by references where it's 
> possible. Places to look at:
> {{BinaryMapReader::GetNext}}.
> The following argument: {{IgniteError* err}}.



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

[jira] [Assigned] (IGNITE-4889) Replacement of Cache Key classes with fields not participating in equals operation

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin reassigned IGNITE-4889:
--

Assignee: Dmitriy Govorukhin

> Replacement of Cache Key classes with fields not participating in equals 
> operation
> --
>
> Key: IGNITE-4889
> URL: https://issues.apache.org/jira/browse/IGNITE-4889
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Dmitriy Govorukhin
>
> h2. Notes
> Having key classes with fields not participating in *equals* operation leads 
> to errors when handling them in B+Tree data structures.
> It is discussed here in more details: [dev-list 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html]
> h2. Acceptance Criteria
> # All classes known to have such flaw are replaced at run time to use them 
> safely within B+Tree.
> # All tests marked with this issue number are passing.
> h2. Out-of-scope
> *BinaryIdentityResolver* approach is deprecated when solution described above 
> is implemented and proven to be working.



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