[jira] [Updated] (IGNITE-4450) Explicit lock is not released when node that acquired it is killed

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-4450:

Attachment: ExplicitLockTest.java

> Explicit lock is not released when node that acquired it is killed
> --
>
> Key: IGNITE-4450
> URL: https://issues.apache.org/jira/browse/IGNITE-4450
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.9
>
> Attachments: ExplicitLockTest.java
>
>
> Test is attached. The scenario is the following:
> # Start first node and create a transactional cache.
> # Start second node and acquire a lock.
> # Kill second node after several seconds without doing unlock.
> # Try to start third node. It can't join because the lock is still held for 
> some reason. The result if hanged cluster.



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

[jira] [Created] (IGNITE-4450) Explicit lock is not released when node that acquired it is killed

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4450:
---

 Summary: Explicit lock is not released when node that acquired it 
is killed
 Key: IGNITE-4450
 URL: https://issues.apache.org/jira/browse/IGNITE-4450
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 1.9


Test is attached. The scenario is the following:
# Start first node and create a transactional cache.
# Start second node and acquire a lock.
# Kill second node after several seconds without doing unlock.
# Try to start third node. It can't join because the lock is still held for 
some reason. The result if hanged cluster.



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

[jira] [Commented] (IGNITE-3867) ScanQuery ignores pageSize propertry

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-3867:
--

[~ntikhonov],
I've no idea how we can test this. We can't add any event listener to check 
that number of pages received and we have no metrics with pages counter.
PageSize is used in GridCacheQueryFutureAdapter, but how we can check the 
pageSize value pass into it?

> ScanQuery ignores pageSize propertry
> 
>
> Key: IGNITE-3867
> URL: https://issues.apache.org/jira/browse/IGNITE-3867
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Andrew Mashenkov
>
> See 
> {{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
>  IgniteClosure, ClusterGroup)}} method. 
> In this place we loose page size which set by user and use default value:
> {{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(), 
> isKeepBinary)}}



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

[jira] [Updated] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3514:

Assignee: (was: Igor Sapego)

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,594][SEVERE][main][IgniteKernal%grid-0] Failed to stop component 
> (ignoring): GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> 

[jira] [Assigned] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-3514:
---

Assignee: Igor Sapego

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,594][SEVERE][main][IgniteKernal%grid-0] Failed to stop component 
> (ignoring): GridManagerAdapter [enabled=true, 
> 

[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3514:


Merged to master.

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,594][SEVERE][main][IgniteKernal%grid-0] Failed to stop component 
> (ignoring): GridManagerAdapter 

[jira] [Comment Edited] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4441 at 12/16/16 4:20 PM:
--

On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of {{IPluginProvider}} implementations 
via {{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control. 

We can combine this with {{IgniteConfiguration.PluginConfigurations}}, so that 
plugin author provides {{IPluginConfiguration}} implementation with 
{{PluginProviderType}} property already set.


was (Author: ptupitsyn):
On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of {{IPluginProvider}} implementations 
via {{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control.

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Resolved] (IGNITE-2412) Synchronous atomic ops should not call GridDhtAtomicCache.asyncOp

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-2412.
--
Resolution: Fixed

Did some refactoring in GridCacheAdapter/GridDhtAtomicCache so that now we do 
not call 'asyncOp' for synchronous operations.

> Synchronous atomic ops should not call GridDhtAtomicCache.asyncOp
> -
>
> Key: IGNITE-2412
> URL: https://issues.apache.org/jira/browse/IGNITE-2412
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 2.0
>
>
> GridDhtAtomicCache.asyncOp is needed to limit number of asynchronous 
> operations, but now implementation of synchronous operations calls 
> asynchronous counterpart (i.e. 'put' calls 'putAsync').



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

[jira] [Comment Edited] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4441 at 12/16/16 4:22 PM:
--

On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of {{IPluginProvider}} implementations 
via {{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control. 

We can combine this with {{IgniteConfiguration.PluginConfigurations}}, so that 
plugin author provides {{IPluginConfiguration}} implementation with mandatory 
{{PluginProviderFactory}} property.


was (Author: ptupitsyn):
On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of {{IPluginProvider}} implementations 
via {{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control. 

We can combine this with {{IgniteConfiguration.PluginConfigurations}}, so that 
plugin author provides {{IPluginConfiguration}} implementation with 
{{PluginProviderType}} property already set.

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Comment Edited] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4441 at 12/16/16 4:17 PM:
--

On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of {{IPluginProvider}} implementations 
via {{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control.


was (Author: ptupitsyn):
On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of PluginProvider classes via 
{{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control.

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Commented] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4441:


On the second thought, we should not examine all DLLs in the folder.
* Scanning all assemblies in a folder is unsafe and slow
* User may want to load specific plugins only, or decide dynamically which ones 
should be loaded

So the proper way is to specify a list of PluginProvider classes via 
{{ICollection IgniteConfiguration.Plugins}}.
This requires one extra step from the user, but allows precise control.

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Commented] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4441:


Sure, I've outlined the general logic only in the description.

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Commented] (IGNITE-4378) Affinity function should support assigning partition to subset of cluster nodes

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4378:
---

Linked related issue https://issues.apache.org/jira/browse/IGNITE-4448

> Affinity function should support assigning partition to subset of cluster 
> nodes
> ---
>
> Key: IGNITE-4378
> URL: https://issues.apache.org/jira/browse/IGNITE-4378
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Alexei Scherbakov
> Fix For: 2.0
>
>
> Currently both default affinity function(AF) implementations randomly choose 
> primary node among all topology nodes.
> This may not be enough to handle complex data placement scenarios without 
> implementing own AF.
> On example, some partitions can be assigned to more powerful hardware, or 
> limited to subset of cluster nodes due to ease of management or fault 
> tolerance scenarios.
> We should implement node filter, which will allow to choose subset of cluster 
> nodes to place primary and backup partitions.
> With already existing ability to filter backup nodes (using 
> {{AffinityBackupFilter}}) it will allow to implement different approaches to 
> data placement with Ignite without resorting to custom AF.
> It's also desirable to include a practical example of both topology filters 
> based on node attribute values.
> Proposed primary filter interface is below.
> {noformat}
> /**
>  * Allows partition placement to subset of cluster node.
>  *
>  * Backup nodes also will be assigned from the subset.
>  */
> public interface AffinityPrimaryFilter extends IgniteBiClosure List, List> {
> /**
>  * Return nodes allowed to contain given partition.
>  * @param partition Partition.
>  * @param currentTopologyNodes All nodes from current topology.
>  * @return Subset of nodes.
>  */
> @Override public List apply(Integer partition, 
> List currentTopologyNodes);
> }
> {noformat}



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

[jira] [Created] (IGNITE-4448) Implement correct affinity validation on joining topology.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4448:
-

 Summary: Implement correct affinity validation on joining topology.
 Key: IGNITE-4448
 URL: https://issues.apache.org/jira/browse/IGNITE-4448
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2,0


Currently on joining a topology only affinity class name and partition number 
are checked between configurations of local and remote nodes.

This is not enough in case of configured backup filter and possible extension 
with primary filter and can lead to disastrous situations due to node 
misconfiguration.

We should implement something like {{AffinityValidator}} having signature as 
follows:

{noformat}
boolean validate(Affinity affinity)
{noformat}

Maybe it'll be useful for other grid objects as well, like 
{{CacheStore}},{{NodeFilter}}, etc.









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

[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3514:


Looks good, see minor comment.

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,594][SEVERE][main][IgniteKernal%grid-0] Failed to stop component 
> (ignoring): 

[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov edited comment on IGNITE-4157 at 12/16/16 3:14 PM:
---

Received some comments on review including (from major to minor):
* *DiscoveryDataContainer* is part of public API but exposes some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in GridFutureAdapter specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

Working on addressing them.


was (Author: sergey-chugunov):
Received some comments on review including (from major to minor):
* DiscoveryDataContainer is part of public API but expresses some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in GridFutureAdapter specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

Working on addressing them.

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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

[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov edited comment on IGNITE-4157 at 12/16/16 3:14 PM:
---

Received some comments on review including (from major to minor):
* *DiscoveryDataContainer* is part of public API but exposes some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in *GridFutureAdapter* specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

Working on addressing them.


was (Author: sergey-chugunov):
Received some comments on review including (from major to minor):
* *DiscoveryDataContainer* is part of public API but exposes some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in GridFutureAdapter specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

Working on addressing them.

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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

[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov edited comment on IGNITE-4157 at 12/16/16 3:12 PM:
---

Received some comments on review including (from major to minor):
* DiscoveryDataContainer is part of public API but expresses some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in GridFutureAdapter specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

Working on addressing them.


was (Author: sergey-chugunov):
Received some comments on review including (from major to minor):
* DiscoveryDataContainer is part of public API but expresses some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in GridFutureAdapter specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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

[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4157:
-

Received some comments on review including (from major to minor):
* DiscoveryDataContainer is part of public API but expresses some internal 
concepts through its interface;
* Mappings should be persisted outside of discovery thread;
* Managing map used for synchronization of mappings distribution should be done 
in GridFutureAdapter specialized subclass;
* It is more efficient for client to request missed mappings 
(*MissingMappingRequest/ResponseMessage*) using communication instead of 
discovery messages;
* *MessageRejectedMessage* may not be necessary, figuring out if I can get rid 
of additional pass of this message;

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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

[jira] [Updated] (IGNITE-4371) Neat TX finish request processing may fall into sync wait of dht finish response

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-4371:
-
Fix Version/s: 2.0

> Neat TX finish request processing may fall into sync wait of dht finish 
> response
> 
>
> Key: IGNITE-4371
> URL: https://issues.apache.org/jira/browse/IGNITE-4371
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
> Fix For: 2.0
>
>
> After fixing this please remove TODO and put proper partition ID to 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxFinishResponse#partition
> {noformat}
> Thread 
> [name="sys-stripe-1-#30%dht.GridCacheColocatedTxExceptionSelfTest1%", id=46, 
> state=WAITING, blockCnt=0, waitCnt=7]
> Lock 
> [object=o.a.i.i.processors.cache.distributed.dht.GridDhtTxFinishFuture@212874c9,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxFinishFuture.onError(GridDhtTxFinishFuture.java:183)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.finishCommit(GridDhtTxLocal.java:543)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.commitAsync(GridDhtTxLocal.java:580)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:849)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:728)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:687)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:157)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:155)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:758)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:363)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:287)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:89)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:232)
> at 
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1212)
> at 
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:840)
> at 
> o.a.i.i.managers.communication.GridIoManager.access$2100(GridIoManager.java:110)
> at 
> o.a.i.i.managers.communication.GridIoManager$6.run(GridIoManager.java:785)
> at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:362)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}



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

[jira] [Commented] (IGNITE-4371) Neat TX finish request processing may fall into sync wait of dht finish response

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-4371:
--

Fixed problem with synchronous rollback in GridNearTxFinishFuture.onDone and in 
GridDhtTxFinishFuture.onError.

> Neat TX finish request processing may fall into sync wait of dht finish 
> response
> 
>
> Key: IGNITE-4371
> URL: https://issues.apache.org/jira/browse/IGNITE-4371
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
>
> After fixing this please remove TODO and put proper partition ID to 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxFinishResponse#partition
> {noformat}
> Thread 
> [name="sys-stripe-1-#30%dht.GridCacheColocatedTxExceptionSelfTest1%", id=46, 
> state=WAITING, blockCnt=0, waitCnt=7]
> Lock 
> [object=o.a.i.i.processors.cache.distributed.dht.GridDhtTxFinishFuture@212874c9,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxFinishFuture.onError(GridDhtTxFinishFuture.java:183)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.finishCommit(GridDhtTxLocal.java:543)
> at 
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.commitAsync(GridDhtTxLocal.java:580)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:849)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:728)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:687)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:157)
> at 
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:155)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:758)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:363)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:287)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:89)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:232)
> at 
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1212)
> at 
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:840)
> at 
> o.a.i.i.managers.communication.GridIoManager.access$2100(GridIoManager.java:110)
> at 
> o.a.i.i.managers.communication.GridIoManager$6.run(GridIoManager.java:785)
> at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:362)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}



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

[jira] [Commented] (IGNITE-4391) Web Console: Implement grouping by company in Admin panel

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin commented on IGNITE-4391:
--

Rework on users table

> Web Console: Implement grouping by company in Admin panel
> -
>
> Key: IGNITE-4391
> URL: https://issues.apache.org/jira/browse/IGNITE-4391
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
>Assignee: Dmitriy Shabalin
> Fix For: 2.0
>
>
> It will be useful to have different view on same data:
> # list by name (current)
> # group by company
> # group by country



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

[jira] [Created] (IGNITE-4447) Remove "Ignite 150 Clients" suite.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4447:
---

 Summary: Remove "Ignite 150 Clients" suite.
 Key: IGNITE-4447
 URL: https://issues.apache.org/jira/browse/IGNITE-4447
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 2.0


It has only 1 tests. It runs for ~1m, but takes ~6m including build phase. 
Let's just embed it into one of cache suites.



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

[jira] [Commented] (IGNITE-3537) Add tests checking that data structures work inside user transactions

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3537:
--

Some more details:
implementation of ignite data structures internally uses special system caches, 
need make sure that transaction on these system caches do not intersect with 
transactions stared by user. Test pseudo-code (also 
GridCachePartitionedAtomicSequenceTxSelfTest.testIsolation can be used as 
example):
{noformat}
IgniteAtomicLong atomicLong = ignite.atomicLong();

try (Transaction tx = ignite(0).transactions().txStart()) {
atomicLong.incrementAndGet();

cache.put(1, 1);

tx.rollback();
}

assertEquals(1L, atomicLong.get()); // Tx was rolled back, but 
IgniteAtomicLong increment should be committed.
{noformat}

Need add tests for IgniteSet, IgniteQueue, IgniteSemaphore, IgniteLock, 
IgniteCountDownLatch, IgniteAtomicStamped, IgniteAtomicReference, 
IgniteAtomicLong. We already have test classes for all these data structures 
(e.g. IgniteAtomicLongApiAbstractSelfTest), need just add new testcases into 
these class.

> Add tests checking that data structures work inside user transactions
> -
>
> Key: IGNITE-3537
> URL: https://issues.apache.org/jira/browse/IGNITE-3537
> Project: Ignite
>  Issue Type: Task
>  Components: data structures
>Reporter: Semen Boikov
>Assignee: Milap Wadhwa
>Priority: Minor
>  Labels: newbie
>
> Need create tests to check that Ignite data structures work inside user 
> transaction. Now data structures should use independent transactions, test 
> should jus check that there are no exceptions.



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

[jira] [Commented] (IGNITE-4446) Split query tests into unit tests and failover/concurrency tests.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4446:


GitHub user devozerov opened a pull request:

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

IGNITE-4446



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

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

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

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


commit 36505a9196f388e36293ad70cae0873699644969
Author: devozerov 
Date:   2016-12-16T14:11:36Z

Re-grouped tests.

commit 8f79ebbeab3eadd2ce92abe5ef32b2109e34485f
Author: devozerov 
Date:   2016-12-16T14:14:52Z

Re-grouped tests.




> Split query tests into unit tests and failover/concurrency tests.
> -
>
> Key: IGNITE-4446
> URL: https://issues.apache.org/jira/browse/IGNITE-4446
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4446) Split query tests into unit tests and failover/concurrency tests.

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-4446:
--

Aslo it makes sense to separate suites for sql queries, scan queries, 
continuous queries.

> Split query tests into unit tests and failover/concurrency tests.
> -
>
> Key: IGNITE-4446
> URL: https://issues.apache.org/jira/browse/IGNITE-4446
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>




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

[jira] [Assigned] (IGNITE-2793) ODBC: Add support for Arrays.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-2793:
--

Assignee: Sergey Kalashnikov

> ODBC: Add support for Arrays.
> -
>
> Key: IGNITE-2793
> URL: https://issues.apache.org/jira/browse/IGNITE-2793
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Sergey Kalashnikov
>  Labels: roadmap
>
> Support for arrays should be added. We need to at least support byte arrays 
> to match {{SQL_C_BINARY}} type.



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

[jira] [Created] (IGNITE-4446) Split query tests into unit tests and failover/concurrency tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4446:
---

 Summary: Split query tests into unit tests and 
failover/concurrency tests.
 Key: IGNITE-4446
 URL: https://issues.apache.org/jira/browse/IGNITE-4446
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 2.0






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

[jira] [Comment Edited] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Igor Sapego (JIRA)]

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

Igor Sapego edited comment on IGNITE-3514 at 12/16/16 1:26 PM:
---

Pavel, OK, I did not describe an issue and solution yesterday, this is my fault.

The issue is that we tried to delete the same value twice on failure - first in 
{{IgniteEnvironment}}, when receiving {{ON_STOP}} message from Java, and then 
in "else" branch, which handles node start failure. So I have removed the 
second delete, which solved the issue.

You are also right about the test. I'm going to add it.


was (Author: isapego):
Pavel, OK, I did not describe an issue and solution yesterday, this is my fault.

The issue is that we tried to delete the same value twice on failure - first in 
{{IgniteEnvironment}}, when receiving `ON_STOP` message from Java, and then in 
"else" branch, which handles node start failure. So I have removed the second 
delete, which solved the issue.

You are also right about the test. I'm going to add it.

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> 

[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3514:
-

Pavel, OK, I did not describe an issue and solution yesterday, this is my fault.

The issue is that we tried to delete the same value twice on failure - first in 
{{IgniteEnvironment}}, when receiving `ON_STOP` message from Java, and then in 
"else" branch, which handles node start failure. So I have removed the second 
delete, which solved the issue.

You are also right about the test. I'm going to add it.

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> 

[jira] [Closed] (IGNITE-4249) ODBC: Even simple request takes a lot of time.

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4249.
---

> ODBC: Even simple request takes a lot of time.
> --
>
> Key: IGNITE-4249
> URL: https://issues.apache.org/jira/browse/IGNITE-4249
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> Even if you submit very simple request with {{SQLExecute}} on a small data 
> set, it's going to take ~40ms to be processed, while the same request in C++ 
> client takes ~200us.



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

[jira] [Closed] (IGNITE-4227) ODBC: Implement SQLError function

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4227.
---

> ODBC: Implement SQLError function
> -
>
> Key: IGNITE-4227
> URL: https://issues.apache.org/jira/browse/IGNITE-4227
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>  Labels: odbc
> Fix For: 1.8
>
>
> Some driver managers use this function even though {{SQLGetDiagRec}} was 
> called.



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

[jira] [Closed] (IGNITE-4132) .NET: Binary configuration related improvements

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4132.
---

> .NET: Binary configuration related improvements
> ---
>
> Key: IGNITE-4132
> URL: https://issues.apache.org/jira/browse/IGNITE-4132
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> - If you register an object in BinaryConfiguration in C# code using object’s 
> type name then it must be a full name like typeof(Account).FullName. Document 
> this.
> - https://apacheignite-net.readme.io/docs/serialization#ibinarizable . No 
> example on how to register the class in App.config file



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

[jira] [Closed] (IGNITE-4216) .NET: PlatformAffinityFunction does not inject resource into baseFunc

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4216.
---

> .NET: PlatformAffinityFunction does not inject resource into baseFunc
> -
>
> Key: IGNITE-4216
> URL: https://issues.apache.org/jira/browse/IGNITE-4216
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.8
>
>
> PlatformAffinityFunction does not inject resource into baseFunc. This causes 
> NPE within RendezvousAffinityFunction:
> * start multiple nodes
> * start a new cache with RendezvousAffinityFunction



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

[jira] [Resolved] (IGNITE-4407) IgniteUuid is a single point of contention for the whole framework.

[Vladimir Ozerov (JIRA)]

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

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

No gain. Closing for now.

> IgniteUuid is a single point of contention for the whole framework.
> ---
>
> Key: IGNITE-4407
> URL: https://issues.apache.org/jira/browse/IGNITE-4407
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> It uses static {{AtomicLong.incrementAndGet}}. We can use thread-locals to 
> minimize contention.
> Similar problem is in {{GridCacheIoManager}} and {{GridCacheMvccCandidate}}.



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

[jira] [Closed] (IGNITE-4407) IgniteUuid is a single point of contention for the whole framework.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4407.
---

> IgniteUuid is a single point of contention for the whole framework.
> ---
>
> Key: IGNITE-4407
> URL: https://issues.apache.org/jira/browse/IGNITE-4407
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> It uses static {{AtomicLong.incrementAndGet}}. We can use thread-locals to 
> minimize contention.
> Similar problem is in {{GridCacheIoManager}} and {{GridCacheMvccCandidate}}.



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

[jira] [Closed] (IGNITE-4134) .NET: Expiration policy related improvements

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4134.
---

> .NET: Expiration policy related improvements
> 
>
> Key: IGNITE-4134
> URL: https://issues.apache.org/jira/browse/IGNITE-4134
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> There are two things to pay attention to right now:
> - It's not possible to set an expiration policy globally for a cache at the 
> level of C# config and App.config.
>   
> - It's not clear that {{null}} should be used if the one wants to set eternal 
> expiration. This has to be documented.



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

[jira] [Closed] (IGNITE-4326) .NET: Rebuild in Visual Studio fails the first time

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4326.
---

> .NET: Rebuild in Visual Studio fails the first time
> ---
>
> Key: IGNITE-4326
> URL: https://issues.apache.org/jira/browse/IGNITE-4326
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.9
>
>
> Clean then Rebuild fails:
> {code}
> CS0234The type or namespace name 'Linq' does not exist in the 
> namespace 'Apache.Ignite' (are you missing an assembly reference?)  
> Apache.Ignite.Examples  
> C:\W\incubator-ignite\modules\platforms\dotnet\Examples\Apache.Ignite.Examples\Datagrid\LinqExample.cs
> {code}
> Consequent build succeeds.
> Looks like a missing build dependency.



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

[jira] [Created] (IGNITE-4445) Test suites improvements

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4445:
---

 Summary: Test suites improvements
 Key: IGNITE-4445
 URL: https://issues.apache.org/jira/browse/IGNITE-4445
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.0


This is an umbrella ticket for various improvement on Ignite test suites.



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

[jira] [Commented] (IGNITE-4139) .NET: improve the getting started guide

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4139:


Paths fixed, download link updated.
I've removed some sections related to Apache.Ignite.exe from {{Getting 
Started}} because this information is present on {{Standalone Nodes}} page.

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Resolved] (IGNITE-4139) .NET: improve the getting started guide

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4139.

Resolution: Fixed
  Assignee: (was: Pavel Tupitsyn)

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Commented] (IGNITE-4441) Define plugin API in .NET

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4441:
-

Pavel,

Please note that we must not only call a single "start" method, but rather 
wire-up the plugin with general start lifecycle: 
- onStart
- onIgniteStart
- onIgniteStop
- onStop

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Closed] (IGNITE-4117) .NET: after the reconnection client fails while trying to get a reference to a cache

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4117.
---

> .NET: after the reconnection client fails while trying to get a reference to 
> a cache
> 
>
> Key: IGNITE-4117
> URL: https://issues.apache.org/jira/browse/IGNITE-4117
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> In the following example 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs
> we deliberately added these lines of the code
> {code}
> while (!task.IsCompleted) // workaround.
> task.Wait();
> Console.WriteLine(">>> Client has reconnected 
> successfully");
> //Workaround.
> System.Threading.Thread.Sleep(3000);
> {code}
> because otherwise after the clients successfully reconnects to the cluster it 
> expects different issues that prevent from using it. In particular, the 
> example will throw cache related exception at the next line but this mustn't 
> happen
> {code}
> // Updating the reference to the cache. The 
> client reconnected to the new cluster.
> cache = ignite.GetOrCreateCache string>(CacheName);
> {code} 
> Step to reproduce:
> - Start remote .NET node;
> - Start the example;
> - Restart the remote node.
> The issue is 100% reproducible on my VirtualBox Windows 8.1 machine.



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

[jira] [Resolved] (IGNITE-4262) Hadoop Accelerator performance improvements.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4262.
-
Resolution: Fixed

> Hadoop Accelerator performance improvements.
> 
>
> Key: IGNITE-4262
> URL: https://issues.apache.org/jira/browse/IGNITE-4262
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>




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

[jira] [Comment Edited] (IGNITE-4139) .NET: improve the getting started guide

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova edited comment on IGNITE-4139 at 12/16/16 10:56 AM:


1) FULL DISTRIBUTION section: it's not obvious that I should download Binary 
Release rather than Source Release. Please, clarify.

2) {quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available under modules\platforms\dotnet\bin folder which does not 
require you to build the binaries only for the purpose of starting a new node
{quote}
Path is incorrect (there is no {{modules}} direcoty in binary distribution). 
Also it would be more clear if you metion that this is about binary release. 
Suggest rephrasing to something like
{quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available in binary release under platforms\dotnet\bin folder which 
does not require you to build the binaries only for the purpose of starting a 
new node
{quote}


was (Author: krybakova):
1) FULL DISTRIBUTION section: it's not obvious that I should download Binary 
Release rather than Source Release. Please, clarify.

2) {quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available under modules\platforms\dotnet\bin folder which does not 
require you to build the binaries only for the purpose of starting a new node
{quote}
Path is incorrect (there is no {{modules}} direcoty in binary distribution). 
Also it would be more clear if you metion that this is aboute binary release. 
Suggest rephrasing to something like
{quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available in binary release under platforms\dotnet\bin folder which 
does not require you to build the binaries only for the purpose of starting a 
new node
{quote}

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Comment Edited] (IGNITE-4139) .NET: improve the getting started guide

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova edited comment on IGNITE-4139 at 12/16/16 10:54 AM:


1) FULL DISTRIBUTION section: it's not obvious that I should download Binary 
Release rather than Source Release. Please, clarify.

2) {quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available under modules\platforms\dotnet\bin folder which does not 
require you to build the binaries only for the purpose of starting a new node
{quote}
Path is incorrect (there is no {{modules}} direcoty in binary distribution). 
Also it would be more clear if you metion that this is aboute binary release. 
Suggest rephrasing to something like
{quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available in binary release under platforms\dotnet\bin folder which 
does not require you to build the binaries only for the purpose of starting a 
new node
{quote}


was (Author: krybakova):
1) FULL DISTRIBUTION section: it's not obvious that I should download Binary 
Release rather than Source Release. Please, clarify.

2) {quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available under modules\platforms\dotnet\bin folder which does not 
require you to build the binaries only for the purpose of starting a new node
{quote}
Path is incorrect (there is no modules direcoty in binary distribution). Also 
it would be more clear if you metion that this is aboute binary release. 
Suggest rephrasing to something like
{quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available in binary release under platforms\dotnet\bin folder which 
does not require you to build the binaries only for the purpose of starting a 
new node
{quote}

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Reopened] (IGNITE-4139) .NET: improve the getting started guide

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova reopened IGNITE-4139:
-
  Assignee: Pavel Tupitsyn

1) FULL DISTRIBUTION section: it's not obvious that I should download Binary 
Release rather than Source Release. Please, clarify.

2) {quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available under modules\platforms\dotnet\bin folder which does not 
require you to build the binaries only for the purpose of starting a new node
{quote}
Path is incorrect (there is no modules direcoty in binary distribution). Also 
it would be more clear if you metion that this is aboute binary release. 
Suggest rephrasing to something like
{quote}
Alternatively, you can start a node using the Apache.Ignite.exe file that is 
already available in binary release under platforms\dotnet\bin folder which 
does not require you to build the binaries only for the purpose of starting a 
new node
{quote}

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-:
---
Description: Plugin authors should be able to interact with Java part of 
the plugin: call .NET->Java and Java->.NET.

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



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-:
---
Summary: Extend .NET plugin API to interact with Java  (was: Extend plugin 
API to interact with Java)

> Extend .NET plugin API to interact with Java
> 
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>




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

[jira] [Created] (IGNITE-4444) Extend plugin API to interact with Java

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-:
--

 Summary: Extend plugin API to interact with Java
 Key: IGNITE-
 URL: https://issues.apache.org/jira/browse/IGNITE-
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0






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

[jira] [Created] (IGNITE-4443) .NET: doc for 1.7: there is no TransactionDeadlockException class

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-4443:
---

 Summary: .NET: doc for 1.7: there is no 
TransactionDeadlockException class
 Key: IGNITE-4443
 URL: https://issues.apache.org/jira/browse/IGNITE-4443
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 1.7
Reporter: Ksenia Rybakova
Priority: Minor


https://apacheignite-net.readme.io/v1.7/docs/transactions#deadlock-detection-in-pessimistic-transactions
 mentions TransactionDeadlockException class, but this class is absent in 1.7 
version.

Please, make corresponding corrections. 



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

[jira] [Updated] (IGNITE-4443) .NET: doc for 1.7: there is no TransactionDeadlockException class

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-4443:

Description: 
https://apacheignite-net.readme.io/v1.7/docs/transactions#deadlock-detection-in-pessimistic-transactions
 mentions TransactionDeadlockException, but this class is absent in 1.7 version.

Please, make corresponding corrections. 

  was:
https://apacheignite-net.readme.io/v1.7/docs/transactions#deadlock-detection-in-pessimistic-transactions
 mentions TransactionDeadlockException class, but this class is absent in 1.7 
version.

Please, make corresponding corrections. 


> .NET: doc for 1.7: there is no TransactionDeadlockException class
> -
>
> Key: IGNITE-4443
> URL: https://issues.apache.org/jira/browse/IGNITE-4443
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Priority: Minor
>
> https://apacheignite-net.readme.io/v1.7/docs/transactions#deadlock-detection-in-pessimistic-transactions
>  mentions TransactionDeadlockException, but this class is absent in 1.7 
> version.
> Please, make corresponding corrections. 



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

[jira] [Updated] (IGNITE-4442) Web console: Implement configuration of affinity function in cache configuration.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-4442:
--
Description: Also implement custom configuration of cache store.

> Web console: Implement configuration of affinity function in cache 
> configuration.
> -
>
> Key: IGNITE-4442
> URL: https://issues.apache.org/jira/browse/IGNITE-4442
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.9
>
>
> Also implement custom configuration of cache store.



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

[jira] [Created] (IGNITE-4442) Web console: Implement configuration of affinity function in cache configuration.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-4442:
-

 Summary: Web console: Implement configuration of affinity function 
in cache configuration.
 Key: IGNITE-4442
 URL: https://issues.apache.org/jira/browse/IGNITE-4442
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.9
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
 Fix For: 1.9






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

[jira] [Updated] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4441:
---
Description: 
Define plugin API in .NET similar to Java API:
* {{IgniteConfiguration.PluginConfigurations}}
* {{CacheConfiguration.PluginConfigurations}}
* {{IPluginProvider}}
* {{ICachePluginProvider}}
* {{IPluginContext}}
* {{ICachePluginContext}}

Should work like this:
* Plugin author implements {{IPluginProvider}}
* We discover plugins on Ignite start by examining all DLL files in the folder, 
load DLLs where {{IPluginProvider}} implementations are present, instantiate 
these implementations, and call {{IPluginProvider.Start(IPluginContext)}} 
method.
* Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, or 
via helper extension method provided by plugin author.

This task does not include the possibility to interact with Java from the 
plugin code.

  was:
Define plugin API in .NET similar to Java API:
* {{IgniteConfiguration.PluginConfigurations}}
* {{CacheConfiguration.PluginConfigurations}}
* {{IPluginProvider}}
* {{ICachePluginProvider}}
* {{IPluginContext}}
* {{ICachePluginContext}}

Should work like this:
* Plugin author implements {{IPluginProvider}}
* We discover plugins on Ignite start by examining all DLL files in the folder, 
load DLLs where {{IPluginProvider}} implementations are present, instantiate 
these implementations, and call {{IPluginProvider.Start(IPluginContext)}} method
* Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, or 
via helper extension method provided by plugin author.


> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{CacheConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{ICachePluginProvider}}
> * {{IPluginContext}}
> * {{ICachePluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Created] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4441:
--

 Summary: Define plugin API in .NET
 Key: IGNITE-4441
 URL: https://issues.apache.org/jira/browse/IGNITE-4441
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


Define plugin API in .NET similar to Java API:
* {{IgniteConfiguration.PluginConfigurations}}
* {{CacheConfiguration.PluginConfigurations}}
* {{IPluginProvider}}
* {{ICachePluginProvider}}
* {{IPluginContext}}
* {{ICachePluginContext}}

Should work like this:
* Plugin author implements {{IPluginProvider}}
* We discover plugins on Ignite start by examining all DLL files in the folder, 
load DLLs where {{IPluginProvider}} implementations are present, instantiate 
these implementations, and call {{IPluginProvider.Start(IPluginContext)}} method
* Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, or 
via helper extension method provided by plugin author.



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-3710:
--

Alexey, we have 160 transitive dependencies at spark module according to maven 
report.

I found that addition of 

{noformat}
   
org.apache.spark
spark-catalyst_2.11
${spark.version}



org.apache.hadoop
hadoop-client
${hadoop.version}

{noformat}

starts fixing of issues.
I'll continue to detect required libs, but main question is how it worked 
before (for spark 1.x) without any transitive dependencies.

> 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: Anton Vinogradov
>Priority: Critical
> 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.4#6332)

[jira] [Resolved] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4422.

Resolution: Won't Fix

> Define platform plugin API in Java
> --
>
> Key: IGNITE-4422
> URL: https://issues.apache.org/jira/browse/IGNITE-4422
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> * Move {{PlatformTarget}} to public package org.apache.ignite.platform
> * Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
> {{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
> User should be able to add {{PlatformPluginConfiguration}} to 
> {{PlatformConfiguration}}.



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

[jira] [Assigned] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-3514:
--

Assignee: Igor Sapego  (was: Pavel Tupitsyn)

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,594][SEVERE][main][IgniteKernal%grid-0] Failed to stop component 
> (ignoring): GridManagerAdapter [enabled=true, 

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

Oleg Ostanin commented on IGNITE-4212:
--

[~dmagda]
Thank you for your advise. I'v send the message. Meanwhile I'm working on 
module integration and documentation.

> Ignite Benchmarking Simplification and Automation
> -
>
> Key: IGNITE-4212
> URL: https://issues.apache.org/jira/browse/IGNITE-4212
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> There is a plenty of useful Yardstick benchmarks located in ignite-yardstick 
> module that is used by the community to check Ignite performance across 
> deployments of different configurations.
> However, it's not easy to start with the benchmarking process because the 
> user needs to download, build, set up and only after that run the benchmarks.
> 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 use some default yardstick configuration that 
> apparently should be AWS oriented.



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

[jira] [Commented] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4422:


We can use existing plugin infrastructure for platform plugins. The only 
difference platform plugins have is the ability to return {{PlatformTarget}} by 
request from native platform. This can be achieved by additional 
PlatformPluginProvider interface with one method.

> Define platform plugin API in Java
> --
>
> Key: IGNITE-4422
> URL: https://issues.apache.org/jira/browse/IGNITE-4422
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> * Move {{PlatformTarget}} to public package org.apache.ignite.platform
> * Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
> {{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
> User should be able to add {{PlatformPluginConfiguration}} to 
> {{PlatformConfiguration}}.



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

[jira] [Comment Edited] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3514 at 12/16/16 8:27 AM:
--

Not sure I understand exact problem and the fix. Is there a test to check that 
invalid configuration is handled gracefully?

> probably caused by the attempted call on some platform callback which is null 
> in C++
In such cases {{ThrowOnMissingHandler}} is called, so we would see that in the 
log.


was (Author: ptupitsyn):
Not sure I understand the fix. Is there a test to check that invalid 
configuration is handled gracefully?

> probably caused by the attempted call on some platform callback which is null 
> in C++
In such cases {{ThrowOnMissingHandler}} is called, so we would see that in the 
log.

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> 

[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3514:


Not sure I understand the fix. Is there a test to check that invalid 
configuration is handled gracefully?

> probably caused by the attempted call on some platform callback which is null 
> in C++
In such cases {{ThrowOnMissingHandler}} is called, so we would see that in the 
log.

> CPP: JVM crash on "Failed to start SPI" exception.
> --
>
> Key: IGNITE-3514
> URL: https://issues.apache.org/jira/browse/IGNITE-3514
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>  Labels: cpp
> Fix For: 2.0
>
>
> On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify 
> negative {{socketTimeout}}). This is probably caused by the attempted call on 
> some platform callback which is null in C++.
> {noformat}
> Failed to start manager: GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
> ... 9 more
> [15:17:45,584][SEVERE][main][IgniteKernal%grid-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:1576)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
> ... 7 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter 
> failed condition check: sockTimeout > 0
> at 
> org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
> at 
>