[jira] [Commented] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4324:


GitHub user WilliamDo opened a pull request:

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

IGNITE-4324 Check node list is non-empty before query execution



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

$ git pull https://github.com/WilliamDo/ignite IGNITE-4324

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

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


commit 5fc9cf9796c96208124f0d1ae363c6c557ec3b5c
Author: William Do 
Date:   2017-05-12T21:18:20Z

IGNITE-4324 Check node list is non-empty before selecting one for query 
execution




> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes
> -
>
> Key: IGNITE-4324
> URL: https://issues.apache.org/jira/browse/IGNITE-4324
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Nikolay Tikhonov
>Assignee: William Do
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: Tests.patch
>
>
> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes (for example with node filter).  See attached test.
> {code}
> java.lang.IllegalArgumentException: bound must be positive
>   at java.util.Random.nextInt(Random.java:388)
>   at org.apache.ignite.internal.util.lang.GridFunc.rand(GridFunc.java:677)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.nodes(GridCacheQueryAdapter.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:527)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4119)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4094)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
>   at 
> org.apache.ignite.internal.CacheFilterQueryTest.testScanQuery(CacheFilterQueryTest.java:90)
>   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:1768)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1706)
>   at java.lang.Thread.run(Thread.java:745)
> [
> {code}



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

[jira] [Created] (IGNITE-5212) Allow custom affinity for system caches

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-5212:
-

 Summary: Allow custom affinity for system caches
 Key: IGNITE-5212
 URL: https://issues.apache.org/jira/browse/IGNITE-5212
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov


Currently there is no option to specify affinity function atomics system cache, 
which may be not appropriate in custom data placement scenarios.

Suggestion: allow setting custom affinity for AtomicConfiguration



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

[jira] [Commented] (IGNITE-2492) .NET: Peer assembly loading

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2492:


Added more tests with indirect type dependencies, where required 
types/assemblies are known only at deserialization time, not before.
Turns out {{PeerLoadingObjectHolder}} on the top level of object graph is not 
enough, we must wrap every user object down the graph with it.

> .NET: Peer assembly loading
> ---
>
> Key: IGNITE-2492
> URL: https://issues.apache.org/jira/browse/IGNITE-2492
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.1
>
>
> Similar to peer class loading in Java, we can provide a possibility to load 
> assemblies on already started nodes, so that a node can execute jobs that are 
> not present on other nodes.
> Considerations:
> * Can we unload assemblies after use to free memory? This requires a separate 
> AppDomain, can we work with that?



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

[jira] [Assigned] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes

[William Do (JIRA)]

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

William Do reassigned IGNITE-4324:
--

Assignee: William Do

> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes
> -
>
> Key: IGNITE-4324
> URL: https://issues.apache.org/jira/browse/IGNITE-4324
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Nikolay Tikhonov
>Assignee: William Do
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: Tests.patch
>
>
> ScanQuery throws incomprehensible exception when topology does not contain 
> data nodes (for example with node filter).  See attached test.
> {code}
> java.lang.IllegalArgumentException: bound must be positive
>   at java.util.Random.nextInt(Random.java:388)
>   at org.apache.ignite.internal.util.lang.GridFunc.rand(GridFunc.java:677)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.nodes(GridCacheQueryAdapter.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:527)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4119)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4094)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
>   at 
> org.apache.ignite.internal.CacheFilterQueryTest.testScanQuery(CacheFilterQueryTest.java:90)
>   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:1768)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1706)
>   at java.lang.Thread.run(Thread.java:745)
> [
> {code}



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

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4052:
-

[~javaller], the issue was fixed. Please go ahead and suggest the changes in 
readme.io.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Updated] (IGNITE-5211) Classes based constructor for QueryEntities

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5211:

Description: 
We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to 
query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…)}} 
method.

Otherwise, there is no easy way for people who define SQL scheme with the 
annotations to do advanced settings like names of key and value objects, table 
name, etc.

See this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html

  was:
We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to 
query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…) }} 
method.

Otherwise, there is no easy way for people who define SQL scheme with the 
annotations to do advanced settings like names of key and value objects, table 
name, etc.

See this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html


> Classes based constructor for QueryEntities
> ---
>
> Key: IGNITE-5211
> URL: https://issues.apache.org/jira/browse/IGNITE-5211
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.1
>
>
> We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to 
> query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…)}} 
> method.
> Otherwise, there is no easy way for people who define SQL scheme with the 
> annotations to do advanced settings like names of key and value objects, 
> table name, etc.
> See this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html



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

[jira] [Updated] (IGNITE-5211) Classes based constructor for QueryEntities

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5211:

Priority: Critical  (was: Major)

> Classes based constructor for QueryEntities
> ---
>
> Key: IGNITE-5211
> URL: https://issues.apache.org/jira/browse/IGNITE-5211
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.1
>
>
> We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to 
> query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…) }} 
> method.
> Otherwise, there is no easy way for people who define SQL scheme with the 
> annotations to do advanced settings like names of key and value objects, 
> table name, etc.
> See this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html



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

[jira] [Created] (IGNITE-5211) Classes based constructor for QueryEntities

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5211:
---

 Summary: Classes based constructor for QueryEntities
 Key: IGNITE-5211
 URL: https://issues.apache.org/jira/browse/IGNITE-5211
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Vladimir Ozerov
 Fix For: 2.1


We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to 
query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…) }} 
method.

Otherwise, there is no easy way for people who define SQL scheme with the 
annotations to do advanced settings like names of key and value objects, table 
name, etc.

See this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html



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

[jira] [Commented] (IGNITE-5183) parallelJobsNumber does not prevent concurrent execution

[Ryan Ripken (JIRA)]

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

Ryan Ripken commented on IGNITE-5183:
-

I duplicated the issue in the 2.0 release on a Windows 10 machine.

> parallelJobsNumber does not prevent concurrent execution
> 
>
> Key: IGNITE-5183
> URL: https://issues.apache.org/jira/browse/IGNITE-5183
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.5.0.final, 1.9, 2.0
> Environment: Windows7, WIndows 8, Windows 10
>Reporter: Ryan Ripken
> Attachments: IgniteTest.7z
>
>
> Using FifoQueueCollisionSpi with parallelJobsNumber == 1 does not prevent 
> multiple jobs from executing at the same time.
> Emails sent to Users list April 10th, 11th, 12th.
> Attached example which reproduces issue in Ignite 1.5.
> One node needs to run node.bat
> Another node should execute IgniteTest class.
> This example looks for concurrent execution using a static AtomicInteger, 
> when multiple executions are detected it prints a message with lots of 
> asterisks.
> The example also exhibits the issue in Ignite 1.9
> Example output:
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: Peer class loading is enabled (disable it in production for 
> performance and deployment consistency reasons)
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: This operating system has been tested less rigorously: Windows 
> 10 10.0 amd64. Our team will appreciate the feedback if you experience any 
> problems running ignite in this environment.
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: Checkpoints are disabled (to enable configure any 
> GridCheckpointSpi implementation)
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: Swap space is disabled. To enable use FileSwapSpaceSpi.
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in 
> [jar:file:/J:/ignite/modules/rest-http/target/libs/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/J:/ignite/modules/visor-plugins/target/libs/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: TcpDiscoveryMulticastIpFinder has no pre-configured addresses 
> (it is recommended in production to specify at least one address in 
> TcpDiscoveryMulticastIpFinder.getAddresses() configuration property)
> Apr 11, 2017 5:03:43 PM ignitetest.TestJob execute
> WARNING: ***Multiple jobs in progress. NOT GOOD 
> 
> ***Multiple jobs in progress. NOT GOOD 
> Apr 11, 2017 5:03:43 PM ignitetest.TestJob execute
> WARNING: ***Multiple jobs in progress. NOT GOOD 
> 
> ***Multiple jobs in progress. NOT GOOD 



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

[jira] [Updated] (IGNITE-5183) parallelJobsNumber does not prevent concurrent execution

[Ryan Ripken (JIRA)]

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

Ryan Ripken updated IGNITE-5183:

Affects Version/s: 2.0
  Environment: Windows7, WIndows 8, Windows 10  (was: Windows7, WIndows 
8 possibly others)

> parallelJobsNumber does not prevent concurrent execution
> 
>
> Key: IGNITE-5183
> URL: https://issues.apache.org/jira/browse/IGNITE-5183
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.5.0.final, 1.9, 2.0
> Environment: Windows7, WIndows 8, Windows 10
>Reporter: Ryan Ripken
> Attachments: IgniteTest.7z
>
>
> Using FifoQueueCollisionSpi with parallelJobsNumber == 1 does not prevent 
> multiple jobs from executing at the same time.
> Emails sent to Users list April 10th, 11th, 12th.
> Attached example which reproduces issue in Ignite 1.5.
> One node needs to run node.bat
> Another node should execute IgniteTest class.
> This example looks for concurrent execution using a static AtomicInteger, 
> when multiple executions are detected it prints a message with lots of 
> asterisks.
> The example also exhibits the issue in Ignite 1.9
> Example output:
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: Peer class loading is enabled (disable it in production for 
> performance and deployment consistency reasons)
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: This operating system has been tested less rigorously: Windows 
> 10 10.0 amd64. Our team will appreciate the feedback if you experience any 
> problems running ignite in this environment.
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: Checkpoints are disabled (to enable configure any 
> GridCheckpointSpi implementation)
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: Swap space is disabled. To enable use FileSwapSpaceSpi.
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in 
> [jar:file:/J:/ignite/modules/rest-http/target/libs/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/J:/ignite/modules/visor-plugins/target/libs/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
> Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger warning
> WARNING: TcpDiscoveryMulticastIpFinder has no pre-configured addresses 
> (it is recommended in production to specify at least one address in 
> TcpDiscoveryMulticastIpFinder.getAddresses() configuration property)
> Apr 11, 2017 5:03:43 PM ignitetest.TestJob execute
> WARNING: ***Multiple jobs in progress. NOT GOOD 
> 
> ***Multiple jobs in progress. NOT GOOD 
> Apr 11, 2017 5:03:43 PM ignitetest.TestJob execute
> WARNING: ***Multiple jobs in progress. NOT GOOD 
> 
> ***Multiple jobs in progress. NOT GOOD 



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

[jira] [Commented] (IGNITE-2178) keepBinary is not honored for a scan query filter

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2178:


Github user agoncharuk closed the pull request at:

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


> keepBinary is not honored for a scan query filter
> -
>
> Key: IGNITE-2178
> URL: https://issues.apache.org/jira/browse/IGNITE-2178
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
> Fix For: 1.5.0.final
>
>
> To reproduce try to SCAN cache with incorrect Key\Value classes in cache 
> configuration
> {code}
> [16:55:41,901][SEVERE][sys-#18%111%][GridCacheMapEntry] An exception was 
> thrown while filter checking.
> class org.apache.ignite.IgniteCheckedException: Failed to read class name 
> from file [id=213172044, file=IGNITE_HOME\work\marshaller\213172044.classname]
> at 
> org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:158)
> at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
> at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:458)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1443)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:537)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:116)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils$23.apply(GridCacheUtils.java:1581)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils$23.apply(GridCacheUtils.java:1579)
> at org.apache.ignite.internal.util.F0$5.apply(F0.java:164)
> at org.apache.ignite.internal.util.F0$5.apply(F0.java:150)
> at 
> org.apache.ignite.internal.processors.cache.CacheEntrySerializablePredicate.apply(CacheEntrySerializablePredicate.java:96)
> at 
> org.apache.ignite.internal.processors.cache.CacheEntrySerializablePredicate.apply(CacheEntrySerializablePredicate.java:30)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAll(GridCacheContext.java:1222)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.visitable(GridCacheMapEntry.java:4101)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$Iterator0.advanceInBucket(GridCacheConcurrentMap.java:1323)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$Iterator0.advance(GridCacheConcurrentMap.java:1296)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$Iterator0.(GridCacheConcurrentMap.java:1267)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$KeyIterator.(GridCacheConcurrentMap.java:1773)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$KeyIterator.(GridCacheConcurrentMap.java:1751)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$Set0.keyIterator(GridCacheConcurrentMap.java:1482)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap$KeySet.iterator(GridCacheConcurrentMap.java:1834)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.(GridCacheQueryManager.java:844)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.scanIterator(GridCacheQueryManager.java:830)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.executeQuery(GridCacheQueryManager.java:593)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1387)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheLocalQueryFuture$LocalQueryRunnable.run(GridCacheLocalQueryFuture.java:95)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6453)
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:788)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.FileNotFoundException: 
> IGNITE_HOME\work\marshaller\213172044.classname (═х єфрхЄё  эрщЄш єърчрээ√щ 
> Їрщы)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:146)
> at 

[jira] [Commented] (IGNITE-2194) IgniteCacheProxy is not serialized properly.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2194:


Github user agoncharuk closed the pull request at:

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


> IgniteCacheProxy is not serialized properly.
> 
>
> Key: IGNITE-2194
> URL: https://issues.apache.org/jira/browse/IGNITE-2194
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
> Fix For: 2.0
>
>
> See 
> org.apache.ignite.internal.processors.cache.IgniteCacheSerializationSelfTest
> I believe that only proxy instances should be serializable. However, the 
> change should be done carefully to preserve backward compatibility.



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

[jira] [Created] (IGNITE-5210) If enabled security authentication, server is unable to restart if client tries to reconnect

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-5210:
---

 Summary: If enabled security authentication, server is unable to 
restart if client tries to reconnect
 Key: IGNITE-5210
 URL: https://issues.apache.org/jira/browse/IGNITE-5210
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.0
Reporter: Dmitry Karachentsev


Steps to reproduce:
# Configure security authentication.
# Start server node.
# Start client node.
# Restart server node.
# Server fails with ClassCastException

{noformat}
java.lang.ClassCastException: 
org.apache.ignite.plugin.security.SecurityCredentials cannot be cast to [B
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.unmarshalCredentials(ServerImpl.java:1316)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2500(ServerImpl.java:168)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3362)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2573)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2393)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6491)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2479)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}



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

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5195:
--

There is another use case to be checked: if rising minor version topology can 
cause DataStreamer remapping procedure.
E.g. clients connect to grid and register caches that rises minor topology 
version. 

If it so, then may be it would enough to make DataStreamer just ignore minor 
topology changes?

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Minor
> Fix For: 2.2
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Commented] (IGNITE-4831) Add an option to disable MBeans

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4831:
--

I've found we support MBean registration for various plugged components, e.g. 
SPI implementations. 
But there is no list of such components and their interfaces javadoc doesn't 
contains such info as well.
It would be nice to fix javadoc within this ticket.

> Add an option to disable MBeans
> ---
>
> Key: IGNITE-4831
> URL: https://issues.apache.org/jira/browse/IGNITE-4831
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>
> There are multiple MBeans registered by Ignite and there is no way to avoid 
> their registration (in case they're not allowed for security reasons for 
> example). We should have a system property that will disable MBeans.
> In addition, if MBean registration throws a {{RuntimeException}}, this 
> exception is not properly handled. For example, if it happens during cache 
> creation, {{createCache}} method hangs forever.



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

[jira] [Resolved] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5207.

Resolution: Fixed

> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. 
> Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
> {{uint}}, {{long}}, {{ulong}} (see 
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).
> We should write all of these except {{long}} and {{ulong}} properly 
> (converting them to int and back).
> {{long}} and {{ulong}} enums should be written as object.



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

[jira] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5207:


Github user asfgit closed the pull request at:

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


> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. 
> Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
> {{uint}}, {{long}}, {{ulong}} (see 
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).
> We should write all of these except {{long}} and {{ulong}} properly 
> (converting them to int and back).
> {{long}} and {{ulong}} enums should be written as object.



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

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR commented on IGNITE-5208:
--

Note that if this crash does not happen initially and the program survives for 
some time, it does not seem to happen later.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5207:


Fixed in master: 4b2b68434bf4560cb71485b93f366126730d59a7

> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. 
> Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
> {{uint}}, {{long}}, {{ulong}} (see 
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).
> We should write all of these except {{long}} and {{ulong}} properly 
> (converting them to int and back).
> {{long}} and {{ulong}} enums should be written as object.



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

[jira] [Updated] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5207:
---
Description: 
There is no way to serialize non-Int32 enums. 

Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
{{uint}}, {{long}}, {{ulong}} (see 
https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).

We should write all of these except {{long}} and {{ulong}} properly (converting 
them to int and back).
{{long}} and {{ulong}} enums should be written as object.

  was:There is no way to serialize non-Int32 enums. We should write them in 
some special way maybe.


> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. 
> Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
> {{uint}}, {{long}}, {{ulong}} (see 
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).
> We should write all of these except {{long}} and {{ulong}} properly 
> (converting them to int and back).
> {{long}} and {{ulong}} enums should be written as object.



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

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Description: 
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}

There seems to be some kind of race situation:
{code:none}
0x01381206 in std::less::operator() (this=0x1a4e4b0, __x=, __y=@0x7fff80846e04: 2066246303) at 
/usr/include/c++/6.3.1/bits/stl_function.h:386
{code}
{code:none}
#4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
(this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
src/impl/binary/binary_type_manager.cpp:56
56  std::map::iterator it = 
snapshots0.find(typeId);
(gdb) print snapshots0
$10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl = 
0x0}...}
(gdb) print snapshot
$11 = {ptr = 0x7fffda4f, impl = 0x11}
{code}

`impl` pointers seems to be corrupted on multiple places.

  was:
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-5208:

Fix Version/s: 2.1

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places. Why aren't you 
> using `std::shared_ptr` instead of your own concurrent shared pointer?



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

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-5208:

Component/s: (was: cache)
 platforms

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places. Why aren't you 
> using `std::shared_ptr` instead of your own concurrent shared pointer?



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

[jira] [Assigned] (IGNITE-5208) C++ Segfault on Put

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-5208:
---

Assignee: Igor Sapego

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places. Why aren't you 
> using `std::shared_ptr` instead of your own concurrent shared pointer?



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

[jira] [Updated] (IGNITE-5209) "IllegalStateException: Already swapped" error with offheap_tired indexed cache

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-5209:

Attachment: run-load.xml
run-load.properties
ignite-base-load-config.xml

> "IllegalStateException: Already swapped" error with offheap_tired indexed 
> cache
> ---
>
> Key: IGNITE-5209
> URL: https://issues.apache.org/jira/browse/IGNITE-5209
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ksenia Rybakova
> Attachments: ignite-base-load-config.xml, run-load.properties, 
> run-load.xml
>
>
> The following error occurs during load test and causes client fail:
> {noformat}
> <12:33:26> The benchmark of random operation 
> failed.
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
> Failed to update keys on primary node.
> at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1443)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2182)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putAll(IgniteCacheProxy.java:1429)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.doPutAll(IgniteCacheRandomOperationBenchmark.java:712)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeRandomOperation(IgniteCacheRandomOperationBenchmark.java:566)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeOutOfTx(IgniteCacheRandomOperationBenchmark.java:548)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.test(IgniteCacheRandomOperationBenchmark.java:157)
> at 
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> keys on primary node.
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:370)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:2023)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1776)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3254)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:131)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:342)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:337)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:827)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:369)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:95)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:238)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1224)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:852)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:109)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:792)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:428)
> ... 1 more
> Suppressed: java.lang.IllegalStateException: Already swapped: 
> 140510727619712
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOffheap.onSwap(GridH2KeyValueRowOffheap.java:201)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.onSwapUnswap(GridH2Table.java:230)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.onSwap(GridH2Table.java:181)

[jira] [Updated] (IGNITE-5055) Optimize GridDhtPartitionTopologyImpl: store only diff between current partition map and affinity map

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-5055:
-
Fix Version/s: 2.1

> Optimize GridDhtPartitionTopologyImpl: store only diff between current 
> partition map and affinity map
> -
>
> Key: IGNITE-5055
> URL: https://issues.apache.org/jira/browse/IGNITE-5055
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Alexey Goncharuk
> Fix For: 2.1
>
>




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

[jira] [Updated] (IGNITE-5055) Optimize GridDhtPartitionTopologyImpl: store only diff between current partition map and affinity map

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-5055:
-
Summary: Optimize GridDhtPartitionTopologyImpl: store only diff between 
current partition map and affinity map  (was: Optimize 
GridDhtPartitionTopologyImpl: do not store backup mappings for replicated cache)

> Optimize GridDhtPartitionTopologyImpl: store only diff between current 
> partition map and affinity map
> -
>
> Key: IGNITE-5055
> URL: https://issues.apache.org/jira/browse/IGNITE-5055
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Alexey Goncharuk
>




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

[jira] [Assigned] (IGNITE-5055) Optimize GridDhtPartitionTopologyImpl: do not store backup mappings for replicated cache

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-5055:


Assignee: Alexey Goncharuk  (was: Konstantin Dudkov)

> Optimize GridDhtPartitionTopologyImpl: do not store backup mappings for 
> replicated cache
> 
>
> Key: IGNITE-5055
> URL: https://issues.apache.org/jira/browse/IGNITE-5055
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Alexey Goncharuk
>




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

[jira] [Created] (IGNITE-5209) "IllegalStateException: Already swapped" error with offheap_tired indexed cache

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-5209:
---

 Summary: "IllegalStateException: Already swapped" error with 
offheap_tired indexed cache
 Key: IGNITE-5209
 URL: https://issues.apache.org/jira/browse/IGNITE-5209
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Ksenia Rybakova


The following error occurs during load test and causes client fail:
{noformat}
<12:33:26> The benchmark of random operation 
failed.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
Failed to update keys on primary node.
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1443)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2182)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putAll(IgniteCacheProxy.java:1429)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.doPutAll(IgniteCacheRandomOperationBenchmark.java:712)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeRandomOperation(IgniteCacheRandomOperationBenchmark.java:566)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeOutOfTx(IgniteCacheRandomOperationBenchmark.java:548)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.test(IgniteCacheRandomOperationBenchmark.java:157)
at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
keys on primary node.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:370)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:2023)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1776)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3254)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:131)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:342)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:337)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:827)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:369)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:95)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:238)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1224)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:852)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:109)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:792)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:428)
... 1 more
Suppressed: java.lang.IllegalStateException: Already swapped: 
140510727619712
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOffheap.onSwap(GridH2KeyValueRowOffheap.java:201)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.onSwapUnswap(GridH2Table.java:230)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.onSwap(GridH2Table.java:181)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onSwap(IgniteH2Indexing.java:736)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onSwap(GridQueryProcessor.java:1183)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.onSwap(GridCacheQueryManager.java:398)
at 
org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(GridCacheSwapManager.java:1381)
at 

[jira] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5207:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-5207 .NET: Support non-Int32 enums



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5207

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

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


commit 79520ac9d6da1decebbe3a0e31abe48fc4c064b1
Author: Pavel Tupitsyn 
Date:   2017-05-12T08:18:35Z

IGNITE-5207 .NET: Non-Int32 enums can't be serialized

commit 6279507ec929f1dd7ba938e2383766451253ab7b
Author: Pavel Tupitsyn 
Date:   2017-05-12T08:21:38Z

failing test added

commit 79862815a2e2fada95a12caac138f604f32ac126
Author: Pavel Tupitsyn 
Date:   2017-05-12T08:27:25Z

Easy fix implemented

commit b4ee2ea5faae143266693d27993cb36c03b15f20
Author: Pavel Tupitsyn 
Date:   2017-05-12T08:42:37Z

wip tests

commit 1d14404a6b8cde039a5607fdc275bae5536aebd8
Author: Pavel Tupitsyn 
Date:   2017-05-12T08:48:21Z

wip tests

commit 244d6540f2bfdc8b8224aa63a1c2b4edfca05a11
Author: Pavel Tupitsyn 
Date:   2017-05-12T08:50:08Z

wip

commit c29bf478d66da332fe6e00353c63239fab443149
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:00:53Z

wip

commit 12a9775fb70693fcd793b3eed028a5eee440dde8
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:07:55Z

wip

commit 88f1d6e59d5e4d153d4c2c66e5a98e177dbfece7
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:30:24Z

Refactor binary writers

commit a7b77be9ec56da3d627c9986daf7473a75b2c2a6
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:34:02Z

wip

commit 544e07d941d3321d6c431d08247df248dbf85003
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:50:39Z

wip

commit f6fc06c3d4092a3e77ece5f8ce64e46a12d9970a
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:52:49Z

wip

commit dffe685e28ce9e3a9de21e752489bdec97c760fd
Author: Pavel Tupitsyn 
Date:   2017-05-12T09:53:50Z

Enum handling done




> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. We should write them in some 
> special way maybe.



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

[jira] [Updated] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5195:
-
Fix Version/s: (was: 2.1)
   2.2

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Minor
> Fix For: 2.2
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Updated] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5195:
-
Priority: Minor  (was: Major)

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Minor
> Fix For: 2.2
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Description: 
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}

There seems to be some kind of race situation:
{code:none}
0x01381206 in std::less::operator() (this=0x1a4e4b0, __x=, __y=@0x7fff80846e04: 2066246303) at 
/usr/include/c++/6.3.1/bits/stl_function.h:386
{code}
{code:none}
#4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
(this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
src/impl/binary/binary_type_manager.cpp:56
56  std::map::iterator it = 
snapshots0.find(typeId);
(gdb) print snapshots0
$10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl = 
0x0}...}
(gdb) print snapshot
$11 = {ptr = 0x7fffda4f, impl = 0x11}
{code}

`impl` pointers seems to be corrupted on multiple places. Why aren't you using 
`std::shared_ptr` instead of your own concurrent shared pointer?

  was:
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Description: 
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}

There seems to be some kind of race situation:
{code:none}
0x01381206 in std::less::operator() (this=0x1a4e4b0, __x=, __y=@0x7fff80846e04: 2066246303) at 
/usr/include/c++/6.3.1/bits/stl_function.h:386
{code}
{code:none}
#4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
(this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
src/impl/binary/binary_type_manager.cpp:56
56  std::map::iterator it = 
snapshots0.find(typeId);
(gdb) print snapshots0
$10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl = 
0x0}...}
(gdb) print snapshot
$11 = {ptr = 0x7fffda4f, impl = 0x11}
{code}

  was:
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Description: 
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}

There seems to be some kind of race situation:
{code:none}
0x01381206 in std::less::operator() (this=0x1a4e4b0, __x=, __y=@0x7fff80846e04: 2066246303) at 
/usr/include/c++/6.3.1/bits/stl_function.h:386
{code}
{code:none}
#4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
(this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
src/impl/binary/binary_type_manager.cpp:56
56  std::map::iterator it = 
snapshots0.find(typeId);
(gdb) print snapshots0
$10 = std::map with 42286576 elements = \{[42312864] = \{ptr = 0x285a4a0, impl 
= 0x0\}...\}
(gdb) print snapshot
$11 = \{ptr = 0x7fffda4f, impl = 0x11\}
{code}

  was:
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  

[jira] [Commented] (IGNITE-4509) SQL: query with condition on affinity columns and without joins and subqueries can be replaced with GET

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-4509:


[~sergi.vladykin], [~vozerov] Can you please review the changes?

> SQL: query with condition on affinity columns and without joins and 
> subqueries can be replaced with GET
> ---
>
> Key: IGNITE-4509
> URL: https://issues.apache.org/jira/browse/IGNITE-4509
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: performance, sql
> Fix For: 2.1
>
>
> Simple SQL queries usually demonstrate negative scalability when more nodes 
> are added. 
> Consider the following query:
> {code}
> SELECT * FROM Person p
> WHERE p.id = ?
> {code}
> If {{Person.id}} is affinity field, then query can be replaced with plain 
> {{IgniteCache.get}} or some specialized version of GET, which will return 
> only desired fields. This optimization will guarantee smooth scale with any 
> number of nodes.



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

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Description: 
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on each cache 
concurrently, independent caches (X_1, X_2, ...) can be operated on and called 
`::Put` on concurrently, but that should not be relevant as cache api is thread 
safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}

  was:
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on *one* cache 
concurrently, but that should not be relevant as cache api is thread safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}


> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Priority: Critical
>  Labels: c++
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in 

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Description: 
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_\{number\}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on *one* cache 
concurrently, but that should not be relevant as cache api is thread safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}

  was:
The following segfault happens when:
  - using multiple caches (suffixed with number as in X_{number}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on *one* cache 
concurrently, but that should not be relevant as cache api is thread safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}


> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Priority: Critical
>  Labels: c++
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing 

[jira] [Created] (IGNITE-5208) C++ Segfault on Put

[JIRA]

Tolga HOŞGÖR created IGNITE-5208:


 Summary: C++ Segfault on Put
 Key: IGNITE-5208
 URL: https://issues.apache.org/jira/browse/IGNITE-5208
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Tolga HOŞGÖR


The following segfault happens when:
  - using multiple caches (suffixed with number as in X_{number}),
  - caches contain same type of object but not the same objects,
  - doing multithreaded `::Put` operation, only one put is done on *one* cache 
concurrently, but that should not be relevant as cache api is thread safe.

{code:none}
C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
const+0x14
C  [test+0x1106305]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node_base*, int const&)+0x41
C  [test+0x1105a9d]  std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(int const&)+0x45
C  [test+0x1104e7f]  std::map > >::find(int const&)+0x23
C  [test+0x1104031]  
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string const&, int)+0x6f
C  [test+0xe6de2d]  void 
ignite::impl::binary::BinaryWriterImpl::WriteTopObject(std::shared_ptr const&)+0xbb
C  [test+0xe6cd48]  ignite::impl::In2Operation, std::shared_ptr 
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C  [test+0x1128cf1]  
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
 ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C  [test+0x1125f41]  
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
ignite::IgniteError&)+0x2d
C  [test+0xe5539a]  ignite::cache::Cache, std::shared_ptr 
>::Put(std::__cxx11::basic_string const&, std::shared_ptr const&, 
ignite::IgniteError&)+0x52
{code}



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

[jira] [Updated] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR updated IGNITE-5208:
-
Priority: Critical  (was: Major)

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Priority: Critical
>  Labels: c++
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_{number}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on *one* 
> cache concurrently, but that should not be relevant as cache api is thread 
> safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}



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

[jira] [Created] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5207:
--

 Summary: .NET: Non-Int32 enums can't be serialized
 Key: IGNITE-5207
 URL: https://issues.apache.org/jira/browse/IGNITE-5207
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


There is no way to serialize non-Int32 enums. We should write them in some 
special way maybe.



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

[jira] [Closed] (IGNITE-5082) Redesign base template

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-5082.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Redesign base template
> --
>
> Key: IGNITE-5082
> URL: https://issues.apache.org/jira/browse/IGNITE-5082
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.1
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: base layout.png
>
>




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

[jira] [Resolved] (IGNITE-5009) Backport IGNITE-4932 optimization in 2.x release

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-5009.
--
Resolution: Fixed
  Assignee: (was: Semen Boikov)

Merged into master (01671827411ed6043e6bfb80514e3ff57fb40b18).

> Backport IGNITE-4932 optimization in 2.x release
> 
>
> Key: IGNITE-5009
> URL: https://issues.apache.org/jira/browse/IGNITE-5009
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Priority: Critical
> Fix For: 2.1
>
>
> In IGNITE-4932 we implemented for 1.9 codebase optimization to avoid cache 
> entry creation for cache.get operation, need backport this optimization in 
> 2.x release.



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