[jira] [Created] (IGNITE-7760) Handle FS hangs

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7760:


 Summary: Handle FS hangs
 Key: IGNITE-7760
 URL: https://issues.apache.org/jira/browse/IGNITE-7760
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.2, 2.1, 2.0, 1.9, 1.8, 1.7, 1.6
Reporter: Alexander Belyak


Need to handle FS operations hangs, for example  - copy WAL into wal archive 
(specially if wal archive mount as network file system volume).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7744) OPTION_LIBS environment variable is not picked up

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-7744:

Priority: Critical  (was: Blocker)

> OPTION_LIBS environment variable is not picked up
> -
>
> Key: IGNITE-7744
> URL: https://issues.apache.org/jira/browse/IGNITE-7744
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Stéphane Thibaud
>Priority: Critical
>
> When starting the Ignite docker container using `docker run -d --net=host -e 
> OPTION_LIBS=ignite-gce -e CONFIG_URI=secret_url ignite`, the container stops 
> immediately and the logs mention that the ignite-gce library was not loaded 
> correctly:
>  ```
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350) at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
>  Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673) 
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874) at 
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783) at 
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653) at 
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622) at 
> org.apache.ignite.Ignition.start(Ignition.java:347) ... 1 more Caused by: 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in 
> URL [https://storage.googleapis.com/ignite-discovery/default-config.xml]: 
> Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' 
> defined in URL 
> [https://storage.googleapis.com/ignite-discovery/default-config.xml]: Cannot 
> create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24'
>  defined in URL 
> [https://storage.googleapis.com/ignite-discovery/default-config.xml]: 
> Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]:
>  No default constructor found; nested exception is 
> java.lang.NoClassDefFoundError: 
> com/google/api/client/http/AbstractInputStreamContent at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)
>  at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:122)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1531)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1276)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
>  at 
> 

[jira] [Created] (IGNITE-7759) Logger does not print sockTimeout and ackTimeout default values for TcpDiscoverySpi

[Roman Guseinov (JIRA)]

Roman Guseinov created IGNITE-7759:
--

 Summary: Logger does not print sockTimeout and ackTimeout default 
values for TcpDiscoverySpi
 Key: IGNITE-7759
 URL: https://issues.apache.org/jira/browse/IGNITE-7759
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3, 2.1, 1.9
Reporter: Roman Guseinov


Logger does not print sockTimeout and ackTimeout default values for 
TcpDiscoverySpi

Before starting TcpDiscoverySpi logger prints the following message (debug mode 
is enabled):
{code:java}
[main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null, 
sockTimeout=0, ackTimeout=0, marsh=JdkMarshaller 
[clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10, 
reconDelay=2000, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
{code}
Note, that sockTimeout=0 and ackTimeout=0. Default values initializing happens 
after TcpDiscoverySpi.spiStart is called:
{code:java}
public class TcpDiscoverySpi extends IgniteSpiAdapter implements DiscoverySpi {
/** Node attribute that is mapped to node's external addresses (value is 
disc.tcp.ext-addrs). */

/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws 
IgniteSpiException {
initializeImpl();
}

/**
 *
 */
private void initializeImpl() {
if (impl != null)
return;

initFailureDetectionTimeout();

if (!forceSrvMode && 
(Boolean.TRUE.equals(ignite.configuration().isClientMode( {
if (ackTimeout == 0)
ackTimeout = DFLT_ACK_TIMEOUT_CLIENT;

if (sockTimeout == 0)
sockTimeout = DFLT_SOCK_TIMEOUT_CLIENT;

impl = new ClientImpl(this);

ctxInitLatch.countDown();
}
else {
if (ackTimeout == 0)
ackTimeout = DFLT_ACK_TIMEOUT;

if (sockTimeout == 0)
sockTimeout = DFLT_SOCK_TIMEOUT;

impl = new ServerImpl(this);
}
 
}

}

{code}
To avoid confusion I suggest printing default sockTimeout and ackTimeout if 
they weren't changed like:
{code:java}
[main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null, 
sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller 
[clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10, 
reconDelay=2000, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3345:
--

Added support for Java built in types for put/get operations via "keyType" and 
"valueType" optional parameters. List of supported types: 
 * java.lang.Boolean (with alias boolean)
 * java.lang.Byte (with alias byte)
 * java.lang.Short (with alias short)
 * java.lang.Integer (with aliases int, integer)
 * java.lang.Long (with alias long)
 * java.lang.Float (with alias float)
 * java.lang.Double (with alias double)
 * java.sql.Date (with alias date)
 * java.sql.Time (with alias time)
 * java.sql.Timestamp (with alias timestamp)
 * java.util.UUUID (with alias uuid)
 * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid)

For Date, Time, Timestamp value should be in format as specified in 
*valueOf(String)* methods of corresponding classes.

Example for date: "2018-01-01" see 
[https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String-]

Example for time: "01:01:01" see 
[https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String-]

Example for timestamp: "2018-02-18%2001:01:01" see 
[https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String-]

> Implement support for optional key type in REST HTTP get command
> 
>
> Key: IGNITE-3345
> URL: https://issues.apache.org/jira/browse/IGNITE-3345
> Project: Ignite
>  Issue Type: Task
>  Components: cache, rest
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> It seems that in current implementation 
> (https://apacheignite.readme.io/docs/rest-api#get)
> GET command could work only with String keys.
> We can add optional parameter "keyType" and implement support for common 
> built-in types such as Integer, Long, UUID,... and user classes that a valid 
> JavaBeans.
> Sample: http://host:port/ignite?cmd=get=1=myCache=Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3345:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Implement support for optional key type in REST HTTP get command
> 
>
> Key: IGNITE-3345
> URL: https://issues.apache.org/jira/browse/IGNITE-3345
> Project: Ignite
>  Issue Type: Task
>  Components: cache, rest
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> It seems that in current implementation 
> (https://apacheignite.readme.io/docs/rest-api#get)
> GET command could work only with String keys.
> We can add optional parameter "keyType" and implement support for common 
> built-in types such as Integer, Long, UUID,... and user classes that a valid 
> JavaBeans.
> Sample: http://host:port/ignite?cmd=get=1=myCache=Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-7725:
--

[~dmagda] I created issue IGNITE-7758 to update docs.

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7758) Update REST documentation

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7758:
-
Description: 
RETS documentation need to be updated:
 # GET_OR_CREATE_CACHE enhanced command with optional "templateName", 
"backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options.
 #  Added support for Java built in types for put/get operations via "keyType" 
and "valueType" optional parameters. List of supported types: 

 * java.lang.Boolean (with alias boolean)
 * java.lang.Byte (with alias byte)
 * java.lang.Short (with alias short)
 * java.lang.Integer (with aliases int, integer)
 * java.lang.Long (with alias long)
 * java.lang.Float (with alias float)
 * java.lang.Double (with alias double)
 * java.sql.Date (with alias date)
 * java.sql.Time (with alias time)
 * java.sql.Timestamp (with alias timestamp)
 * java.util.UUUID (with alias uuid)
 * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid)

For Date, Time, Timestamp value should be in format as specified in 
*valueOf(String)* methods of corresponding classes.

Example for date: "2018-01-01" see 
https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String-

Example for time: "01:01:01" see 
https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String-

Example for timestamp: "2018-02-18%2001:01:01" see 
https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String-

 

  was:
RETS documentation need to be updated:
 # GET_OR_CREATE_CACHE enhanced command with optional "templateName", 
"backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options.
 #  Added support for Java built in types for put/get operations via "keyType" 
and "valueType" optional parameters. List of supported types: 


> Update REST documentation
> -
>
> Key: IGNITE-7758
> URL: https://issues.apache.org/jira/browse/IGNITE-7758
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
>Reporter: Alexey Kuznetsov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> RETS documentation need to be updated:
>  # GET_OR_CREATE_CACHE enhanced command with optional "templateName", 
> "backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options.
>  #  Added support for Java built in types for put/get operations via 
> "keyType" and "valueType" optional parameters. List of supported types: 
>  * java.lang.Boolean (with alias boolean)
>  * java.lang.Byte (with alias byte)
>  * java.lang.Short (with alias short)
>  * java.lang.Integer (with aliases int, integer)
>  * java.lang.Long (with alias long)
>  * java.lang.Float (with alias float)
>  * java.lang.Double (with alias double)
>  * java.sql.Date (with alias date)
>  * java.sql.Time (with alias time)
>  * java.sql.Timestamp (with alias timestamp)
>  * java.util.UUUID (with alias uuid)
>  * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid)
> For Date, Time, Timestamp value should be in format as specified in 
> *valueOf(String)* methods of corresponding classes.
> Example for date: "2018-01-01" see 
> https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String-
> Example for time: "01:01:01" see 
> https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String-
> Example for timestamp: "2018-02-18%2001:01:01" see 
> https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String-
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7729) Add usage of Roles for Web Console E2E tests

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-7729:
--

[~alexdel] I left several review comments in upsource.

> Add usage of Roles for Web Console E2E tests
> 
>
> Key: IGNITE-7729
> URL: https://issues.apache.org/jira/browse/IGNITE-7729
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Ilya Borisov
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7758) Update REST documentation

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7758:


 Summary: Update REST documentation
 Key: IGNITE-7758
 URL: https://issues.apache.org/jira/browse/IGNITE-7758
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.5
Reporter: Alexey Kuznetsov
Assignee: Denis Magda
 Fix For: 2.5


RETS documentation need to be updated:
 # GET_OR_CREATE_CACHE enhanced command with optional "templateName", 
"backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options.
 #  Added support for Java built in types for put/get operations via "keyType" 
and "valueType" optional parameters. List of supported types: 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-7725.
--
Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7696) Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-7696:
--

[~frsyuki] I suggest you provide cluster configuration details and raise 
attention to the issue in the ml.

> Deadlock at GridDhtAtomicCache.lockEntries called through 
> GridDhtAtomicCache.updateAllAsyncInternal
> ---
>
> Key: IGNITE-7696
> URL: https://issues.apache.org/jira/browse/IGNITE-7696
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
> Environment: * Ignite 2.3
>  * OpenJDK version "1.8.0_151"
>  * Linux 4.4.0
>Reporter: Sadayuki Furuhashi
>Priority: Major
>
> We observed that all nodes in a cluster completely stalls and put/get/remove 
> operations to a cache block for ever. When it happens, we can see following 
> log in thread dump:
> {code}
> 2018-02-14_04:21:33.84410 Found one Java-level deadlock:
> 2018-02-14_04:21:33.84410 =
> 2018-02-14_04:21:33.84411 "sys-#41%IgniteManager%":
> 2018-02-14_04:21:33.84411   waiting to lock monitor 0x7f6d5e41a558 
> (object 0x000781083ef0, a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry),
> 2018-02-14_04:21:33.84411   which is held by "sys-stripe-5-#6%IgniteManager%"
> 2018-02-14_04:21:33.84412 "sys-stripe-5-#6%IgniteManager%":
> 2018-02-14_04:21:33.84412   waiting to lock monitor 0x7f6d5e41de68 
> (object 0x000781083e70, a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
> 2018-02-14_04:21:33.84412   in JNI, which is held by 
> "sys-stripe-2-#3%IgniteManager%"
> 2018-02-14_04:21:33.84412 "sys-stripe-2-#3%IgniteManager%":
> 2018-02-14_04:21:33.84413   waiting to lock monitor 0x7f6d5e41a558 
> (object 0x000781083ef0, a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
> 2018-02-14_04:21:33.84413   in JNI, which is held by 
> "sys-stripe-5-#6%IgniteManager%"
> 2018-02-14_04:21:33.84413
> 2018-02-14_04:21:33.84414 Java stack information for the threads listed above:
> 2018-02-14_04:21:33.84414 ===
> 2018-02-14_04:21:33.84416 "sys-#41%IgniteManager%":
> 2018-02-14_04:21:33.84416   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.markObsoleteVersion(GridCacheMapEntry.java:2153)
> 2018-02-14_04:21:33.84417   - waiting to lock <0x000781083ef0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
> 2018-02-14_04:21:33.84417   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.removeVersionedEntry(GridDhtLocalPartition.java:368)
> 2018-02-14_04:21:33.84418   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cleanupRemoveQueue(GridDhtLocalPartition.java:392)
> 2018-02-14_04:21:33.84418   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1.run(GridCacheProcessor.java:4051)
> 2018-02-14_04:21:33.84418   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
> 2018-02-14_04:21:33.84419   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> 2018-02-14_04:21:33.84419   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 2018-02-14_04:21:33.84419   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2018-02-14_04:21:33.84420   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2018-02-14_04:21:33.84421   at java.lang.Thread.run(Thread.java:748)
> 2018-02-14_04:21:33.84421 "sys-stripe-5-#6%IgniteManager%":
> 2018-02-14_04:21:33.84421   at sun.misc.Unsafe.monitorEnter(Native Method)
> 2018-02-14_04:21:33.84421   at 
> org.apache.ignite.internal.util.GridUnsafe.monitorEnter(GridUnsafe.java:1207)
> 2018-02-14_04:21:33.84422   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848)
> 2018-02-14_04:21:33.84422   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1707)
> 2018-02-14_04:21:33.84423   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1629)
> 2018-02-14_04:21:33.84423   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056)
> 

[jira] [Commented] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-7725:
--

No, other options are SQL specific.

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-7650) Web Console: Rework signin page.

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-7650.
--

> Web Console: Rework signin page.
> 
>
> Key: IGNITE-7650
> URL: https://issues.apache.org/jira/browse/IGNITE-7650
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.5
>
>
> * Extract signin/signup form to separated page.
>  * Implement landing page, signin/signup page as components.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7650) Web Console: Rework signin page.

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-7650:
--

Resolution: Fixed
  Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

> Web Console: Rework signin page.
> 
>
> Key: IGNITE-7650
> URL: https://issues.apache.org/jira/browse/IGNITE-7650
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.5
>
>
> * Extract signin/signup form to separated page.
>  * Implement landing page, signin/signup page as components.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7650) Web Console: Rework signin page.

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-7650:


Reviewed. Merged to master

> Web Console: Rework signin page.
> 
>
> Key: IGNITE-7650
> URL: https://issues.apache.org/jira/browse/IGNITE-7650
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> * Extract signin/signup form to separated page.
>  * Implement landing page, signin/signup page as components.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-7725 at 2/20/18 3:22 AM:
-

Ignite documentation describes some others optional parameters for 'create 
table' query.
Please refer to https://apacheignite-sql.readme.io/docs/create-table
Should we add support for it as well? 
If NO then it can be merged.


was (Author: pkonstantinov):
Ignite documentation describes some others optional parameters for 'create 
table' query.
Please refer to https://apacheignite-sql.readme.io/docs/create-table
Should we add support for it as well? 

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7725:


Ignite documentation describes some others optional parameters for 'create 
table' query.
Please refer to https://apacheignite-sql.readme.io/docs/create-table
Should we add support for it as well? 

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7725:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7650) Web Console: Rework signin page.

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-7650:
---

[~anovikov] Tests fixed. Please update ticket.

> Web Console: Rework signin page.
> 
>
> Key: IGNITE-7650
> URL: https://issues.apache.org/jira/browse/IGNITE-7650
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> * Extract signin/signup form to separated page.
>  * Implement landing page, signin/signup page as components.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST in special case

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7757:
-
Summary: Unable to create a new cache via REST in special case  (was: 
Unable to create a new cache via REST)

> Unable to create a new cache via REST in special case
> -
>
> Key: IGNITE-7757
> URL: https://issues.apache.org/jira/browse/IGNITE-7757
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
>
> 1. try to start a new cache with non-existing data region 
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1=
> {code}
> You will get correct error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}
> 2. then edit your request and make it correct and try again
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1
> {code}
> You will get the same error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-7757:
---
Description: 
1. try to start a new cache with non-existing data region 
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
You will get correct error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}

2. then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}
You will get the same error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}

  was:
# try to start a new cache with non-existing data region 
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
You will get correct error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}

# then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}
You will get the same error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}


> Unable to create a new cache via REST
> -
>
> Key: IGNITE-7757
> URL: https://issues.apache.org/jira/browse/IGNITE-7757
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
>
> 1. try to start a new cache with non-existing data region 
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1=
> {code}
> You will get correct error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}
> 2. then edit your request and make it correct and try again
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1
> {code}
> You will get the same error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-7757:
---
Description: 
# try to start a new cache with non-existing data region 
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
You will get correct error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}

# then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}
You will get the same error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}

  was:
# try to start a new cache with non-existing data region 
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
# then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}
You will get incorrect error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}


> Unable to create a new cache via REST
> -
>
> Key: IGNITE-7757
> URL: https://issues.apache.org/jira/browse/IGNITE-7757
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
>
> # try to start a new cache with non-existing data region 
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1=
> {code}
> You will get correct error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}
> # then edit your request and make it correct and try again
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1
> {code}
> You will get the same error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-7757:
---
Description: 
# try to start a new cache with non-existing data region 
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
# then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}
You will get incorrect error message
{code}
"Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
is not configured: ]"
{code}

  was:
# try to start a new cache with non-existing cache group name
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
# then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}


> Unable to create a new cache via REST
> -
>
> Key: IGNITE-7757
> URL: https://issues.apache.org/jira/browse/IGNITE-7757
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
>
> # try to start a new cache with non-existing data region 
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1=
> {code}
> # then edit your request and make it correct and try again
> {code}
> localhost:8080/ignite?cmd=getorcreate=cache1
> {code}
> You will get incorrect error message
> {code}
> "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion 
> is not configured: ]"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7757) Unable to create a new cache via REST

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-7757:
--

 Summary: Unable to create a new cache via REST
 Key: IGNITE-7757
 URL: https://issues.apache.org/jira/browse/IGNITE-7757
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov


# try to start a new cache with non-existing cache group name
{code}
localhost:8080/ignite?cmd=getorcreate=cache1=
{code}
# then edit your request and make it correct and try again
{code}
localhost:8080/ignite?cmd=getorcreate=cache1
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-3345:


Re-tested.

> Implement support for optional key type in REST HTTP get command
> 
>
> Key: IGNITE-3345
> URL: https://issues.apache.org/jira/browse/IGNITE-3345
> Project: Ignite
>  Issue Type: Task
>  Components: cache, rest
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> It seems that in current implementation 
> (https://apacheignite.readme.io/docs/rest-api#get)
> GET command could work only with String keys.
> We can add optional parameter "keyType" and implement support for common 
> built-in types such as Integer, Long, UUID,... and user classes that a valid 
> JavaBeans.
> Sample: http://host:port/ignite?cmd=get=1=myCache=Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7744) OPTION_LIBS environment variable is not picked up

[JIRA]

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

Stéphane Thibaud updated IGNITE-7744:
-
Summary: OPTION_LIBS environment variable is not picked up  (was: 
OPTIONAL_LIBS environment variable is not picked up)

> OPTION_LIBS environment variable is not picked up
> -
>
> Key: IGNITE-7744
> URL: https://issues.apache.org/jira/browse/IGNITE-7744
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Stéphane Thibaud
>Priority: Blocker
>
> When starting the Ignite docker container using `docker run -d --net=host -e 
> OPTION_LIBS=ignite-gce -e CONFIG_URI=secret_url ignite`, the container stops 
> immediately and the logs mention that the ignite-gce library was not loaded 
> correctly:
>  ```
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350) at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
>  Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673) 
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874) at 
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783) at 
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653) at 
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622) at 
> org.apache.ignite.Ignition.start(Ignition.java:347) ... 1 more Caused by: 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in 
> URL [https://storage.googleapis.com/ignite-discovery/default-config.xml]: 
> Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' 
> defined in URL 
> [https://storage.googleapis.com/ignite-discovery/default-config.xml]: Cannot 
> create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24'
>  defined in URL 
> [https://storage.googleapis.com/ignite-discovery/default-config.xml]: 
> Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]:
>  No default constructor found; nested exception is 
> java.lang.NoClassDefFoundError: 
> com/google/api/client/http/AbstractInputStreamContent at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)
>  at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:122)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1531)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1276)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
>  at 
> 

[jira] [Created] (IGNITE-7756) Streamer fails if IgniteUuid is indexed

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-7756:
---

 Summary: Streamer fails if IgniteUuid is indexed
 Key: IGNITE-7756
 URL: https://issues.apache.org/jira/browse/IGNITE-7756
 Project: Ignite
  Issue Type: Bug
  Components: streaming
Affects Versions: 2.3
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.5


IgniteDataStreamer are failed to put data to the cache if IgniteUuid is 
IndexedType.

Spark tests in IGNITE-7227 are failed because of this issue.

Reproducer:

{code:java}
public void testStreamer() throws Exception {
Ignite client = grid("client");

CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE");

ccfg.setIndexedTypes(IgniteUuid.class, String.class);

client.createCache(ccfg);

try(IgniteDataStreamer cache =
client.dataStreamer("UUID_CACHE")) {

for(Integer i=0; i<2; i++)
cache.addData(IgniteUuid.randomUuid(), i.toString());
}
}
{code}

Exception stack trace:

{noformat}
[23:43:35] (err) Failed to execute compound future reducer: GridCompoundFuture 
[rdc=null, initFlag=1, lsnrCalls=0, done=false, cancelled=false, err=null, 
futs=[true, true]][23:43:35] (err) Failed to execute compound future reducer: 
GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, 
cancelled=false, err=null, futs=[true, true]]class 
org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
[node=57961924-82ec-4d56-81eb-1a4109a0]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteException: Failed to set initial value 
for cache entry
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
... 6 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, 
actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl]
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2113)
... 11 more
class org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
[node=57961924-82ec-4d56-81eb-1a4109a0]
at 

[jira] [Commented] (IGNITE-6842) Stop all nodes after test by default.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6842:


GitHub user Mmuzaf opened a pull request:

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

 IGNITE-6842

Test PR for learning contributing processes.
- Remove duplicated code stopGrid methods;
- Add stopAllGridsSilently method throwing exception in case stop grids 
fails;
- Make stopGrids default behavior for afterTestsStopped;

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

$ git pull https://github.com/Mmuzaf/ignite ignite-6842

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

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


commit 40f9c158e226942a02a22673637e593a28096496
Author: Maxim Muzafarov 
Date:   2018-02-18T14:29:55Z

IGNITE-6842: make stopAllGrids as default behavior for afterTestsStop

commit 18248091903a0d44e292eb2502f0c40a18abd3cd
Author: Maxim Muzafarov 
Date:   2018-02-19T09:25:52Z

IGNITE-6842:add stopAllGridsSilently as default stop grid

commit b18d9aadc6613c9f5c48e7b2cec2b53ed385c994
Author: Maxim Muzafarov 
Date:   2018-02-19T09:26:21Z

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




> Stop all nodes after test by default.
> -
>
> Key: IGNITE-6842
> URL: https://issues.apache.org/jira/browse/IGNITE-6842
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently it's required to manually call stopAllGrids() after test completion.
> This leads to errors in subsequent tests if someone forgets to call it and to 
> additional boilerplate code in tests.
> Right choice is to make this default behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-7655:
---

Assignee: Denis Magda  (was: Nikolay Izhikov)

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Reporter: Nikolay Izhikov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7648) Revert IGNITE_ENABLE_FORCIBLE_NODE_KILL system property.

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov commented on IGNITE-7648:
--

[~ascherbakov], the code looks OK, but I'd change 
{code:java}
long delay = failureDetectionTimeoutEnabled() ? failureDetectionTimeout() / 
reconCnt :
   connTimeout0 - (U.currentTimeMillis() - start);
{code}
To something like:
{code:java}
long delay = failureDetectionTimeoutEnabled() ? 
timeoutHelper.remainingTime(U.currentTimeMillis()) / (reconCnt - attempt) :
   connTimeout0 - (U.currentTimeMillis() - start);{code}
In 
{{org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#createTcpClient}}

Also I'm not sure is it a good idea to enable force kill by default.

Lets consider next example:

We successfully joined the topology but due to some local issue cannot open a 
direct connection to any node via Communication SPI.

This way using your approach we will kill each node we try to send a message to.

Even in current shape IGNITE_ENABLE_FORCIBLE_NODE_KILL doesn't look like a 
production feature and, in my opinion, cannot be used by default.

 

> Revert IGNITE_ENABLE_FORCIBLE_NODE_KILL system property.
> 
>
> Key: IGNITE-7648
> URL: https://issues.apache.org/jira/browse/IGNITE-7648
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.5
>
>
> IGNITE_ENABLE_FORCIBLE_NODE_KILL system property was introduced in 
> IGNITE-5718 as a way to prevent unnecessary node drops in case of short 
> network problems.
> I suppose it's wrong decision to fix it in such way.
> We had faced some issues in our production due to lack of automatic kicking 
> of ill-behaving nodes (on example, hanging due to long GC pauses) until we 
> realised the necessity of changing default behavior via property.
> Right solution is to kick nodes only if failure threshold is reached. Such 
> behavior should be always enabled.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev commented on IGNITE-7742:


Test update added case for cahe.get() from remote node - it causes 
AssertionError on remote node and hanging up of waiting thread.

> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with 
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423 
> One of them fires here.
> We check for 
> assert 
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at 
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev edited comment on IGNITE-7742 at 2/19/18 4:52 PM:
-

Test update added case for cache.get() from remote node - it causes 
AssertionError on remote node and hanging up of waiting thread.


was (Author: macrergate):
Test update added case for cahe.get() from remote node - it causes 
AssertionError on remote node and hanging up of waiting thread.

> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with 
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423 
> One of them fires here.
> We check for 
> assert 
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at 
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-7742:
---
Attachment: (was: IgniteDbExpirePolicyTest.java)

> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with 
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423 
> One of them fires here.
> We check for 
> assert 
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at 
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev updated IGNITE-7742:
---
Attachment: IgniteDbExpirePolicyTest.java

> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with 
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423 
> One of them fires here.
> We check for 
> assert 
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at 
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7718:


I've triggered Run all for this PR. It is simpler to check chain results, 
moreover bug in such changes may cause compatibilty problems at least in PDS.

I suggest to use run all chain for all PRs
https://ci.ignite.apache.org/viewQueued.html?itemId=1102019=queuedBuildOverviewTab

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7263) Daemon-mode Ignite node should not open client port (10800)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7263:
-

[~dpavlov], [~pvinokurov], patch looks good to me.

> Daemon-mode Ignite node should not open client port (10800)
> --
>
> Key: IGNITE-7263
> URL: https://issues.apache.org/jira/browse/IGNITE-7263
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Pavel Vinokurov
>Priority: Minor
>  Labels: core
> Fix For: 2.4
>
>
> When I run a Visor console with default configuration file it opens a default 
> port (10800) for ODBC driver connection (and for thin JDBC, and for new 
> "thin" client).
> Then I run several Ignite nodes.
> So after that, the ODBC driver with default settings goes directly to a Visor 
> (daemon-mode Ignite) and does not able to get any data (daemon-mode Ignite 
> does not keep any data)
> It is better to avoid such situation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7632) NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-7632:
-

[~agoncharuk] This issue is not fixed in IGNITE-6113. There is no defense 
against possible NullPointers in partition eviction process.

> NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()
> ---
>
> Key: IGNITE-7632
> URL: https://issues.apache.org/jira/browse/IGNITE-7632
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Major
> Fix For: 2.4
>
>
> Occurs on destroying cache while rebuilding indices in progress
> {noformat}
> Partition eviction failed, this can cause grid hang.
> java.lang.NullPointerException: null
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics(IgniteCacheOffheapManagerImpl.java:1576)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1368)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1312)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:368)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:895)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7263) Daemon-mode Ignite node should not open client port (10800)

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7263:


Hi [~vozerov], 

I've checked TC results and code style. 

Could you please confirm we can simply ignore daemon node in 
ClientListenerProcessor.java, line 82

> Daemon-mode Ignite node should not open client port (10800)
> --
>
> Key: IGNITE-7263
> URL: https://issues.apache.org/jira/browse/IGNITE-7263
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Pavel Vinokurov
>Priority: Minor
>  Labels: core
> Fix For: 2.4
>
>
> When I run a Visor console with default configuration file it opens a default 
> port (10800) for ODBC driver connection (and for thin JDBC, and for new 
> "thin" client).
> Then I run several Ignite nodes.
> So after that, the ODBC driver with default settings goes directly to a Visor 
> (daemon-mode Ignite) and does not able to get any data (daemon-mode Ignite 
> does not keep any data)
> It is better to avoid such situation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-7750:
---

 Assignee: Alexey Goncharuk  (was: Pavel Kovalenko)
Affects Version/s: 2.5

Fix is ready.
Changes are tiny and only in test.

TC (Suite contains this test): 
https://ci.ignite.apache.org/viewLog.html?buildId=1100809=buildResultsDiv=IgniteTests24Java8_IgniteCache3
PR: https://github.com/apache/ignite/pull/3541


> testMultiThreadStatisticsEnable is flaky on TC
> --
>
> Key: IGNITE-7750
> URL: https://issues.apache.org/jira/browse/IGNITE-7750
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {code:java}
> class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2]
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181)
> at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found 
> [cacheName=cache2]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494)
> ... 3 more
> {code}
> The problem of the test:
> 1) We don't wait for exchange future completion after "cache2" is started and 
> it may lead to NullPointerException when we try to obtain reference to 
> "cache2" on the node which doesn't complete exchange future and initialize 
> cache proxy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7754:
---
Component/s: persistence

> WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin
> --
>
> Key: IGNITE-7754
> URL: https://issues.apache.org/jira/browse/IGNITE-7754
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Critical
>
> On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) 
> will be called, but it won't actually perform fsync because mode isn't FSYNC. 
> It might lead to LFS corruption if OS or hardware failed until checkpoint had 
> been finished.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7755:
---
Component/s: persistence

> Potentially crash during write cp-***-start.bin can lead to the impossibility 
> of recovering
> ---
>
> Key: IGNITE-7755
> URL: https://issues.apache.org/jira/browse/IGNITE-7755
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3, 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.5
>
>
> We can crashed after cp-***-start.bin created but before content (wal point) 
> is recorded. On recovery after trying read wal point we got an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-7725 at 2/19/18 3:40 PM:
---

Please test.

I added support of following optional parameters:
 * templateName=PARTITIONED|REPLICATED|_custom_template_

 * backups=N

 * writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC

 * cacheGroup=_custom_cache_group_

 * dataRegion=_name_of_existing_data_region_

Please also test negative scenarios, like: buckups=zzz, 
writeSynchronizationMode=zzz, etc


was (Author: kuaw26):
Please test.

I added support of following optional parameters:

* templateName=PARTITIONED|REPLICATED|_custom_template_

* backups=N

* writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC

* cacheGroup=_custom_cache_group_

* dataRegion=_name_of_existing_data_region_

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-7755:
--

 Summary: Potentially crash during write cp-***-start.bin can lead 
to the impossibility of recovering
 Key: IGNITE-7755
 URL: https://issues.apache.org/jira/browse/IGNITE-7755
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3, 2.4
Reporter: Dmitriy Govorukhin
 Fix For: 2.5


We can crashed after cp-***-start.bin created but before content (wal point) is 
recorded. On recovery after trying read wal point we got an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-7725 at 2/19/18 3:38 PM:
---

Please test.

I added support of following optional parameters:

* templateName=PARTITIONED|REPLICATED|_custom_template_

* backups=N

* writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC

* cacheGroup=_custom_cache_group_

* dataRegion=_name_of_existing_data_region_


was (Author: kuaw26):
Please test.

I added support of following optional parameters:

*templateName=PARTITIONED|REPLICATED|_custom_template_

*backups=N

*writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC

*cacheGroup=_custom_cache_group_

*dataRegion=_name_of_existing_data_region_

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7725:


Assignee: Pavel Konstantinov  (was: Vladimir Ozerov)

Please test.

I added support of following optional parameters:

*templateName=PARTITIONED|REPLICATED|_custom_template_

*backups=N

*writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC

*cacheGroup=_custom_cache_group_

*dataRegion=_name_of_existing_data_region_

> REST: expand parameters list of GetOrCreateCache command
> 
>
> Key: IGNITE-7725
> URL: https://issues.apache.org/jira/browse/IGNITE-7725
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.3
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Current implementation is very primitive and do not allow to create caches 
> with custom options via REST.
> http://host:port/ignite?cmd=getorcreate=cache_name[=template_name][=1][=FULL_SYNC][;
>  other options]
> Ignite will support two pre-configured templates out of the box: PARTITIONED 
> and REPLICATED (same as SQL engine).
> If template name is not specified, by default it will be PARTITIONED.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-7754:


 Summary: WAL in LOG_ONLY mode doesn't execute fsync on checkpoint 
begin
 Key: IGNITE-7754
 URL: https://issues.apache.org/jira/browse/IGNITE-7754
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) 
will be called, but it won't actually perform fsync because mode isn't FSYNC. 
It might lead to LFS corruption if OS or hardware failed until checkpoint had 
been finished.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7727) IgniteRDDSpec. Failing tests

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-7727:
---

Assignee: Nikolay Izhikov

> IgniteRDDSpec. Failing tests
> 
>
> Key: IGNITE-7727
> URL: https://issues.apache.org/jira/browse/IGNITE-7727
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Two spark tests are broken.
> Need to fix it.
> 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues  
> 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues with inline transformation



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7042) Test written in scala doesn't executed on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7042:


Github user asfgit closed the pull request at:

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


> Test written in scala doesn't executed on TC 
> -
>
> Key: IGNITE-7042
> URL: https://issues.apache.org/jira/browse/IGNITE-7042
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> Tests from module `spark` and `spark_2.10` written in scala don't executes on 
> TC.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7426) Thin client Java API - encryption

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7426:
-
Description: 
Implement SSL/TLS configuration client Java API including unit and system tests 
and samples.

ClientConfiguration(ssl configuration)

> Thin client Java API - encryption
> -
>
> Key: IGNITE-7426
> URL: https://issues.apache.org/jira/browse/IGNITE-7426
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement SSL/TLS configuration client Java API including unit and system 
> tests and samples.
> ClientConfiguration(ssl configuration)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7426) Thin client Java API - encryption

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin reassigned IGNITE-7426:


Assignee: Alexey Kukushkin

> Thin client Java API - encryption
> -
>
> Key: IGNITE-7426
> URL: https://issues.apache.org/jira/browse/IGNITE-7426
> Project: Ignite
>  Issue Type: Sub-task
> Environment: Implement SSL/TLS configuration client Java API 
> including unit and system tests and samples.
> ClientConfiguration(ssl configuration)
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7426) Thin client Java API - encryption

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7426:
-
Environment: (was: Implement SSL/TLS configuration client Java API 
including unit and system tests and samples.

ClientConfiguration(ssl configuration))

> Thin client Java API - encryption
> -
>
> Key: IGNITE-7426
> URL: https://issues.apache.org/jira/browse/IGNITE-7426
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-7435) Thin client Java API - fields query API

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin resolved IGNITE-7435.
--
Resolution: Fixed

> Thin client Java API - fields query API
> ---
>
> Key: IGNITE-7435
> URL: https://issues.apache.org/jira/browse/IGNITE-7435
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement cache fields query thin client Java API including unit and system 
> tests and samples.
> Cache
>           query(qry: SqlFieldsQuery): FieldsQueryCursor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-7751:
---
Issue Type: Bug  (was: Improvement)

> Pages Write Throttle mode doesn't protect from checkpoint buffer overflow
> -
>
> Key: IGNITE-7751
> URL: https://issues.apache.org/jira/browse/IGNITE-7751
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.5
>
>
> Even with write throttling enabled, checkpoint buffer still can be 
> overflowed. Overflow chance increases with number of writing threads. Example 
> stacktrace:
> {noformat}
> 2018-02-17 21:00:14.777 
> [ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote]
>  Commit failed.
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Commit produced a runtime exception (all transaction entries will be 
> invalidated): 
> GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, 
> concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, 
> invalidate=false, rollbackOnly=false, 
> nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ignite.IgniteException: Runtime failure on row: 
> Row@9f0a081[ key: 4694439661580364888, val: 
> com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, 
> hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, 
> userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, 
> bankInfo_DPL_colocationKey=16678, ownerId=null, 
> infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, 
> uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, 
> sourceSystem_DPL_id=65, id=4694439661580364888, 
> colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, 
> order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 
> 4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536)
>   at 
> 

[jira] [Updated] (IGNITE-6917) SQL: implement COPY command for efficient data loading

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6917:

Fix Version/s: (was: 2.4)
   2.5

> SQL: implement COPY command for efficient data loading
> --
>
> Key: IGNITE-6917
> URL: https://issues.apache.org/jira/browse/IGNITE-6917
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Kirill Shirokov
>Priority: Major
>  Labels: iep-1
> Fix For: 2.5
>
>
> Inspired by Postgres [1]
> Common use case - bulk data load through JDBC/ODBC interface. Currently it is 
> only possible to execute single commands one by one. We already can batch 
> them to improve performance, but there is still big room for improvement.
> We should think of a completely new command - {{COPY}}. It will accept a file 
> (or input stream in general case) on the client side, then transfer data to 
> the cluster, and then execute update inside the cluster, e.g. through 
> streamer.
> First of all we need to create quick and dirty prototype to assess potential 
> performance improvement. It speedup is confirmed, we should build base 
> implementation which will accept only files. But at the same time we should 
> understand how it will evolve in future: multiple file formats (probably 
> including Hadoop formarts, e.g. Parquet), escape characters, input streams, 
> etc..
> [1] [https://www.postgresql.org/docs/9.6/static/sql-copy.html]
> h1. Proposed syntax
> Curent implementation:
> {noformat}
> COPY 
> FROM "file.name"
> INTO .
> [(col-name, ...)]
> FORMAT  -- Only CSV format is supported in the current 
> release
> [BATCH_SIZE ]
> {noformat}
> We may want to gradually add features to this command in future to have 
> something like this:
> {noformat}
> COPY
> FROM "file.name"[CHARSET ""]
> INTO . [CREATE [IF NOT EXISTS]]
> [(col-name [] [NULLABLE] [ESCAPES], ...) [MATCH HEADER]]
> FORMAT (csv|tsv|...)
> -- CSV format options:
> [FIELDSEP='column-separators-regexp']
> [LINESEP='row-separators-regexp']
> [QUOTE='quote-chars']
> [ESCAPE='escape-char']
> [NULL='null-sequence']
> [COMMENT='single-line-comment-start-char']
> [TRIM_LINES]
> [IMPORT_EMPTY_LINES]
> [CHARSET ""]
> [ROWS -]
> --or--
> [SKIP ROWS ] [MAX ROWS ]
> [COLS -]
> --or--
> [SKIP COLS ] [MAX COLS ]
> [(MATCH | SKIP) HEADER]
> [(REPLACE|IGNORE|ABORT ON [])) DUPLICATE KEYS]
> [BATCH SIZE ( ROWS | [K|M|G|T|P])]
> [COMPRESS "codec-name" [codec options]]
> [LOCK (TABLE|ROWS)]
> [NOLOGGING]
> [BACKEND (DIRECT | STREAMER)]
> {noformat}
> h1. Implementation decisions and notes
> h2. Parsing
> * We support CSV format described in RFC 4180.
> * Custom row and column separators, quoting characters are currently hardcoded
> * Escape sequences, line comment characters are currently not supported
> * We may want to support fixed-length formats (via format descriptors) in 
> future
> * We may want to strip comments from lines (for example, starting with '#')
> * We may want to allow user to either ignore empty lines or treat them as a 
> special case of record having all default values
> * We may allow user to enable whitespace trimming from beginning and end of a 
> line
> * We may want to allow user to specify error handling strategy: e.g., only 
> one quote character is present or escape sequence is invalid.
> h2. File handling
> * File character set to be supported in future
> * Skipped/imported row number (or first/last line or skip header option), 
> skipped/imported column number (or first/last column): to be supported in 
> future
> * Line start pattern (as in MySQL): no support planned
> * We currently support only client-side import. No server-side file import.
> * We may want to support client-side stdin import in future.
> * We do not handle importing multiple files from single command
> * We don't benefit from any kind of pre-sorting pre-partitioning data on 
> client side.
> * We don't include any any metadata, such as line number from client side.
> h3. Transferring data
> * We send file data via batches. In future we will support batch size 
> (specified with rows per batch or data block size 
> per batch).
> * We may want to implement data compression in future.
> * We connect to single node in JDBC driver (no multi-node connections).
> h3. Cache/tables/column handling
> * We don't create table in the bulk load command
> * We may want to have and option for reading header row, which contains 
> column names to match columns
> * In future we may wish to support COLUMNS (col1, _, col2, _, col3) syntax, 
> where '_' marker means a skipped column 

[jira] [Updated] (IGNITE-7586) SQL COPY: add code examples

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7586:

Fix Version/s: (was: 2.4)
   2.5

> SQL COPY: add code examples
> ---
>
> Key: IGNITE-7586
> URL: https://issues.apache.org/jira/browse/IGNITE-7586
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>Priority: Major
>  Labels: iep-1
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7709) SQL COPY: fix file name handling

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7709:

Fix Version/s: 2.5

> SQL COPY: fix file name handling
> 
>
> Key: IGNITE-7709
> URL: https://issues.apache.org/jira/browse/IGNITE-7709
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>Priority: Major
> Fix For: 2.5
>
>
> Currently the file name is parsed as identifier, which is obviously a bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov edited comment on IGNITE-7753 at 2/19/18 2:44 PM:
-

The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:

--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 



was (Author: slukyanov):
The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:
{{
--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 
}}

> Processors are incorrectly initialized if a node joins during cluster 
> activation
> 
>
> Key: IGNITE-7753
> URL: https://issues.apache.org/jira/browse/IGNITE-7753
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> If a node joins during the cluster activation process (while the related 
> exchange operation is in progress), then some of the GridProcessor instances 
> of that node will be incorrectly initialized. While GridClusterStateProcessor 
> will correctly report the active cluster state, other processors that are 
> sensitive to the cluster state, e.g. GridServiceProcessor, will be not 
> initialized.
> A reproducer is below. 
> ===
> Ignite server = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "server");
> CyclicBarrier barrier = new CyclicBarrier(2);
> Thread activationThread = new Thread(() -> {
> try {
> barrier.await();
> server.active(true);
> }
> catch (Exception e) {
> e.printStackTrace(); // TODO implement.
> }
> });
> activationThread.start();
> barrier.await();
> IgnitionEx.setClientMode(true);
> Ignite client = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "client");
> activationThread.join();
> client.services().deployClusterSingleton("myClusterSingleton", new 
> SimpleMapServiceImpl<>());
> ===
> Here a single server node is started, then simultaneously a client node is 
> being started and the cluster is being activated, then client attempts to 
> deploy a service. As the result, the thread calling the deploy method hangs 
> forever with a stack trace like this:
> ===
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505)
> at 
> 

[jira] [Comment Edited] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov edited comment on IGNITE-7753 at 2/19/18 2:43 PM:
-

The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:
{{
--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 
}}


was (Author: slukyanov):
The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:
{{--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
   (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 
}}

> Processors are incorrectly initialized if a node joins during cluster 
> activation
> 
>
> Key: IGNITE-7753
> URL: https://issues.apache.org/jira/browse/IGNITE-7753
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> If a node joins during the cluster activation process (while the related 
> exchange operation is in progress), then some of the GridProcessor instances 
> of that node will be incorrectly initialized. While GridClusterStateProcessor 
> will correctly report the active cluster state, other processors that are 
> sensitive to the cluster state, e.g. GridServiceProcessor, will be not 
> initialized.
> A reproducer is below. 
> ===
> Ignite server = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "server");
> CyclicBarrier barrier = new CyclicBarrier(2);
> Thread activationThread = new Thread(() -> {
> try {
> barrier.await();
> server.active(true);
> }
> catch (Exception e) {
> e.printStackTrace(); // TODO implement.
> }
> });
> activationThread.start();
> barrier.await();
> IgnitionEx.setClientMode(true);
> Ignite client = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "client");
> activationThread.join();
> client.services().deployClusterSingleton("myClusterSingleton", new 
> SimpleMapServiceImpl<>());
> ===
> Here a single server node is started, then simultaneously a client node is 
> being started and the cluster is being activated, then client attempts to 
> deploy a service. As the result, the thread calling the deploy method hangs 
> forever with a stack trace like this:
> ===
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505)
> at 
> 

[jira] [Comment Edited] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov edited comment on IGNITE-7753 at 2/19/18 2:43 PM:
-

The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:
{{--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
   (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 
}}


was (Author: slukyanov):
The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:
--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 


> Processors are incorrectly initialized if a node joins during cluster 
> activation
> 
>
> Key: IGNITE-7753
> URL: https://issues.apache.org/jira/browse/IGNITE-7753
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> If a node joins during the cluster activation process (while the related 
> exchange operation is in progress), then some of the GridProcessor instances 
> of that node will be incorrectly initialized. While GridClusterStateProcessor 
> will correctly report the active cluster state, other processors that are 
> sensitive to the cluster state, e.g. GridServiceProcessor, will be not 
> initialized.
> A reproducer is below. 
> ===
> Ignite server = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "server");
> CyclicBarrier barrier = new CyclicBarrier(2);
> Thread activationThread = new Thread(() -> {
> try {
> barrier.await();
> server.active(true);
> }
> catch (Exception e) {
> e.printStackTrace(); // TODO implement.
> }
> });
> activationThread.start();
> barrier.await();
> IgnitionEx.setClientMode(true);
> Ignite client = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "client");
> activationThread.join();
> client.services().deployClusterSingleton("myClusterSingleton", new 
> SimpleMapServiceImpl<>());
> ===
> Here a single server node is started, then simultaneously a client node is 
> being started and the cluster is being activated, then client attempts to 
> deploy a service. As the result, the thread calling the deploy method hangs 
> forever with a stack trace like this:
> ===
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505)
> at 
> 

[jira] [Commented] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov commented on IGNITE-7753:


The bug is caused by a coding error in the 
GridClusterStateProcessor.onStateFinishMessage. Future that holds the 
activation result is always finished with false (joinFut.onDone(false)). The 
patch below fixes the problem:
--- 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b)
+++ 
modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java
 (date 1519047408803)
@@ -389,7 +389,7 @@
 TransitionOnJoinWaitFuture joinFut = this.joinFut;
 
 if (joinFut != null)
-joinFut.onDone(false);
+joinFut.onDone(msg.clusterActive());
 
 GridFutureAdapter transitionFut = 
transitionFuts.remove(state.transitionRequestId());
 


> Processors are incorrectly initialized if a node joins during cluster 
> activation
> 
>
> Key: IGNITE-7753
> URL: https://issues.apache.org/jira/browse/IGNITE-7753
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> If a node joins during the cluster activation process (while the related 
> exchange operation is in progress), then some of the GridProcessor instances 
> of that node will be incorrectly initialized. While GridClusterStateProcessor 
> will correctly report the active cluster state, other processors that are 
> sensitive to the cluster state, e.g. GridServiceProcessor, will be not 
> initialized.
> A reproducer is below. 
> ===
> Ignite server = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "server");
> CyclicBarrier barrier = new CyclicBarrier(2);
> Thread activationThread = new Thread(() -> {
> try {
> barrier.await();
> server.active(true);
> }
> catch (Exception e) {
> e.printStackTrace(); // TODO implement.
> }
> });
> activationThread.start();
> barrier.await();
> IgnitionEx.setClientMode(true);
> Ignite client = 
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
>  "client");
> activationThread.join();
> client.services().deployClusterSingleton("myClusterSingleton", new 
> SimpleMapServiceImpl<>());
> ===
> Here a single server node is started, then simultaneously a client node is 
> being started and the cluster is being activated, then client attempts to 
> deploy a service. As the result, the thread calling the deploy method hangs 
> forever with a stack trace like this:
> ===
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceCache(GridServiceProcessor.java:290)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.writeServiceToCache(GridServiceProcessor.java:728)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:634)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:600)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployMultiple(GridServiceProcessor.java:488)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployClusterSingleton(GridServiceProcessor.java:469)
> at 
> org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:120)
> ===
> The behavior depends on the timings - the client has to join in the middle of 
> the activation's 

[jira] [Assigned] (IGNITE-7383) Failed to restore memory after cluster restart and activating from outdated node

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-7383:


Assignee: Ilya Lantukh

> Failed to restore memory after cluster restart and activating from outdated 
> node
> 
>
> Key: IGNITE-7383
> URL: https://issues.apache.org/jira/browse/IGNITE-7383
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Ilya Lantukh
>Priority: Major
>
> Do the following steps for reproducing the problem:
> 1) start nodes 0-1-2
> 2) stop node 2
> 3) create a new cache and put some data into it
> 4) stop remaining nodes 0-1
> 5) start nodes 0-1-2
> 6) activate the cluster from the node 2
> Then 2 different results could be taken depending on which node is 
> coordinator:
> a) node 2 is a coordinator:
> {noformat}
> Failed to activate node components 
> [nodeId=42d762c7-b1e0-4283-939b-aeeb3c70, client=false, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]]
> class org.apache.ignite.IgniteCheckedException: Failed to find cache group 
> descriptor [grpId=3119]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1602)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1544)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:570)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:820)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> and activation will be failed.
> b) node 2 is NOT a coordinator:
> we will get an error from the previous version, but the activation process 
> will not be failed and then we will take "Failed to wait PME" after a number 
> of assertions
> {noformat}
> Failed to process message [senderId=a940742f-bf17-41b4-bfc2-728bee72, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: -2100569601
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:733)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:2877)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1935)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1810)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1798)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1798)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1484)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
>   at 
> 

[jira] [Created] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-7753:
--

 Summary: Processors are incorrectly initialized if a node joins 
during cluster activation
 Key: IGNITE-7753
 URL: https://issues.apache.org/jira/browse/IGNITE-7753
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3, 2.4, 2.5
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


If a node joins during the cluster activation process (while the related 
exchange operation is in progress), then some of the GridProcessor instances of 
that node will be incorrectly initialized. While GridClusterStateProcessor will 
correctly report the active cluster state, other processors that are sensitive 
to the cluster state, e.g. GridServiceProcessor, will be not initialized.

A reproducer is below. 
===
Ignite server = 
IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
 "server");

CyclicBarrier barrier = new CyclicBarrier(2);
Thread activationThread = new Thread(() -> {
try {
barrier.await();
server.active(true);
}
catch (Exception e) {
e.printStackTrace(); // TODO implement.
}
});
activationThread.start();
barrier.await();

IgnitionEx.setClientMode(true);
Ignite client = 
IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
 "client");

activationThread.join();

client.services().deployClusterSingleton("myClusterSingleton", new 
SimpleMapServiceImpl<>());
===

Here a single server node is started, then simultaneously a client node is 
being started and the cluster is being activated, then client attempts to 
deploy a service. As the result, the thread calling the deploy method hangs 
forever with a stack trace like this:
===
"main@1" prio=5 tid=0x1 nid=NA waiting
  java.lang.Thread.State: WAITING
  at sun.misc.Unsafe.park(Unsafe.java:-1)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
  at 
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505)
  at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceCache(GridServiceProcessor.java:290)
  at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.writeServiceToCache(GridServiceProcessor.java:728)
  at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:634)
  at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:600)
  at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployMultiple(GridServiceProcessor.java:488)
  at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployClusterSingleton(GridServiceProcessor.java:469)
  at 
org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:120)
===

The behavior depends on the timings - the client has to join in the middle of 
the activation's exchange process. Putting Thread.sleep(4000) into 
GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest seems to work on a 
development laptop.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7042) Test written in scala doesn't executed on TC

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7042:
--

[~NIzhikov]
Changes looks good to me

> Test written in scala doesn't executed on TC 
> -
>
> Key: IGNITE-7042
> URL: https://issues.apache.org/jira/browse/IGNITE-7042
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> Tests from module `spark` and `spark_2.10` written in scala don't executes on 
> TC.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-7752:
-
Labels: newbie  (was: )

> Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
> --
>
> Key: IGNITE-7752
> URL: https://issues.apache.org/jira/browse/IGNITE-7752
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Seems, for now it is impossible to use new style KafkaConsumer configuration 
> in KafkaStreamer.
> The issue here is Ignite use 
> kafka.consumer.Consumer.createJavaConsumerConnector() method which creates 
> old consumer (ZookeeperConsumerConnector).
> We should create a new KafkaConsumer instead which looks like support both, 
> old and new style configs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-7752:


 Summary: Update Ignite KafkaStreamer to use new KafkaConsmer 
configuration.
 Key: IGNITE-7752
 URL: https://issues.apache.org/jira/browse/IGNITE-7752
 Project: Ignite
  Issue Type: Task
  Components: streaming
Reporter: Andrew Mashenkov
 Fix For: 2.5


Seems, for now it is impossible to use new style KafkaConsumer configuration in 
KafkaStreamer.

The issue here is Ignite use 
kafka.consumer.Consumer.createJavaConsumerConnector() method which creates old 
consumer (ZookeeperConsumerConnector).

We should create a new KafkaConsumer instead which looks like support both, old 
and new style configs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7594) Tx performance drop after WAL optimization

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-7594:


Assignee: Ilya Lantukh

> Tx performance drop after WAL optimization 
> ---
>
> Key: IGNITE-7594
> URL: https://issues.apache.org/jira/browse/IGNITE-7594
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Aleksey Chetaev
>Assignee: Ilya Lantukh
>Priority: Critical
>
> Perfomance dropes in tx-putAll benchmarks after commit with WAL optimization.
> WAL Mode: Default
> First bad commit: 
> [https://github.com/apache/ignite/commit/a5ffd4eb18e6e9eab30c176a7bb4008a51b3d59d]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-7751:
---
Description: 
Even with write throttling enabled, checkpoint buffer still can be overflowed. 
Overflow chance increases with number of writing threads. Example stacktrace:
{noformat}
2018-02-17 21:00:14.777 
[ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote]
 Commit failed.
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
Commit produced a runtime exception (all transaction entries will be 
invalidated): 
GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, 
concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, 
invalidate=false, rollbackOnly=false, 
nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60]
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.ignite.IgniteException: Runtime failure on row: 
Row@9f0a081[ key: 4694439661580364888, val: 
com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, 
hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, 
userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, 
bankInfo_DPL_colocationKey=16678, ownerId=null, 
infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, 
uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, 
sourceSystem_DPL_id=65, id=4694439661580364888, 
colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, 
order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 
4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:468)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:595)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1865)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
at 

[jira] [Created] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-7751:
--

 Summary: Pages Write Throttle mode doesn't protect from checkpoint 
buffer overflow
 Key: IGNITE-7751
 URL: https://issues.apache.org/jira/browse/IGNITE-7751
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.5


Even with write throttling enabled, checkpoint buffer still can be overflowed. 
Example stacktrace:
{noformat}
2018-02-17 21:00:14.777 
[ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote]
 Commit failed.
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
Commit produced a runtime exception (all transaction entries will be 
invalidated): 
GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, 
concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, 
invalidate=false, rollbackOnly=false, 
nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60]
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.ignite.IgniteException: Runtime failure on row: 
Row@9f0a081[ key: 4694439661580364888, val: 
com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, 
hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, 
userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, 
bankInfo_DPL_colocationKey=16678, ownerId=null, 
infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, 
uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, 
sourceSystem_DPL_id=65, id=4694439661580364888, 
colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, 
order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 
4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:468)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:595)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1865)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
at 

[jira] [Updated] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-7751:
---
Description: 
Even with write throttling enabled, checkpoint buffer still can be overflowed. 
Example stacktrace:
{noformat}
2018-02-17 21:00:14.777 
[ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote]
 Commit failed.
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
Commit produced a runtime exception (all transaction entries will be 
invalidated): 
GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, 
concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, 
invalidate=false, rollbackOnly=false, 
nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60]
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.ignite.IgniteException: Runtime failure on row: 
Row@9f0a081[ key: 4694439661580364888, val: 
com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, 
hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, 
userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, 
bankInfo_DPL_colocationKey=16678, ownerId=null, 
infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, 
uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, 
sourceSystem_DPL_id=65, id=4694439661580364888, 
colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, 
order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 
4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:468)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:595)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1865)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
at 

[jira] [Commented] (IGNITE-6579) WAL history does not used when node returns to cluster again

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin commented on IGNITE-6579:
--

[~v.pyatkov],
I think it's better to create a separate ticket to improve the logging and 
close this one (as Won't FIX).

> WAL history does not used when node returns to cluster again
> 
>
> Key: IGNITE-6579
> URL: https://issues.apache.org/jira/browse/IGNITE-6579
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> When I have set big enough value to "WAL history size" and stop node on 20 
> minutes, I got the message from coordinator (order=1):
> {noformat}
> 2017-10-06 15:46:33.429 [WARN 
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
>  Partition has been scheduled for rebalancing due to outdated update counter 
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
>  cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424, 
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN 
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
>  Partition has been scheduled for rebalancing due to outdated update counter 
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
>  cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427, 
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN 
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
>  Partition has been scheduled for rebalancing due to outdated update counter 
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
>  cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426, 
> haveHistory=false]
> {noformat}
> after start node again.
> I think, history size should be enough, but I see it is not by logs 
> (haveHistory=false).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-6579) WAL history does not used when node returns to cluster again

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin edited comment on IGNITE-6579 at 2/19/18 12:59 PM:


Hello, [~v.pyatkov].
I agree, but since coordinator doesn't have information about non local 
partition sizes we can't simply point to this restriction here, at least 
without some irrelevant changes to existing partition exchange procedure.
To improve understanding, may be, we can add debug message on nodes where WAL 
history is being reserved for exchange (in case partition size too small for 
partial rebalancing)?


was (Author: xtern):
Hello, [~v.pyatkov].
I agreed, but since coordinator doesn't have information about non local 
partition sizes we can't simply point to this restriction here, at least 
without some irrelevant changes to existing partition exchange procedure.
To improve understanding, may be, we can add debug message on nodes where WAL 
history is being reserved for exchange (in case partition size too small for 
partial rebalancing)?

> WAL history does not used when node returns to cluster again
> 
>
> Key: IGNITE-6579
> URL: https://issues.apache.org/jira/browse/IGNITE-6579
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> When I have set big enough value to "WAL history size" and stop node on 20 
> minutes, I got the message from coordinator (order=1):
> {noformat}
> 2017-10-06 15:46:33.429 [WARN 
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
>  Partition has been scheduled for rebalancing due to outdated update counter 
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
>  cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424, 
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN 
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
>  Partition has been scheduled for rebalancing due to outdated update counter 
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
>  cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427, 
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN 
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
>  Partition has been scheduled for rebalancing due to outdated update counter 
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
>  cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426, 
> haveHistory=false]
> {noformat}
> after start node again.
> I think, history size should be enough, but I see it is not by logs 
> (haveHistory=false).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7253) JDBC thin driver: introduce streaming mode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7253:


Github user asfgit closed the pull request at:

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


> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7750:

Fix Version/s: 2.5

> testMultiThreadStatisticsEnable is flaky on TC
> --
>
> Key: IGNITE-7750
> URL: https://issues.apache.org/jira/browse/IGNITE-7750
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {code:java}
> class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2]
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181)
> at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found 
> [cacheName=cache2]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494)
> ... 3 more
> {code}
> The problem of the test:
> 1) We don't wait for exchange future completion after "cache2" is started and 
> it may lead to NullPointerException when we try to obtain reference to 
> "cache2" on the node which doesn't complete exchange future and initialize 
> cache proxy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7717:

Fix Version/s: 2.5

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-7253) JDBC thin driver: introduce streaming mode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-7253.
-
Resolution: Fixed

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7749:

Fix Version/s: 2.5

> testDiscoCacheReuseOnNodeJoin fails on TC
> -
>
> Key: IGNITE-7749
> URL: https://issues.apache.org/jira/browse/IGNITE-7749
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {code:java}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to 
> java.lang.String
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93)
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64)
> {code}
> There are 2 problems in the test.
> 1) We don't wait for final topology version is set on all nodes and start 
> checking discovery caches immediately after grids starting. It leads to 
> possible NullPointerException while accessing to discovery caches history.
> 2) We don't use explicit assertEquals(String, Object, Object) related to 
> comparing Objects, while Java can choose assertEquals(String, String) method 
> to compare discovery cache fields which we're getting in runtime using 
> reflection.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6113) Partition eviction prevents exchange from completion

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-6113:

Fix Version/s: 2.5

> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> 

[jira] [Updated] (IGNITE-6113) Partition eviction prevents exchange from completion

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-6113:

Component/s: cache

> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> 

[jira] [Updated] (IGNITE-6113) Partition eviction prevents exchange from completion

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-6113:

Component/s: persistence

> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> 

[jira] [Commented] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7750:


GitHub user Jokser opened a pull request:

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

IGNITE-7750 Fixed testMultiThreadStatisticsEnable test.



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

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

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

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


commit 1418eb9659f10831621426beefe2a4f8978b63a5
Author: Pavel Kovalenko 
Date:   2018-02-19T11:47:37Z

IGNITE-7750 Fixed testMultiThreadStatisticsEnable test.




> testMultiThreadStatisticsEnable is flaky on TC
> --
>
> Key: IGNITE-7750
> URL: https://issues.apache.org/jira/browse/IGNITE-7750
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> {code:java}
> class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2]
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181)
> at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found 
> [cacheName=cache2]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494)
> ... 3 more
> {code}
> The problem of the test:
> 1) We don't wait for exchange future completion after "cache2" is started and 
> it may lead to NullPointerException when we try to obtain reference to 
> "cache2" on the node which doesn't complete exchange future and initialize 
> cache proxy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-7749:
---

 Assignee: Alexey Goncharuk  (was: Pavel Kovalenko)
Affects Version/s: 2.5

Fix is ready. 
Changes are only in the test behavior.

TC: 
https://ci.ignite.apache.org/viewLog.html?buildId=1100808=buildResultsDiv=IgniteTests24Java8_IgniteSpi
PR: https://github.com/apache/ignite/pull/3540

> testDiscoCacheReuseOnNodeJoin fails on TC
> -
>
> Key: IGNITE-7749
> URL: https://issues.apache.org/jira/browse/IGNITE-7749
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> {code:java}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to 
> java.lang.String
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93)
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64)
> {code}
> There are 2 problems in the test.
> 1) We don't wait for final topology version is set on all nodes and start 
> checking discovery caches immediately after grids starting. It leads to 
> possible NullPointerException while accessing to discovery caches history.
> 2) We don't use explicit assertEquals(String, Object, Object) related to 
> comparing Objects, while Java can choose assertEquals(String, String) method 
> to compare discovery cache fields which we're getting in runtime using 
> reflection.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-7750:
---

 Summary: testMultiThreadStatisticsEnable is flaky on TC
 Key: IGNITE-7750
 URL: https://issues.apache.org/jira/browse/IGNITE-7750
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko


{code:java}
class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2]
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
at 
org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497)
at 
org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181)
at 
org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found 
[cacheName=cache2]
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227)
at 
org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494)
... 3 more
{code}


The problem of the test:

1) We don't wait for exchange future completion after "cache2" is started and 
it may lead to NullPointerException when we try to obtain reference to "cache2" 
on the node which doesn't complete exchange future and initialize cache proxy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7729) Add usage of Roles for Web Console E2E tests

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7729:
-

Assignee: Ilya Borisov  (was: Alexander Kalinin)

Please review.

> Add usage of Roles for Web Console E2E tests
> 
>
> Key: IGNITE-7729
> URL: https://issues.apache.org/jira/browse/IGNITE-7729
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Ilya Borisov
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7749:


GitHub user Jokser opened a pull request:

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

IGNITE-7749 Fixed testDiscoCacheReuseOnNodeJoin test.



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

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

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

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


commit 5233269ea684e4cff8d4a7d46d3ce1dc343dd5f1
Author: Pavel Kovalenko 
Date:   2018-02-19T10:46:26Z

IGNITE-7749 Fixed testDiscoCacheReuseOnNodeJoin test.




> testDiscoCacheReuseOnNodeJoin fails on TC
> -
>
> Key: IGNITE-7749
> URL: https://issues.apache.org/jira/browse/IGNITE-7749
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> {code:java}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to 
> java.lang.String
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93)
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64)
> {code}
> There are 2 problems in the test.
> 1) We don't wait for final topology version is set on all nodes and start 
> checking discovery caches immediately after grids starting. It leads to 
> possible NullPointerException while accessing to discovery caches history.
> 2) We don't use explicit assertEquals(String, Object, Object) related to 
> comparing Objects, while Java can choose assertEquals(String, String) method 
> to compare discovery cache fields which we're getting in runtime using 
> reflection.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-7749:
---

 Summary: testDiscoCacheReuseOnNodeJoin fails on TC
 Key: IGNITE-7749
 URL: https://issues.apache.org/jira/browse/IGNITE-7749
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko


{code:java}
java.lang.ClassCastException: 
org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to 
java.lang.String
at 
org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93)
at 
org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64)
{code}


There are 2 problems in the test.

1) We don't wait for final topology version is set on all nodes and start 
checking discovery caches immediately after grids starting. It leads to 
possible NullPointerException while accessing to discovery caches history.
2) We don't use explicit assertEquals(String, Object, Object) related to 
comparing Objects, while Java can choose assertEquals(String, String) method to 
compare discovery cache fields which we're getting in runtime using reflection.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin commented on IGNITE-7747:


[~agoncharuk] Please review my changes.

> WAL manage getAndReserveWalFiles should not throw exception if segments not 
> found
> -
>
> Key: IGNITE-7747
> URL: https://issues.apache.org/jira/browse/IGNITE-7747
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.3, 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7747:


GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-7747 An exception should not be throw if segments not found 

An exception should not be throw if segments not found for 
getAndReserveWalFiles. Stopped iteration if next segment not found

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

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

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

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


commit bc381187292e0c032f30069e9174bc78d1376789
Author: Dmitriy Govorukhin 
Date:   2018-02-19T10:34:17Z

IGNITE-7747 Exception should not be throw if segments not found for 
getAndReserveWalFiles. Stopped iteration if next segment not found




> WAL manage getAndReserveWalFiles should not throw exception if segments not 
> found
> -
>
> Key: IGNITE-7747
> URL: https://issues.apache.org/jira/browse/IGNITE-7747
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.3, 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7747:
---
Affects Version/s: 2.4

> WAL manage getAndReserveWalFiles should not throw exception if segments not 
> found
> -
>
> Key: IGNITE-7747
> URL: https://issues.apache.org/jira/browse/IGNITE-7747
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.3, 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7747:
---
Affects Version/s: 2.3

> WAL manage getAndReserveWalFiles should not throw exception if segments not 
> found
> -
>
> Key: IGNITE-7747
> URL: https://issues.apache.org/jira/browse/IGNITE-7747
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.3, 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7747:
---
Component/s: persistence

> WAL manage getAndReserveWalFiles should not throw exception if segments not 
> found
> -
>
> Key: IGNITE-7747
> URL: https://issues.apache.org/jira/browse/IGNITE-7747
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7748) MVCC TX Implement TxLog related stuctures

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7748:


 Summary: MVCC TX Implement TxLog related stuctures
 Key: IGNITE-7748
 URL: https://issues.apache.org/jira/browse/IGNITE-7748
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov


Create TxLog on the basis of BPlusTree.

The key is a pair of two long (which correspond to crd version and mvcc cntr of 
MvccVersion)

The value is TxState - an enum.

TxState has next possible values : PREPARED, COMMITTED, ABORTED, NA.

NA is a special value, which is returned when there is no info about requested 
TX.

TxLog is managed by MvccProcessor and initiated along with MvccProcessor.

At the first step there is no special WAL records corresponding to TxLog 
operation (will be implemented in future.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7193) IgniteReflectionFactory does not handle primitive data types.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7193:


Hi [~slava.koptilin], are there any news on this issue?

> IgniteReflectionFactory does not handle primitive data types.
> -
>
> Key: IGNITE-7193
> URL: https://issues.apache.org/jira/browse/IGNITE-7193
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Fix For: 2.5
>
>
> {code:java}
> public class TestClass {
> public static final int INITIAL_VALUE = 12;
> public static final int UPDATED_VALUE = 42;
> private int field = INITIAL_VALUE;
> public void setField(int value) {
> this.field = value;
> }
> public int getField() {
> return this.field;
> }
> public static void main(String[] args) {
> Map props = new HashMap<>();
> props.put("field", UPDATED_VALUE);
> IgniteReflectionFactory factory = new 
> IgniteReflectionFactory<>(ExampleNodeStartup.TestClass.class);
> factory.setProperties(props);
> assertEquals(UPDATED_VALUE, factory.create().getField());
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-7747:
--

 Summary: WAL manage getAndReserveWalFiles should not throw 
exception if segments not found
 Key: IGNITE-7747
 URL: https://issues.apache.org/jira/browse/IGNITE-7747
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7747:
---
Fix Version/s: 2.5

> WAL manage getAndReserveWalFiles should not throw exception if segments not 
> found
> -
>
> Key: IGNITE-7747
> URL: https://issues.apache.org/jira/browse/IGNITE-7747
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-7717:
---

Assignee: Alexey Goncharuk  (was: Pavel Kovalenko)

Ready to review.
Unfortunately fix heals only the described problem.

TC Run: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3536%2Fhead
PR: https://github.com/apache/ignite/pull/3536

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[Pavel Vinokurov (JIRA)]

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

Pavel Vinokurov commented on IGNITE-7718:
-

[~dpavlov], Please review my changes

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[Pavel Vinokurov (JIRA)]

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

Pavel Vinokurov commented on IGNITE-7718:
-

https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3534%2Fmerge

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-3345:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Implement support for optional key type in REST HTTP get command
> 
>
> Key: IGNITE-3345
> URL: https://issues.apache.org/jira/browse/IGNITE-3345
> Project: Ignite
>  Issue Type: Task
>  Components: cache, rest
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> It seems that in current implementation 
> (https://apacheignite.readme.io/docs/rest-api#get)
> GET command could work only with String keys.
> We can add optional parameter "keyType" and implement support for common 
> built-in types such as Integer, Long, UUID,... and user classes that a valid 
> JavaBeans.
> Sample: http://host:port/ignite?cmd=get=1=myCache=Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-3345:


Successful in general but in some case error is empty in response although the 
node console had an error

> Implement support for optional key type in REST HTTP get command
> 
>
> Key: IGNITE-3345
> URL: https://issues.apache.org/jira/browse/IGNITE-3345
> Project: Ignite
>  Issue Type: Task
>  Components: cache, rest
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> It seems that in current implementation 
> (https://apacheignite.readme.io/docs/rest-api#get)
> GET command could work only with String keys.
> We can add optional parameter "keyType" and implement support for common 
> built-in types such as Integer, Long, UUID,... and user classes that a valid 
> JavaBeans.
> Sample: http://host:port/ignite?cmd=get=1=myCache=Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7746) Failed to put data into cache if IndexedTypes configured.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7746:


 Summary: Failed to put data into cache if IndexedTypes configured.
 Key: IGNITE-7746
 URL: https://issues.apache.org/jira/browse/IGNITE-7746
 Project: Ignite
  Issue Type: Improvement
  Components: cache, sql
Reporter: Alexey Kuznetsov
Assignee: Vladimir Ozerov
 Fix For: 2.5


reproducer

{code}

import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;

public class Reproducer {
 /**
 * @param args Command line arguments.
 */
 public static void main(String[] args) {
 IgniteConfiguration cfg = new IgniteConfiguration();

 CacheConfiguration ccfg = new CacheConfiguration("test");
 ccfg.setIndexedTypes(String.class, String.class);

 cfg.setCacheConfiguration(ccfg);

 try(Ignite ignite = Ignition.start(cfg)) {
 IgniteCache cStr = ignite.cache("test");
 cStr.put("key", "value");

 IgniteCache cInt = ignite.cache("test");
 cInt.put(1, 2);

 IgniteCache cIntStr = ignite.cache("test");
 cIntStr.put(7, "test");
 }
 }
}

{code}

{noformat}

Exception in thread "main" org.apache.ignite.cache.CachePartialUpdateException: 
Failed to update keys (retry update if possible).: [7]
 at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1278)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1731)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1087)
 at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:886)
 at org.apache.ignite.Reproducer.main(Reproducer.java:26)
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [7]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1805)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
 at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2369)
 at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2346)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
 ... 2 more
 Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to update 
keys.
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKey(UpdateErrors.java:108)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:329)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2559)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
 at