[jira] [Updated] (IGNITE-4450) Explicit lock is not released when node that acquired it is killed
[ 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 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] [Created] (IGNITE-4449) Document the usage of CacheKeyConfiguration
Denis Magda created IGNITE-4449: --- Summary: Document the usage of CacheKeyConfiguration Key: IGNITE-4449 URL: https://issues.apache.org/jira/browse/IGNITE-4449 Project: Ignite Issue Type: Task Components: documentation Reporter: Denis Magda {{CacheKeyConfiguration}} is used for scenarios when an affinity field has to be specified for a key. It's one of the alternatives to {{AffinityKeyMapped}} annotation. Needs to be documented on this page https://apacheignite.readme.io/docs/affinity-collocation And might be referred from some other pages (SQL Grid, PHP Guide, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3867) ScanQuery ignores pageSize propertry
[ https://issues.apache.org/jira/browse/IGNITE-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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] > j
[jira] [Assigned] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.
[ 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, > name=o.a.i.i.managers.disc
[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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): GridManager
[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15754909#comment-15754909 ] ASF GitHub Bot commented on IGNITE-3514: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1354 > 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][
[jira] [Comment Edited] (IGNITE-4441) Define plugin API in .NET
[ https://issues.apache.org/jira/browse/IGNITE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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): G
[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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 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.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apa
[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.spi.IgniteSpiAdap
[jira] [Closed] (IGNITE-4249) ODBC: Even simple request takes a lot of time.
[ 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
[ 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
[ 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-1998) Platforms: create separate portable reader.
[ https://issues.apache.org/jira/browse/IGNITE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova closed IGNITE-1998. --- > Platforms: create separate portable reader. > --- > > Key: IGNITE-1998 > URL: https://issues.apache.org/jira/browse/IGNITE-1998 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Critical > > Base portable reader - BinaryReaderExImpl. It is designed for situation when > real deserialization is expected. > To the contrast, we never deserialize objects in platform's code. For this > reason it makes sense to create separate for efficient reader for platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-4216) .NET: PlatformAffinityFunction does not inject resource into baseFunc
[ 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.
[ 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.
[ 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
[ 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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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.
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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 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 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
[ 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.
[ 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 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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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] [Comment Edited] (IGNITE-4422) Define platform plugin API in Java
[ https://issues.apache.org/jira/browse/IGNITE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15753867#comment-15753867 ] Pavel Tupitsyn edited comment on IGNITE-4422 at 12/16/16 9:29 AM: -- 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. Won't fix for now. was (Author: ptupitsyn): 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] [Closed] (IGNITE-4422) Define platform plugin API in Java
[ https://issues.apache.org/jira/browse/IGNITE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-4422. -- > 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] [Commented] (IGNITE-4408) IndexingSpi support BinaryObjects
[ https://issues.apache.org/jira/browse/IGNITE-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15753909#comment-15753909 ] Andrew Mashenkov commented on IGNITE-4408: -- TC test looks fine. Can be merged after review. > IndexingSpi support BinaryObjects > - > > Key: IGNITE-4408 > URL: https://issues.apache.org/jira/browse/IGNITE-4408 > Project: Ignite > Issue Type: Improvement > Components: binary >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: easyfix, performance > Fix For: 2.0 > > > For now key and values is being deserialized before passing to IndexingSpi. > This can cause performance issues in some cases and there is no way to change > this behavior. > It look like we should allow to avoid deserialization and pass BinaryObjects > if keepBinary option is true as we do for CacheStore. > Also SpiQueries should nof fails then both IndexingSpi is configured and > GridQueryIndexing is disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apa
[jira] [Commented] (IGNITE-3514) CPP: JVM crash on "Failed to start SPI" exception.
[ https://issues.apache.org/jira/browse/IGNITE-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiS