[jira] [Commented] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes
[
https://issues.apache.org/jira/browse/IGNITE-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[
https://issues.apache.org/jira/browse/IGNITE-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
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 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
[ https://issues.apache.org/jira/browse/IGNITE-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
https://issues.apache.org/jira/browse/IGNITE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (IGNITE-2194) IgniteCacheProxy is not serialized properly.
[ https://issues.apache.org/jira/browse/IGNITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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.
[ https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
https://issues.apache.org/jira/browse/IGNITE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer
> > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::find(int const&)+0x45
> C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer,
> std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::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
[
https://issues.apache.org/jira/browse/IGNITE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __y=@0x7fff80846e04: 2066246303) at
/usr/include/c++/6.3.1/bits/stl_function.h:386
{code}
{code:none}
#4 0x015040c
[jira] [Updated] (IGNITE-5208) C++ Segfault on Put
[
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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer
> > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::find(int const&)+0x45
> C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer,
> std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::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
[
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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer
> > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::find(int const&)+0x45
> C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer,
> std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::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
[
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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer
> > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::find(int const&)+0x45
> C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer,
> std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::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
[
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] [Commented] (IGNITE-5055) Optimize GridDhtPartitionTopologyImpl: store only diff between current partition map and affinity map
[ https://issues.apache.org/jira/browse/IGNITE-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007914#comment-16007914 ] Alexey Goncharuk commented on IGNITE-5055: -- On stable topology the diff should be empty, so no extra space will be occupied > 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
[ 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
[ 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
[ 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 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
org.apache.ignite.inter
[jira] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized
[ https://issues.apache.org/jira/browse/IGNITE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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.
[ 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
[
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __y=@0x7fff80846e04: 2066246303) at
[jira] [Updated] (IGNITE-5208) C++ Segfault on Put
[
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __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
(
[jira] [Updated] (IGNITE-5208) C++ Segfault on Put
[
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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=, __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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::allocator >, std::shared_ptr
>::Put(std::__cxx11::basic_string,
std::allocator > 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
[jira] [Commented] (IGNITE-4509) SQL: query with condition on affinity columns and without joins and subqueries can be replaced with GET
[
https://issues.apache.org/jira/browse/IGNITE-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::allocator >, std::shared_ptr
>::Put(std::__cxx11::basic_string,
std::allocator > 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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::allocator >, std::shared_ptr
>::Put(std::__cxx11::basic_string,
std::allocator > 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 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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignit
[jira] [Updated] (IGNITE-5208) C++ Segfault on Put
[
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::allocator >, std::shared_ptr
>::Put(std::__cxx11::basic_string,
std::allocator > 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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::allocator >, std::shared_ptr
>::Put(std::__cxx11::basic_string,
std::allocator > 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 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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer
> > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C [test
[jira] [Created] (IGNITE-5208) C++ Segfault on Put
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,
std::less, std::allocator
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string, 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::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::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] [Updated] (IGNITE-5208) C++ Segfault on Put
[
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 ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer
> > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer
> >, std::_Select1st ignite::common::concurrent::SharedPointer
> > >, std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::find(int const&)+0x45
> C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer,
> std::less, std::allocator ignite::common::concurrent::SharedPointer
> > > >::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 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
[ 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)
