[jira] [Created] (IGNITE-13432) Continuous Query deploys remote filter even on client nodes
Mikhail Cherkasov created IGNITE-13432: -- Summary: Continuous Query deploys remote filter even on client nodes Key: IGNITE-13432 URL: https://issues.apache.org/jira/browse/IGNITE-13432 Project: Ignite Issue Type: Improvement Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov CQ deployment can fail due to the absence of a remote filter on client nodes. And this doesn't make sense, we don't need it on nodes which doesn't store data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12808) Allow create tables for existing caches
Mikhail Cherkasov created IGNITE-12808: -- Summary: Allow create tables for existing caches Key: IGNITE-12808 URL: https://issues.apache.org/jira/browse/IGNITE-12808 Project: Ignite Issue Type: New Feature Components: sql Reporter: Mikhail Cherkasov If you have a big cache with a lot of data and you need to index it, right now you have to destroy cache and create a new one to index your data. Or create a new cache with a table and reload it to data to the new cache which definitely is time-consuming and super inconvenient. I believe we can allow users to create tables for existing caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12758) zookeeper discovery does not work due to missed dependency
Mikhail Cherkasov created IGNITE-12758: -- Summary: zookeeper discovery does not work due to missed dependency Key: IGNITE-12758 URL: https://issues.apache.org/jira/browse/IGNITE-12758 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Mikhail Cherkasov in new zookeeper 3.5.5 version part of classes were moved in new jar: [https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper-jute/3.5.5] which is missed in Apache Ignite release. Sever fails to start with the following exception: [15:16:14,514][SEVERE][main][IgniteKernal] Got exception while starting (will rollback startup routine). java.lang.NoClassDefFoundError: org/apache/zookeeper/data/Id at org.apache.zookeeper.ZooDefs$Ids.(ZooDefs.java:111) at org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.(ZookeeperClient.java:68) at org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:783) at org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:714) at org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:483) at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:943) at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1276) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at org.apache.ignite.Ignition.start(Ignition.java:346) at org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:300) Caused by: java.lang.ClassNotFoundException: [org.apache.zookeeper.data.Id|http://org.apache.zookeeper.data.id/] at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) ... 19 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12431) Allow to set inline size for implicit indexes per table
Mikhail Cherkasov created IGNITE-12431: -- Summary: Allow to set inline size for implicit indexes per table Key: IGNITE-12431 URL: https://issues.apache.org/jira/browse/IGNITE-12431 Project: Ignite Issue Type: Bug Components: sql Reporter: Mikhail Cherkasov Right now you can specify inline size only for explicit indexes, but there's no way you can set it for implicit caches, except global flag: IGNITE_MAX_INDEX_PAYLOAD_SIZE or per cache: [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/CacheConfiguration.html#setSqlIndexMaxInlineSize-int-] however, if there's only one table which requires a big inline for implicit indices is too big overhead to specify it for the whole cache. Let's introduce some way to do this per table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12276) Thin client uses Optimized marshaller for TreeSet and TreeMap
Mikhail Cherkasov created IGNITE-12276: -- Summary: Thin client uses Optimized marshaller for TreeSet and TreeMap Key: IGNITE-12276 URL: https://issues.apache.org/jira/browse/IGNITE-12276 Project: Ignite Issue Type: Bug Components: thin client Reporter: Mikhail Cherkasov Thin client uses Optimized marshaller for TreeSet and TreeMap, while thick client replace them with BinaryTreeMap/BinaryTreeSet. As a result it blocks schema changes for stored objects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-9184: - Assignee: (was: Mikhail Cherkasov) > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-2176) Not valid exceptions in case when example can't works with remote node started with server classpath (Java 8)
[
https://issues.apache.org/jira/browse/IGNITE-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-2176:
--
Affects Version/s: 2.7.5
> Not valid exceptions in case when example can't works with remote node
> started with server classpath (Java 8)
> -
>
> Key: IGNITE-2176
> URL: https://issues.apache.org/jira/browse/IGNITE-2176
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final, 2.7.5
> Environment: jdk 1.7
> OS X 10.10.2
>Reporter: Ilya Suntsov
>Assignee: Yakov Zhdanov
>Priority: Critical
>
> Steps for reproduce:
> 1. Start one node from IDEA and one more from terminal
> 2. Run StreamVisitorExample (Java 8):
> Exception:
> {noformat}
> Exception in thread "pub-#2%null%" class
> org.apache.ignite.binary.BinaryInvalidTypeException:
> org.apache.ignite.examples.java8.streaming.StreamVisitorExample
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:467)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1330)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1284)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readClass(BinaryReaderExImpl.java:339)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:835)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:645)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:696)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1646)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:645)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:696)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:267)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal(BinaryMarshaller.java:112)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:271)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:49)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:76)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:819)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:782)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.examples.java8.streaming.StreamVisitorExample
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8172)
> at
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:185)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:458)
> ... 22 more
> {noformat}
> 3. Run StreamTransformerExample (Java 8)
> Exception:
> {noformat}
> Exception in thread "pub-#2%null%" class
> org.apache.ignite.binary.BinaryInvalidTypeException:
> org.apache.ignite.examples.java8.streaming.StreamTransformerExample
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:467)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1330)
> at
>
[jira] [Resolved] (IGNITE-11819) Add query timeouts support for JDBC statement
[ https://issues.apache.org/jira/browse/IGNITE-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-11819. Resolution: Duplicate > Add query timeouts support for JDBC statement > - > > Key: IGNITE-11819 > URL: https://issues.apache.org/jira/browse/IGNITE-11819 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Mikhail Cherkasov >Priority: Major > > statement.setQueryTimeout(5_000); - this timeout doesn't have any effect for > ignite, it ignores it, event if we have delays in network for minutes, it > will wait all this time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11819) Add query timeouts support for JDBC statement
Mikhail Cherkasov created IGNITE-11819: -- Summary: Add query timeouts support for JDBC statement Key: IGNITE-11819 URL: https://issues.apache.org/jira/browse/IGNITE-11819 Project: Ignite Issue Type: Improvement Components: sql Reporter: Mikhail Cherkasov statement.setQueryTimeout(5_000); - this timeout doesn't have any effect for ignite, it ignores it, event if we have delays in network for minutes, it will wait all this time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11400) Rebalancing caches with TTL enabled can cause data corruption.
[
https://issues.apache.org/jira/browse/IGNITE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov resolved IGNITE-11400.
Resolution: Cannot Reproduce
> Rebalancing caches with TTL enabled can cause data corruption.
> --
>
> Key: IGNITE-11400
> URL: https://issues.apache.org/jira/browse/IGNITE-11400
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Mikhail Cherkasov
>Priority: Critical
>
> During or just after rebalancing caches with TTL enabled, data corruption can
> occurs while ttl-cleanup-worker purges expired data.
> See details in log
> {code:java}
> [15:24:01,677][INFO
> ][sys-#49%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [M2_PRODUCT_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topic=0, fullPartitions=[1,
> 55, 112, 153, 170, 175, 204, 236, 247, 331, 347, 417, 473, 503, 514, 524,
> 551, 745, 748, 752, 762, 803, 816, 831, 851, 877, 928, 939],
> histPartitions=[]]
> [15:24:02,031][ERROR][ttl-cleanup-worker-#39%datafabric-dev-21.example.com%][GridCacheTtlManager]
> Failed to process entry expiration: class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: Runtime
> failure on bounds: [lower=null, upper=PendingRow []]
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on bounds: [lower=null, upper=PendingRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1000)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:979)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:1957)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1913)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:861)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:142)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Invalid object type: 0
> at
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toKeyCacheObject(IgniteCacheObjectProcessorImpl.java:166)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toKeyCacheObject(CacheObjectBinaryProcessorImpl.java:980)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.readFullRow(CacheDataRowAdapter.java:299)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:159)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingRow.initKey(PendingRow.java:72)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:118)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:31)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer(BPlusTree.java:4702)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.init(BPlusTree.java:4604)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.access$5000(BPlusTree.java:4543)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findLowerUnbounded(BPlusTree.java:956)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:988)
> ... 8 more
> [15:24:02,348][INFO
> ][sys-#52%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [CART_CACHE, supplier=70be2776-9e8f-4940-8a07-5e3c0ad43bdd,
> topic=0, fullPartitions=[561, 897], histPartitions=[]]
> [15:24:02,439][INFO
> ][sys-#48%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Completed
> (final) rebalancing [grp=CART_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topVer=AffinityTopologyVersion
>
[jira] [Reopened] (IGNITE-11400) Rebalancing caches with TTL enabled can cause data corruption.
[
https://issues.apache.org/jira/browse/IGNITE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov reopened IGNITE-11400:
> Rebalancing caches with TTL enabled can cause data corruption.
> --
>
> Key: IGNITE-11400
> URL: https://issues.apache.org/jira/browse/IGNITE-11400
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Mikhail Cherkasov
>Priority: Critical
>
> During or just after rebalancing caches with TTL enabled, data corruption can
> occurs while ttl-cleanup-worker purges expired data.
> See details in log
> {code:java}
> [15:24:01,677][INFO
> ][sys-#49%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [M2_PRODUCT_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topic=0, fullPartitions=[1,
> 55, 112, 153, 170, 175, 204, 236, 247, 331, 347, 417, 473, 503, 514, 524,
> 551, 745, 748, 752, 762, 803, 816, 831, 851, 877, 928, 939],
> histPartitions=[]]
> [15:24:02,031][ERROR][ttl-cleanup-worker-#39%datafabric-dev-21.example.com%][GridCacheTtlManager]
> Failed to process entry expiration: class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: Runtime
> failure on bounds: [lower=null, upper=PendingRow []]
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on bounds: [lower=null, upper=PendingRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1000)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:979)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:1957)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1913)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:861)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:142)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Invalid object type: 0
> at
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toKeyCacheObject(IgniteCacheObjectProcessorImpl.java:166)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toKeyCacheObject(CacheObjectBinaryProcessorImpl.java:980)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.readFullRow(CacheDataRowAdapter.java:299)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:159)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingRow.initKey(PendingRow.java:72)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:118)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:31)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer(BPlusTree.java:4702)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.init(BPlusTree.java:4604)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.access$5000(BPlusTree.java:4543)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findLowerUnbounded(BPlusTree.java:956)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:988)
> ... 8 more
> [15:24:02,348][INFO
> ][sys-#52%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [CART_CACHE, supplier=70be2776-9e8f-4940-8a07-5e3c0ad43bdd,
> topic=0, fullPartitions=[561, 897], histPartitions=[]]
> [15:24:02,439][INFO
> ][sys-#48%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Completed
> (final) rebalancing [grp=CART_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topVer=AffinityTopologyVersion
> [topVer=921, minorTopVer=0],
[jira] [Assigned] (IGNITE-11400) Rebalancing caches with TTL enabled can cause data corruption.
[
https://issues.apache.org/jira/browse/IGNITE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov reassigned IGNITE-11400:
--
Assignee: Mikhail Cherkasov
> Rebalancing caches with TTL enabled can cause data corruption.
> --
>
> Key: IGNITE-11400
> URL: https://issues.apache.org/jira/browse/IGNITE-11400
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Mikhail Cherkasov
>Priority: Critical
>
> During or just after rebalancing caches with TTL enabled, data corruption can
> occurs while ttl-cleanup-worker purges expired data.
> See details in log
> {code:java}
> [15:24:01,677][INFO
> ][sys-#49%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [M2_PRODUCT_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topic=0, fullPartitions=[1,
> 55, 112, 153, 170, 175, 204, 236, 247, 331, 347, 417, 473, 503, 514, 524,
> 551, 745, 748, 752, 762, 803, 816, 831, 851, 877, 928, 939],
> histPartitions=[]]
> [15:24:02,031][ERROR][ttl-cleanup-worker-#39%datafabric-dev-21.example.com%][GridCacheTtlManager]
> Failed to process entry expiration: class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: Runtime
> failure on bounds: [lower=null, upper=PendingRow []]
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on bounds: [lower=null, upper=PendingRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1000)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:979)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:1957)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1913)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:861)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:142)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Invalid object type: 0
> at
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toKeyCacheObject(IgniteCacheObjectProcessorImpl.java:166)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toKeyCacheObject(CacheObjectBinaryProcessorImpl.java:980)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.readFullRow(CacheDataRowAdapter.java:299)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:159)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingRow.initKey(PendingRow.java:72)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:118)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:31)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer(BPlusTree.java:4702)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.init(BPlusTree.java:4604)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.access$5000(BPlusTree.java:4543)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findLowerUnbounded(BPlusTree.java:956)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:988)
> ... 8 more
> [15:24:02,348][INFO
> ][sys-#52%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [CART_CACHE, supplier=70be2776-9e8f-4940-8a07-5e3c0ad43bdd,
> topic=0, fullPartitions=[561, 897], histPartitions=[]]
> [15:24:02,439][INFO
> ][sys-#48%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Completed
> (final) rebalancing [grp=CART_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topVer=AffinityTopologyVersion
[jira] [Resolved] (IGNITE-11400) Rebalancing caches with TTL enabled can cause data corruption.
[
https://issues.apache.org/jira/browse/IGNITE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov resolved IGNITE-11400.
Resolution: Duplicate
> Rebalancing caches with TTL enabled can cause data corruption.
> --
>
> Key: IGNITE-11400
> URL: https://issues.apache.org/jira/browse/IGNITE-11400
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Mikhail Cherkasov
>Priority: Critical
>
> During or just after rebalancing caches with TTL enabled, data corruption can
> occurs while ttl-cleanup-worker purges expired data.
> See details in log
> {code:java}
> [15:24:01,677][INFO
> ][sys-#49%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [M2_PRODUCT_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topic=0, fullPartitions=[1,
> 55, 112, 153, 170, 175, 204, 236, 247, 331, 347, 417, 473, 503, 514, 524,
> 551, 745, 748, 752, 762, 803, 816, 831, 851, 877, 928, 939],
> histPartitions=[]]
> [15:24:02,031][ERROR][ttl-cleanup-worker-#39%datafabric-dev-21.example.com%][GridCacheTtlManager]
> Failed to process entry expiration: class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: Runtime
> failure on bounds: [lower=null, upper=PendingRow []]
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on bounds: [lower=null, upper=PendingRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1000)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:979)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:1957)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1913)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:861)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:142)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Invalid object type: 0
> at
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toKeyCacheObject(IgniteCacheObjectProcessorImpl.java:166)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toKeyCacheObject(CacheObjectBinaryProcessorImpl.java:980)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.readFullRow(CacheDataRowAdapter.java:299)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:159)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingRow.initKey(PendingRow.java:72)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:118)
> at
> org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:31)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer(BPlusTree.java:4702)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.init(BPlusTree.java:4604)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.access$5000(BPlusTree.java:4543)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findLowerUnbounded(BPlusTree.java:956)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:988)
> ... 8 more
> [15:24:02,348][INFO
> ][sys-#52%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Started
> rebalance routine [CART_CACHE, supplier=70be2776-9e8f-4940-8a07-5e3c0ad43bdd,
> topic=0, fullPartitions=[561, 897], histPartitions=[]]
> [15:24:02,439][INFO
> ][sys-#48%datafabric-dev-21.example.com%][GridDhtPartitionDemander] Completed
> (final) rebalancing [grp=CART_CACHE,
> supplier=14c0d3aa-6720-4c7f-a0e5-3ae1a00948b6, topVer=AffinityTopologyVersion
>
[jira] [Reopened] (IGNITE-11531) Merge concurrent registrations of the same binary type
[
https://issues.apache.org/jira/browse/IGNITE-11531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov reopened IGNITE-11531:
> Merge concurrent registrations of the same binary type
> --
>
> Key: IGNITE-11531
> URL: https://issues.apache.org/jira/browse/IGNITE-11531
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Reporter: Denis Mekhanikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a binary type is registered multiple times simultaneously, then a lot of
> type versions are generated with the same schema. It leads to long binary
> type registration especially on big topologies.
> The following code sample demonstrates the problem:
> {code:java}
> public class LongRegistration {
> public static void main(String[] args) throws InterruptedException {
> Ignite ignite = Ignition.start(igniteConfig());
> int threadsNum = 50;
> ExecutorService exec = Executors.newFixedThreadPool(threadsNum);
> CyclicBarrier barrier = new CyclicBarrier(threadsNum);
> long startTime = System.currentTimeMillis();
> // register(ignite);
> for (int i = 0; i < threadsNum; i++)
> exec.submit(new TypeRegistrator(ignite, barrier));
> exec.shutdown();
> exec.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
> System.out.println("Total registration time: " +
> (System.currentTimeMillis() - startTime));
> }
> private static IgniteConfiguration igniteConfig() {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
> discoverySpi.setLocalAddress("127.0.0.1");
> discoverySpi.setLocalPort(47500);
> discoverySpi.setIpFinder(ipFinder);
> igniteCfg.setDiscoverySpi(discoverySpi);
> return igniteCfg;
> }
> private static void register(Ignite ignite) {
> long startTime = System.currentTimeMillis();
> IgniteBinary binary = ignite.binary();
> BinaryObjectBuilder builder = binary.builder("TestType");
> builder.setField("intField", 1);
> builder.build();
> System.out.println("Registration time: " +
> (System.currentTimeMillis() - startTime));
> }
> private static class TypeRegistrator implements Runnable {
> private Ignite ignite;
> private CyclicBarrier cyclicBarrier;
> TypeRegistrator(Ignite ignite, CyclicBarrier cyclicBarrier) {
> this.ignite = ignite;
> this.cyclicBarrier = cyclicBarrier;
> }
> @Override public void run() {
> try {
> cyclicBarrier.await();
> register(ignite);
> } catch (InterruptedException | BrokenBarrierException e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> This code sample leads to registration of 50 versions of the same type. The
> effect is more noticeable if a cluster contains a lot of nodes.
> If you uncomment the call to {{register()}} method, then overall registration
> becomes 10 times faster on topology of 5 nodes.
> Registration of matching types should be merged to avoid long processing of
> such cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11531) Merge concurrent registrations of the same binary type
[
https://issues.apache.org/jira/browse/IGNITE-11531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798146#comment-16798146
]
Mikhail Cherkasov commented on IGNITE-11531:
[~akalashnikov] BinaryTypeRegistrationTest#shouldSendOnlyOneMetadataMessage
test fails periodicly, could you please take a look on it:
java.lang.AssertionError:
Expected :1
Actual :2
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertEquals(JUnitAssertAware.java:94)
at
org.apache.ignite.internal.processors.cache.BinaryTypeRegistrationTest.shouldSendOnlyOneMetadataMessage(BinaryTypeRegistrationTest.java:106)
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
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2102)
at java.lang.Thread.run(Thread.java:748)
> Merge concurrent registrations of the same binary type
> --
>
> Key: IGNITE-11531
> URL: https://issues.apache.org/jira/browse/IGNITE-11531
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Reporter: Denis Mekhanikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a binary type is registered multiple times simultaneously, then a lot of
> type versions are generated with the same schema. It leads to long binary
> type registration especially on big topologies.
> The following code sample demonstrates the problem:
> {code:java}
> public class LongRegistration {
> public static void main(String[] args) throws InterruptedException {
> Ignite ignite = Ignition.start(igniteConfig());
> int threadsNum = 50;
> ExecutorService exec = Executors.newFixedThreadPool(threadsNum);
> CyclicBarrier barrier = new CyclicBarrier(threadsNum);
> long startTime = System.currentTimeMillis();
> // register(ignite);
> for (int i = 0; i < threadsNum; i++)
> exec.submit(new TypeRegistrator(ignite, barrier));
> exec.shutdown();
> exec.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
> System.out.println("Total registration time: " +
> (System.currentTimeMillis() - startTime));
> }
> private static IgniteConfiguration igniteConfig() {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
> discoverySpi.setLocalAddress("127.0.0.1");
> discoverySpi.setLocalPort(47500);
> discoverySpi.setIpFinder(ipFinder);
> igniteCfg.setDiscoverySpi(discoverySpi);
> return igniteCfg;
> }
> private static void register(Ignite ignite) {
> long startTime = System.currentTimeMillis();
> IgniteBinary binary = ignite.binary();
> BinaryObjectBuilder builder = binary.builder("TestType");
> builder.setField("intField", 1);
> builder.build();
> System.out.println("Registration time: " +
> (System.currentTimeMillis() - startTime));
> }
> private static class TypeRegistrator implements Runnable {
> private Ignite ignite;
> private CyclicBarrier cyclicBarrier;
> TypeRegistrator(Ignite ignite, CyclicBarrier cyclicBarrier) {
> this.ignite = ignite;
> this.cyclicBarrier = cyclicBarrier;
> }
> @Override public void run() {
> try {
> cyclicBarrier.await();
> register(ignite);
> } catch (InterruptedException | BrokenBarrierException e) {
> e.printStackTrace();
> }
> }
>
[jira] [Commented] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746506#comment-16746506 ] Mikhail Cherkasov commented on IGNITE-10944: Ignite already has method validateNode(ClusterNode node, JoiningNodeDiscoveryData discoData) in GridPlugingComponent, we just need to make ignite use this method and bypass discoData to plugin provider. I added a new method to plugins provider to implement this and added default implementation to interface to keep compatibility with existing plugins: [https://github.com/apache/ignite/pull/5865/files] [~agoncharuk] could you please review my changes? > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method then we should add a possibility to get this > data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
Mikhail Cherkasov created IGNITE-10960:
--
Summary: Thin client cannot retrieve data that was inserted with
the Thick Ignite client when using a composite key
Key: IGNITE-10960
URL: https://issues.apache.org/jira/browse/IGNITE-10960
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Mikhail Cherkasov
Attachments: ThinClientGets.java
Thin client cannot retrieve data that was inserted with the Thick Ignite client
when using a composite key.
See the attached reproducer:
ThinClientGets.java
thickCache.put(new TestKey("a", "0"), 1);
thickCache.get(new TestKey("a", "0")); // returns 1
thinCache.get(new TestKey("a", "0")) // returns null
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-10944: -- Assignee: Mikhail Cherkasov > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method then we should add a possibility to get this > data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743051#comment-16743051 ] Mikhail Cherkasov commented on IGNITE-10886: [~skozlov] could you please help me with testing of this change? I tested it manually, but might be you know/have some automated tests for sh scripts? > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742917#comment-16742917 ] Mikhail Cherkasov edited comment on IGNITE-10886 at 1/15/19 9:58 AM: - [~ilyak] without fix: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev with fix: Mikhails-MBP:apache-ignite-2.7.0-bin mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Ignite Command Line Startup, ver. 2.7.0#20181130-sha1:256ae401 ... [19:17:31,306][INFO][main][IgniteKernal] IGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin [19:17:31,306][INFO][main][IgniteKernal] VM arguments: [-XX:+AggressiveOpts, -Xms1g, -Xmx1g, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=false, -DIGNITE_SUCCESS_FILE=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin/work/ignite_success_80a26259-9b3f-4f81-aee2-56a558bda5f7, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49184, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin, -DIGNITE_PROG_NAME=bin/ignite.sh, -Xmx3G, -Xms3G, -DIGNITE_CLUSTER_NAME=dev dev dev] was (Author: mcherkasov): without fix: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev with fix: Mikhails-MBP:apache-ignite-2.7.0-bin mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Ignite Command Line Startup, ver. 2.7.0#20181130-sha1:256ae401 ... [19:17:31,306][INFO][main][IgniteKernal] IGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin [19:17:31,306][INFO][main][IgniteKernal] VM arguments: [-XX:+AggressiveOpts, -Xms1g, -Xmx1g, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=false, -DIGNITE_SUCCESS_FILE=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin/work/ignite_success_80a26259-9b3f-4f81-aee2-56a558bda5f7, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49184, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin, -DIGNITE_PROG_NAME=bin/ignite.sh, -Xmx3G, -Xms3G, -DIGNITE_CLUSTER_NAME=dev dev dev] > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742917#comment-16742917 ] Mikhail Cherkasov commented on IGNITE-10886: without fix: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev with fix: Mikhails-MBP:apache-ignite-2.7.0-bin mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Ignite Command Line Startup, ver. 2.7.0#20181130-sha1:256ae401 ... [19:17:31,306][INFO][main][IgniteKernal] IGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin [19:17:31,306][INFO][main][IgniteKernal] VM arguments: [-XX:+AggressiveOpts, -Xms1g, -Xmx1g, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=false, -DIGNITE_SUCCESS_FILE=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin/work/ignite_success_80a26259-9b3f-4f81-aee2-56a558bda5f7, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49184, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin, -DIGNITE_PROG_NAME=bin/ignite.sh, -Xmx3G, -Xms3G, -DIGNITE_CLUSTER_NAME=dev dev dev] > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-10886: --- Description: -J-PARAMS doesn't allow spaces, so you can not pass for example: -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. it will fail with the following message: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev was: JVM_OPTS and -J-PARAMS doesn't allow spaces, so you can pass for example: -DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-10886: --- Summary: -J-PARAMS does not allow spaces in arguments (was: -J-PARAMS doesn't allow spaces) > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > JVM_OPTS and -J-PARAMS doesn't allow spaces, so you can pass for example: > -DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10886) -J-PARAMS doesn't allow spaces
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-10886: --- Summary: -J-PARAMS doesn't allow spaces (was: JVM_OPTS and -J-PARAMS doesn't allow spaces) > -J-PARAMS doesn't allow spaces > -- > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > JVM_OPTS and -J-PARAMS doesn't allow spaces, so you can pass for example: > -DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10577) ignite-kubernetes is missing jackson-annotations dependency
[
https://issues.apache.org/jira/browse/IGNITE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-10577:
---
Description:
When starting 2.7 with the ignite-kubernetes option I get the following
exception on startup:
{code:java}
[13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonView
at
com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)
at
com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
{code}
It's clearly missing a dependency.
was:
When starting 2.7 with the ignite-kubernetes option I get the following
exception on startup:
{code}
[13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonView
at
com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)
at
com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
{code}
It's clearly missing a dependency.
> ignite-kubernetes is missing jackson-annotations dependency
> ---
>
> Key: IGNITE-10577
> URL: https://issues.apache.org/jira/browse/IGNITE-10577
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
> Fix For: 2.8
>
>
> When starting 2.7 with the ignite-kubernetes option I get the following
> exception on startup:
>
> {code:java}
> [13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonView
> at
> com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)
> at
> com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
> {code}
>
> It's clearly missing a dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10886) JVM_OPTS and -J-PARAMS doesn't allow spaces
Mikhail Cherkasov created IGNITE-10886: -- Summary: JVM_OPTS and -J-PARAMS doesn't allow spaces Key: IGNITE-10886 URL: https://issues.apache.org/jira/browse/IGNITE-10886 Project: Ignite Issue Type: Improvement Components: general Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov JVM_OPTS and -J-PARAMS doesn't allow spaces, so you can pass for example: -DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728720#comment-16728720 ] Mikhail Cherkasov commented on IGNITE-9184: --- I simplified reproducer, continues queries are not involved here, to reproduce the issue we need to restart concurrently client and server nodes, see a new reproducer StressTest2.java > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9184: -- Summary: Cluster hangs during concurrent node client and server nodes restart (was: Cluster hangs during concurrent node restart and continues query registration) > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9184: -- Attachment: (was: StressTest.java) > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9184: -- Attachment: StressTest2.java > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest.java, StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[
https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728666#comment-16728666
]
Mikhail Cherkasov commented on IGNITE-9184:
---
[~zstan] it hangs even on latest master:
{code:java}
[25-12-2018 13:21:25][WARN ][main][GridCachePartitionExchangeManager] Still
waiting for initial partition map exchange [fut=GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=1f8184a1-4722-4855-83c4-70760229465b, addrs=ArrayList [0:0:0:0:0:0:0:1%lo0,
127.0.0.1, 172.25.4.99], sockAddrs=HashSet [/0:0:0:0:0:0:0:1%lo0:0,
/127.0.0.1:0, Mikhails-MBP.gridgain.local/172.25.4.99:0], discPort=0,
order=705, intOrder=0, lastExchangeTime=1545731025479, loc=true,
ver=2.7.0#19700101-sha1:, isClient=true], topVer=705, nodeId8=1f8184a1,
msg=null, type=NODE_JOINED, tstamp=1545731025740], crd=TcpDiscoveryNode
[id=4f70ea84-f356-4086-9795-ea004edb72e9, addrs=ArrayList [0:0:0:0:0:0:0:1%lo0,
127.0.0.1, 172.25.4.99], sockAddrs=HashSet [/0:0:0:0:0:0:0:1%lo0:47500,
/127.0.0.1:47500, Mikhails-MBP.gridgain.local/172.25.4.99:47500],
discPort=47500, order=681, intOrder=343, lastExchangeTime=1545731025545,
loc=false, ver=2.7.0#19700101-sha1:, isClient=false],
exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=705,
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=1f8184a1-4722-4855-83c4-70760229465b, addrs=ArrayList [0:0:0:0:0:0:0:1%lo0,
127.0.0.1, 172.25.4.99], sockAddrs=HashSet [/0:0:0:0:0:0:0:1%lo0:0,
/127.0.0.1:0, Mikhails-MBP.gridgain.local/172.25.4.99:0], discPort=0,
order=705, intOrder=0, lastExchangeTime=1545731025479, loc=true,
ver=2.7.0#19700101-sha1:, isClient=true], topVer=705, nodeId8=1f8184a1,
msg=null, type=NODE_JOINED, tstamp=1545731025740], nodeId=1f8184a1,
evt=NODE_JOINED], added=true, initFut=GridFutureAdapter
[ignoreInterrupts=false, state=DONE, res=true, hash=1416345449], init=true,
lastVer=null, partReleaseFut=null, exchActions=ExchangeActions
[startCaches=null, stopCaches=null, startGrps=[], stopGrps=[], resetParts=null,
stateChangeRequest=null], affChangeMsg=null, initTs=1545731035406,
centralizedAff=false, forceAffReassignment=false, exchangeLocE=null,
cacheChangeFailureMsgSent=false, done=false, state=CLIENT,
registerCachesFuture=GridFinishedFuture [resFlag=2], partitionsSent=false,
partitionsReceived=false, delayedLatestMsg=GridDhtPartitionsFullMessage
[parts=HashMap {-2100569601=GridDhtPartitionFullMap
{502ade99-f598-428e-a142-2ff997eda6ab=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=703, minorTopVer=0], updateSeq=106,
size=100], 060c1c8d-3137-4069-9c0f-a10f621e38db=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=701, minorTopVer=0], updateSeq=125,
size=100], 4f70ea84-f356-4086-9795-ea004edb72e9=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=701, minorTopVer=0], updateSeq=157,
size=100], 7da72f35-3d8e-44a1-9cd8-c7d9584fa945=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=703, minorTopVer=0], updateSeq=201,
size=100]}, 2571410=GridDhtPartitionFullMap
{502ade99-f598-428e-a142-2ff997eda6ab=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=703, minorTopVer=0], updateSeq=531,
size=525], 060c1c8d-3137-4069-9c0f-a10f621e38db=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=701, minorTopVer=0], updateSeq=649,
size=623], 4f70ea84-f356-4086-9795-ea004edb72e9=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=701, minorTopVer=0], updateSeq=929,
size=708], 7da72f35-3d8e-44a1-9cd8-c7d9584fa945=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=705, minorTopVer=0], updateSeq=1157,
size=515]}}, partCntrs=IgniteDhtPartitionCountersMap [],
partCntrs2=o.a.i.i.processors.cache.distributed.dht.preloader.IgniteDhtPartitionCountersMap2@223769f7,
partHistSuppliers=IgniteDhtPartitionHistorySuppliersMap [],
partsToReload=IgniteDhtPartitionsToReloadMap [], partsSizes=HashMap
{-2100569601=UnmodifiableMap {0=0, 1=0, 2=0, 3=0, 4=0, 5=0, 6=0, 7=0, 8=0, 9=0,
10=0, 11=0, 12=0, 13=0, 14=0, 15=0, 16=0, 17=0, 18=0, 19=0, 20=0, 21=0, 22=0,
23=0, 24=0, 25=0, 26=0, 27=0, 28=0, 29=0, 30=0, 31=0, 32=0, 33=0, 34=0, 35=0,
36=0, 37=0, 38=0, 39=0, 40=0, 41=0, 42=0, 43=0, 44=0, 45=0, 46=0, 47=0, 48=0,
49=0, 50=0, 51=0, 52=0, 53=0, 54=0, 55=0, 56=0, 57=0, 58=0, 59=0, 60=0, 61=0,
62=0, 63=0, 64=0, 65=0, 66=0, 67=0, 68=0, 69=0, 70=0, 71=0, 72=0, 73=0, 74=0,
75=0, 76=0, 77=0, 78=0, 79=0, 80=0, 81=0, 82=0, 83=0, 84=0, 85=0, 86=0, 87=0,
88=0, 89=0, 90=0, 91=0, 92=0, 93=0, 94=0, 95=0, 96=0, 97=0, 98=0, 99=0},
2571410=UnmodifiableMap {0=0, 1=null, 2=null, 3=0, 4=0, 5=0, 6=null, 7=0, 8=0,
9=0, 10=0, 11=null, 12=0, 13=0, 14=0, 15=null, 16=null, 17=0, 18=0, 19=0,
20=null, 21=0, 22=0, 23=0, 24=null, 25=0, 26=0, 27=0, 28=0, 29=0, 30=null,
31=0, 32=0, 33=0,
[jira] [Resolved] (IGNITE-9924) Rename "allow non-collacated joins" to allow distributed joins
[ https://issues.apache.org/jira/browse/IGNITE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-9924. --- Resolution: Duplicate > Rename "allow non-collacated joins" to allow distributed joins > -- > > Key: IGNITE-9924 > URL: https://issues.apache.org/jira/browse/IGNITE-9924 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Minor > Attachments: Screen Shot 2018-10-17 at 15.33.33.png > > > if you google "allow non-collacated joins" it will show you doc with title > about distributed join, our API use is/setDistributedJoins method, so why we > have this non-collacated in WebConsole, let's rename it to "allow distributed > joins" to make it more consistent to our API and doc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9907) Wrong index field name makes the whole cluster to fail
[ https://issues.apache.org/jira/browse/IGNITE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-9907: - Assignee: (was: Mikhail Cherkasov) > Wrong index field name makes the whole cluster to fail > -- > > Key: IGNITE-9907 > URL: https://issues.apache.org/jira/browse/IGNITE-9907 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Priority: Critical > Attachments: WrongFields.java > > > Wrong index field name makes the whole cluster to fail and there's now > reliable way to restore from this state, exchange fails with the exception: > > 2018-10-16 > 14:42:56,842][ERROR][exchange-worker-#42%server_0%][GridCachePartitionExchangeManager] > Failed to wait for completion of partition map exchange (preloading will not > start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent > [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > super=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, > /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, > lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, > isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, > type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], crd=TcpDiscoveryNode > [id=0d8b289d-32aa-402e-8e71-137977559979, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:47500, > /0:0:0:0:0:0:0:1%lo0:47500, /127.0.0.1:47500], discPort=47500, order=1, > intOrder=1, lastExchangeTime=1539726176493, loc=true, > ver=2.4.3#19691231-sha1:, isClient=false], > exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, > affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > super=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, > /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, > lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, > isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, > type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], nodeId=6859ef9c, > evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=false, hash=1240595188], init=false, > lastVer=null, partReleaseFut=PartitionReleaseFuture > [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], futures=[]], TxReleaseFuture [topVer=AffinityTopologyVersion > [topVer=2, minorTopVer=1], futures=[]], AtomicUpdateReleaseFuture > [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], > DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], futures=[, exchActions=null, affChangeMsg=null, > initTs=1539726176695, centralizedAff=false, forceAffReassignment=false, > changeGlobalStateE=null, done=true, state=CRD, evtLatch=0, remaining=[], > super=GridFutureAdapter [ignoreInterrupts=false, state=DONE, > res=java.lang.IndexOutOfBoundsException: Index: 0, Size: 0, hash=1559339235]] > class org.apache.ignite.IgniteCheckedException: Index: 0, Size: 0 > at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2374) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.rangeCheck(ArrayList.java:657) > at java.util.ArrayList.get(ArrayList.java:433) > at > org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:374) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:194) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:816) > at >
[jira] [Updated] (IGNITE-10244) Peer classloading creates a new class on each call for nested compute tasks
[ https://issues.apache.org/jira/browse/IGNITE-10244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-10244: --- Description: If a compute task has embedded compute tasks, embeded task will be loaded by peer class loading as a new class on each call, which leads to metadata OOM. Reproducer is attached. Make sure that you run ignite nodes with -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size. Also, we need to keep client and server in different JVM to make peer classloading be engaged. So what happens: # client sends compute taks MyCall to server_1 # server_1 execute MyCall and MyCall sends NestedCall task to server_2 # server_2 loads NestedCall as a new class and execute it # repeat it's again and on second iteration server_2 will load NestedCall as new class again, after few iterations this will lead to OOM was: If a compute task has embedded compute tasks, embeded task will be loaded by peer class loading as a new class on each call, which leads to metadata OOM. Reproducer is attached. Make sure that you run ignite nodes with -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size. So what happens: # client sends compute taks MyCall to server_1 # server_1 execute MyCall and MyCall sends NestedCall task to server_2 # server_2 loads NestedCall as a new class and execute it # repeat it's again and on second iteration server_2 will load NestedCall as new class again, after few iterations this will lead to OOM > Peer classloading creates a new class on each call for nested compute tasks > --- > > Key: IGNITE-10244 > URL: https://issues.apache.org/jira/browse/IGNITE-10244 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Mikhail Cherkasov >Priority: Critical > Attachments: JustServer.java, MyCall.java, NestedCall.java, Test.java > > > If a compute task has embedded compute tasks, embeded task will be loaded by > peer class loading as a new class on each call, which leads to metadata OOM. > Reproducer is attached. Make sure that you run ignite nodes with > -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size. > Also, we need to keep client and server in different JVM to make peer > classloading be engaged. > So what happens: > # client sends compute taks MyCall to server_1 > # server_1 execute MyCall and MyCall sends NestedCall task to server_2 > # server_2 loads NestedCall as a new class and execute it > # repeat it's again and on second iteration server_2 will load NestedCall as > new class again, after few iterations this will lead to OOM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10244) Peer classloading creates a new class on each call for nested compute tasks
Mikhail Cherkasov created IGNITE-10244: -- Summary: Peer classloading creates a new class on each call for nested compute tasks Key: IGNITE-10244 URL: https://issues.apache.org/jira/browse/IGNITE-10244 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Mikhail Cherkasov Attachments: JustServer.java, MyCall.java, NestedCall.java, Test.java If a compute task has embedded compute tasks, embeded task will be loaded by peer class loading as a new class on each call, which leads to metadata OOM. Reproducer is attached. Make sure that you run ignite nodes with -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size. So what happens: # client sends compute taks MyCall to server_1 # server_1 execute MyCall and MyCall sends NestedCall task to server_2 # server_2 loads NestedCall as a new class and execute it # repeat it's again and on second iteration server_2 will load NestedCall as new class again, after few iterations this will lead to OOM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9965) Ignite.sh must enable GC logs by default
[ https://issues.apache.org/jira/browse/IGNITE-9965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9965: -- Component/s: general > Ignite.sh must enable GC logs by default > > > Key: IGNITE-9965 > URL: https://issues.apache.org/jira/browse/IGNITE-9965 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > Almost always you need to monitor GC and almost always people foget to enable > GC logs, so why not to enable GC logs by default? > Let's check if it's oracle/openjdk and no GC logs config is specified then > collect GC logs, also we may add a script variable to specify a path for logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9966) Dump configuration to distinct file and all dynamic changes to the cluster
[ https://issues.apache.org/jira/browse/IGNITE-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9966: -- Component/s: general > Dump configuration to distinct file and all dynamic changes to the cluster > -- > > Key: IGNITE-9966 > URL: https://issues.apache.org/jira/browse/IGNITE-9966 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > Sometimes it's difficult to analyze issues, very often we can't restore > nodes/caches configurations due to log rotation, I think we can dump > configurations on start in work dir. > Also, it will be convenient to dump configurations of all dynamically created > caches to the file too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9966) Dump configuration to distinct file and all dynamic changes to the cluster
Mikhail Cherkasov created IGNITE-9966: - Summary: Dump configuration to distinct file and all dynamic changes to the cluster Key: IGNITE-9966 URL: https://issues.apache.org/jira/browse/IGNITE-9966 Project: Ignite Issue Type: Improvement Reporter: Mikhail Cherkasov Fix For: 2.8 Sometimes it's difficult to analyze issues, very often we can't restore nodes/caches configurations due to log rotation, I think we can dump configurations on start in work dir. Also, it will be convenient to dump configurations of all dynamically created caches to the file too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9965) Ignite.sh must enable GC logs by default
Mikhail Cherkasov created IGNITE-9965: - Summary: Ignite.sh must enable GC logs by default Key: IGNITE-9965 URL: https://issues.apache.org/jira/browse/IGNITE-9965 Project: Ignite Issue Type: Improvement Reporter: Mikhail Cherkasov Fix For: 2.8 Almost always you need to monitor GC and almost always people foget to enable GC logs, so why not to enable GC logs by default? Let's check if it's oracle/openjdk and no GC logs config is specified then collect GC logs, also we may add a script variable to specify a path for logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9925) Validate QueryEntites on cache creation
Mikhail Cherkasov created IGNITE-9925: - Summary: Validate QueryEntites on cache creation Key: IGNITE-9925 URL: https://issues.apache.org/jira/browse/IGNITE-9925 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.6 Reporter: Mikhail Cherkasov Fix For: 2.8 it's possible to create a cache with the index for non-existing field and kill the whole cluster, I think this should be prevented by configuration validation, see reproducer in https://issues.apache.org/jira/browse/IGNITE-9907 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9924) Rename "allow non-collacated joins" to allow distributed joins
Mikhail Cherkasov created IGNITE-9924: - Summary: Rename "allow non-collacated joins" to allow distributed joins Key: IGNITE-9924 URL: https://issues.apache.org/jira/browse/IGNITE-9924 Project: Ignite Issue Type: Improvement Components: visor Affects Versions: 2.6 Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Attachments: Screen Shot 2018-10-17 at 15.33.33.png if you google "allow non-collacated joins" it will show you doc with title about distributed join, our API use is/setDistributedJoins method, so why we have this non-collacated in WebConsole, let's rename it to "allow distributed joins" to make it more consistent to our API and doc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9907) Wrong index field name makes the whole cluster to fail
Mikhail Cherkasov created IGNITE-9907: - Summary: Wrong index field name makes the whole cluster to fail Key: IGNITE-9907 URL: https://issues.apache.org/jira/browse/IGNITE-9907 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Attachments: WrongFields.java Wrong index field name makes the whole cluster to fail and there's now reliable way to restore from this state, exchange fails with the exception: 2018-10-16 14:42:56,842][ERROR][exchange-worker-#42%server_0%][GridCachePartitionExchangeManager] Failed to wait for completion of partition map exchange (preloading will not start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], crd=TcpDiscoveryNode [id=0d8b289d-32aa-402e-8e71-137977559979, addrs=[0:0:0:0:0:0:0:1%lo0, 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:47500, /0:0:0:0:0:0:0:1%lo0:47500, /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1539726176493, loc=true, ver=2.4.3#19691231-sha1:, isClient=false], exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], nodeId=6859ef9c, evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter [ignoreInterrupts=false, state=DONE, res=false, hash=1240595188], init=false, lastVer=null, partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[, exchActions=null, affChangeMsg=null, initTs=1539726176695, centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, done=true, state=CRD, evtLatch=0, remaining=[], super=GridFutureAdapter [ignoreInterrupts=false, state=DONE, res=java.lang.IndexOutOfBoundsException: Index: 0, Size: 0, hash=1559339235]] class org.apache.ignite.IgniteCheckedException: Index: 0, Size: 0 at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332) at org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259) at org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207) at org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2374) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:657) at java.util.ArrayList.get(ArrayList.java:433) at org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:374) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:194) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:816) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:381) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:554) at
[jira] [Resolved] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov resolved IGNITE-9600.
---
Resolution: Won't Fix
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>Priority: Minor
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov reassigned IGNITE-9600:
-
Assignee: Mikhail Cherkasov
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>Priority: Minor
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9906) Added new method to get or wait for cache
Mikhail Cherkasov created IGNITE-9906: - Summary: Added new method to get or wait for cache Key: IGNITE-9906 URL: https://issues.apache.org/jira/browse/IGNITE-9906 Project: Ignite Issue Type: Improvement Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Attachments: Client.java, Server.java Due async nature of Ignite, ignite client might get cache creation event later then the rest of cluster and if server node created cache and pass it name to client, client might fail to get this cache, client.cache(name) will return null: # server creates cache server.getOrCreateCache() and return from getOrCreateCache method # server sends the cache name to client # client does client.cache(cacheName) and get null. It can be workaround by adding retirees, but it's a boilerplate code that we can add to our API. we can overload existing method ignite.cache() and add timeout for waiting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9844) Replace action in pessimistic transaction makes value unwrap and causes ClassNotFoundException
[
https://issues.apache.org/jira/browse/IGNITE-9844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-9844:
--
Ignite Flags: (was: Docs Required)
> Replace action in pessimistic transaction makes value unwrap and causes
> ClassNotFoundException
> --
>
> Key: IGNITE-9844
> URL: https://issues.apache.org/jira/browse/IGNITE-9844
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Major
> Attachments: SimpleTest.java
>
>
> The problem can be reproduced only if you replace the existing value in a
> cache inside pessimistic transaction and server node doesn't have the class
> for the value which the node already has in the cache.
> The reproducer is attached, please make sure that you run server node without
> model class in class path.
> Stack trace:
> {code:java}
> [2018-10-10 10:16:31,828][ERROR][pub-#52%grid_0%][GridJobWorker] Failed to
> execute job [jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl
> [taskName=class_not_found.SimpleTest$Task, dep=GridDeployment
> [ts=1539191791633, depMode=SHARED, clsLdr=GridDeploymentClassLoader
> [id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
> nodeLdrMap=HashMap
> {c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, userVer=0,
> loc=false, sampleClsName=class_not_found.SimpleTest$Task,
> pendingUndeploy=false, undeployed=false, usage=1]SharedDeployment [rmv=false,
> super=], taskClsName=class_not_found.SimpleTest$Task,
> sesId=f6acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
> startTime=1539191791465, endTime=9223372036854775807,
> taskNodeId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
> clsLdr=GridDeploymentClassLoader
> [id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
> nodeLdrMap=HashMap
> {c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], closed=false,
> cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false,
> internal=false, topPred=null, subjId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
> mapFut=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
> hash=550280323]IgniteFuture [orig=], execName=null],
> jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b]]
> class org.apache.ignite.IgniteException:
> class_not_found.SimpleTest$MyDomainObject
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6797)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1191)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1923)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> class_not_found.SimpleTest$MyDomainObject
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
> at
>
[jira] [Created] (IGNITE-9844) Replace action in pessimistic transaction makes value unwrap and causes ClassNotFoundException
Mikhail Cherkasov created IGNITE-9844:
-
Summary: Replace action in pessimistic transaction makes value
unwrap and causes ClassNotFoundException
Key: IGNITE-9844
URL: https://issues.apache.org/jira/browse/IGNITE-9844
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.6
Reporter: Mikhail Cherkasov
Attachments: SimpleTest.java
The problem can be reproduced only if you replace the existing value in a cache
inside pessimistic transaction and server node doesn't have the class for the
value which the node already has in the cache.
The reproducer is attached, please make sure that you run server node without
model class in class path.
Stack trace:
{code:java}
[2018-10-10 10:16:31,828][ERROR][pub-#52%grid_0%][GridJobWorker] Failed to
execute job [jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
ses=GridJobSessionImpl [ses=GridTaskSessionImpl
[taskName=class_not_found.SimpleTest$Task, dep=GridDeployment
[ts=1539191791633, depMode=SHARED, clsLdr=GridDeploymentClassLoader
[id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
nodeLdrMap=HashMap
{c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
clsLdrId=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, userVer=0,
loc=false, sampleClsName=class_not_found.SimpleTest$Task,
pendingUndeploy=false, undeployed=false, usage=1]SharedDeployment [rmv=false,
super=], taskClsName=class_not_found.SimpleTest$Task,
sesId=f6acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
startTime=1539191791465, endTime=9223372036854775807,
taskNodeId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
clsLdr=GridDeploymentClassLoader
[id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
nodeLdrMap=HashMap
{c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], closed=false,
cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=false,
topPred=null, subjId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
mapFut=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
hash=550280323]IgniteFuture [orig=], execName=null],
jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b]]
class org.apache.ignite.IgniteException:
class_not_found.SimpleTest$MyDomainObject
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6797)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1191)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1923)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
class_not_found.SimpleTest$MyDomainObject
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
at
[jira] [Assigned] (IGNITE-9702) Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default
[ https://issues.apache.org/jira/browse/IGNITE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-9702: - Assignee: (was: Mikhail Cherkasov) > Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default > > > Key: IGNITE-9702 > URL: https://issues.apache.org/jira/browse/IGNITE-9702 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Priority: Blocker > Fix For: 3.0 > > > Right now: > BinObjectImpl(a=1,b=2) != BinObjectImpl(b=2,a=1), so hash code of binary > object depends of fields order and for ignite it's too different objects. > It's unclear and counter-intuitive for a user. > However, this can not be changed till 3.0, because it breaks compatibility > with existent storage and requites migration with downtime and an util that > will migrate binary objects to a new internal fields order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9702) Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default
[ https://issues.apache.org/jira/browse/IGNITE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9702: -- Description: Right now: BinObjectImpl(a=1,b=2) != BinObjectImpl(b=2,a=1), so hash code of binary object depends of fields order and for ignite it's too different objects. It's unclear and counter-intuitive for a user. However, this can not be changed till 3.0, because it breaks compatibility with existent storage and requites migration with downtime and an util that will migrate binary objects to a new internal fields order. was: Right now: BinObjectImpl(a=1,b=2) != BinObjectImpl(a=2,b=1), so hash code of binary object depends of fields order and for ignite it's too different objects. It's unclear and counter-intuitive for a user. However, this can not be changed till 3.0, because it breaks compatibility with existent storage and requites migration with downtime and an util that will migrate binary objects to a new internal fields order. > Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default > > > Key: IGNITE-9702 > URL: https://issues.apache.org/jira/browse/IGNITE-9702 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 3.0 > > > Right now: > BinObjectImpl(a=1,b=2) != BinObjectImpl(b=2,a=1), so hash code of binary > object depends of fields order and for ignite it's too different objects. > It's unclear and counter-intuitive for a user. > However, this can not be changed till 3.0, because it breaks compatibility > with existent storage and requites migration with downtime and an util that > will migrate binary objects to a new internal fields order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9702) Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default
[ https://issues.apache.org/jira/browse/IGNITE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-9702: - Assignee: Mikhail Cherkasov > Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default > > > Key: IGNITE-9702 > URL: https://issues.apache.org/jira/browse/IGNITE-9702 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 3.0 > > > Right now: > BinObjectImpl(a=1,b=2) != BinObjectImpl(a=2,b=1), so hash code of binary > object depends of fields order and for ignite it's too different objects. > It's unclear and counter-intuitive for a user. > However, this can not be changed till 3.0, because it breaks compatibility > with existent storage and requites migration with downtime and an util that > will migrate binary objects to a new internal fields order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-7196: -- Fix Version/s: (was: 2.7) 2.8 > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.8 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, >
[jira] [Updated] (IGNITE-7793) SQL does not work if value has sql field which name equals to affinity key name
[
https://issues.apache.org/jira/browse/IGNITE-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-7793:
--
Fix Version/s: (was: 2.7)
2.8
> SQL does not work if value has sql field which name equals to affinity key
> name
> ---
>
> Key: IGNITE-7793
> URL: https://issues.apache.org/jira/browse/IGNITE-7793
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Maxim Pudov
>Priority: Major
> Fix For: 2.8
>
>
> SQL does not work if value has index filed which name equals to affinity key
> name:
> {code:java}
> public class AKey {
> @AffinityKeyMapped
> int a;
> public AKey(int a) {
> this.a = a;
> }
> }
> public class AVal {
> @QuerySqlField
> int a;
> public AVal(int a) {
> this.a = a;
> }
> }
> AKey aKey = new AKey(1);
> AVal aVal = new AVal(0);
> IgniteCache cache = ignite.cache("Instrument");
> cache.put(aKey, aVal);
> SqlFieldsQuery query = new SqlFieldsQuery("select * from \"Instrument\".AVal
> it where it.a=?");
> List> res = cache.query(query.setArgs(0)).getAll();
> if(res.isEmpty()) {
> System.out.println("! FAILED !!!");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-7883:
--
Fix Version/s: (was: 2.7)
2.8
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Attachments: TC recheck 01.png, TC recheck 02.png, TC recheck 03.png,
> TC recheck 04.png, TC.png
>
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7231) Cassandra-sessions-pool is running after Ignition.stop
[ https://issues.apache.org/jira/browse/IGNITE-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-7231: -- Fix Version/s: (was: 2.7) 2.8 > Cassandra-sessions-pool is running after Ignition.stop > -- > > Key: IGNITE-7231 > URL: https://issues.apache.org/jira/browse/IGNITE-7231 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Anton Kurbanov >Priority: Minor > Fix For: 2.8 > > Attachments: ThreadDump.txt > > > Cassandra-sessions-pool is running after Ignition.stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9184: -- Fix Version/s: (was: 2.7) 2.8 > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7028) Memcached does not set type flags for response
[ https://issues.apache.org/jira/browse/IGNITE-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-7028: -- Fix Version/s: (was: 2.7) 2.8 > Memcached does not set type flags for response > -- > > Key: IGNITE-7028 > URL: https://issues.apache.org/jira/browse/IGNITE-7028 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > Memcached does not set type flags for response: > http://apache-ignite-users.70518.x6.nabble.com/Memcached-doesn-t-store-flags-td18403.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7458) NPE occurs after node restart with native persistence enabled.
[ https://issues.apache.org/jira/browse/IGNITE-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-7458: -- Fix Version/s: (was: 2.7) 2.8 > NPE occurs after node restart with native persistence enabled. > -- > > Key: IGNITE-7458 > URL: https://issues.apache.org/jira/browse/IGNITE-7458 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > We have a report from a user: > [http://apache-ignite-users.70518.x6.nabble.com/NPE-from-the-native-persistence-enable-node-td19555.html] > > it says that NPE occurred after node restart with native persistence enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9702) Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default
Mikhail Cherkasov created IGNITE-9702: - Summary: Make IGNITE_BINARY_SORT_OBJECT_FIELDS enabled by default Key: IGNITE-9702 URL: https://issues.apache.org/jira/browse/IGNITE-9702 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov Fix For: 3.0 Right now: BinObjectImpl(a=1,b=2) != BinObjectImpl(a=2,b=1), so hash code of binary object depends of fields order and for ignite it's too different objects. It's unclear and counter-intuitive for a user. However, this can not be changed till 3.0, because it breaks compatibility with existent storage and requites migration with downtime and an util that will migrate binary objects to a new internal fields order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4575) Implement wrapper for enums based on H2 user value type
[ https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621770#comment-16621770 ] Mikhail Cherkasov commented on IGNITE-4575: --- [~vozerov] , could you please take a look at this ticket, do we still have blockers from H2 side? if not, might be it makes sense to target it to further release 2.7 or 2.8? > Implement wrapper for enums based on H2 user value type > --- > > Key: IGNITE-4575 > URL: https://issues.apache.org/jira/browse/IGNITE-4575 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-engine > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16614603#comment-16614603
]
Mikhail Cherkasov commented on IGNITE-9600:
---
[~antkr] clarified that I used "AND" instead of ",", after fixing query it
works fine.
I think this syntax error should be handled and explained to a user by some
clear message.
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Minor
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-9600:
--
Priority: Minor (was: Blocker)
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Minor
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-9600:
--
Attachment: TwoFieldUpdate.java
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Blocker
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9600) SQL update fails if the sql updates more than one field
Mikhail Cherkasov created IGNITE-9600:
-
Summary: SQL update fails if the sql updates more than one field
Key: IGNITE-9600
URL: https://issues.apache.org/jira/browse/IGNITE-9600
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.6
Reporter: Mikhail Cherkasov
SQL update fails if the sql updates more than one field:
{noformat}
Exception in thread "main" javax.cache.CacheException: Failed to execute map
query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
errMsg=Failed to execute SQL query. Data conversion error converting "Entity2";
SQL statement:
SELECT
__Z0._KEY __C0_0,
__Z0._VAL __C0_1,
((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
FROM PUBLIC.ENTITY_TABLE __Z0
WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
at
org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){noformat}
Looks like ignite or underlying h2 engine generates query incorrectly:
((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
the name for first field is missed.
The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9527) NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test
[ https://issues.apache.org/jira/browse/IGNITE-9527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov closed IGNITE-9527. - Ignite Flags: (was: Docs Required) > NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test > --- > > Key: IGNITE-9527 > URL: https://issues.apache.org/jira/browse/IGNITE-9527 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > The wrong assertion was removed by the following ticket: > https://issues.apache.org/jira/browse/IGNITE-5510, however, NPE exception can > be observed in logs, so if [~sboikov] said that this method can be called > concurrently and it's valid to have null here, then I think we should remove > NPE from logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9527) NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test
[ https://issues.apache.org/jira/browse/IGNITE-9527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-9527. --- Resolution: Not A Problem 5510 fixed the issue completely, can't reproduce on master. > NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test > --- > > Key: IGNITE-9527 > URL: https://issues.apache.org/jira/browse/IGNITE-9527 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > The wrong assertion was removed by the following ticket: > https://issues.apache.org/jira/browse/IGNITE-5510, however, NPE exception can > be observed in logs, so if [~sboikov] said that this method can be called > concurrently and it's valid to have null here, then I think we should remove > NPE from logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9527) NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test
Mikhail Cherkasov created IGNITE-9527: - Summary: NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test Key: IGNITE-9527 URL: https://issues.apache.org/jira/browse/IGNITE-9527 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov The wrong assertion was removed by the following ticket: https://issues.apache.org/jira/browse/IGNITE-5510, however, NPE exception can be observed in logs, so if [~sboikov] said that this method can be called concurrently and it's valid to have null here, then I think we should remove NPE from logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9488) GridSpringCacheManagerMultiJvmSelfTest#testSyncCache test hangs
[ https://issues.apache.org/jira/browse/IGNITE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-9488: - Assignee: Mikhail Cherkasov > GridSpringCacheManagerMultiJvmSelfTest#testSyncCache test hangs > --- > > Key: IGNITE-9488 > URL: https://issues.apache.org/jira/browse/IGNITE-9488 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Minor > > GridSpringCacheManagerMultiJvmSelfTest#testSyncCache test hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9488) GridSpringCacheManagerMultiJvmSelfTest#testSyncCache test hangs
Mikhail Cherkasov created IGNITE-9488: - Summary: GridSpringCacheManagerMultiJvmSelfTest#testSyncCache test hangs Key: IGNITE-9488 URL: https://issues.apache.org/jira/browse/IGNITE-9488 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov GridSpringCacheManagerMultiJvmSelfTest#testSyncCache test hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6167) Ability to enabled TLS protocols and cipher suites
[
https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585278#comment-16585278
]
Mikhail Cherkasov commented on IGNITE-6167:
---
[~vozerov]
# fixed
# tests added for thin client, JDBC doesn't have an option to configure
protocols and cipher suites. I will add string parameters for this.
# I'm not sure that ignite can be configured this way, I see that ignite
configuration have only one common configuration for discovery and
communication SPI. Might be I missed something, could you please explain how to
configure SSL separately for discovery and communication?
> Ability to enabled TLS protocols and cipher suites
> --
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
> Issue Type: Wish
> Components: security
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> It would be very useful to be able to, in addition to the
> {{javax.net.ssl.SSLContext}}, either specify a custom
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the
> enabled TLS protocols and cipher suites.
> I have noticed that the
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for
> the latter but I cannot find a way of getting a reference to the filter
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled
> cipher suites and protocols used by Ignite, without doing it globally for the
> JRE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9200) Continuous query notifications can be missed if entry processor is retried due to binary type registration
[ https://issues.apache.org/jira/browse/IGNITE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov closed IGNITE-9200. - > Continuous query notifications can be missed if entry processor is retried > due to binary type registration > -- > > Key: IGNITE-9200 > URL: https://issues.apache.org/jira/browse/IGNITE-9200 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.7 > > Attachments: InvokeAllContinuousQueryTest.java > > > Due to fix introduced in IGNITE-8926, entry processor will be retried if it > triggers binary meta data registration. However, such retries may cause loss > of continuous query notifications. > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9200) Continuous query notifications can be missed if entry processor is retried due to binary type registration
[ https://issues.apache.org/jira/browse/IGNITE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-9200. --- Resolution: Won't Fix The issue is fixed as part of IGNITE-8926 > Continuous query notifications can be missed if entry processor is retried > due to binary type registration > -- > > Key: IGNITE-9200 > URL: https://issues.apache.org/jira/browse/IGNITE-9200 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.7 > > Attachments: InvokeAllContinuousQueryTest.java > > > Due to fix introduced in IGNITE-8926, entry processor will be retried if it > triggers binary meta data registration. However, such retries may cause loss > of continuous query notifications. > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[
https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570181#comment-16570181
]
Mikhail Cherkasov commented on IGNITE-9184:
---
Stacktraces shows that client and server node are stuck on initial exchange:
{code:java}
"Thread-0" #10 prio=5 os_prio=31 tid=0x7fd2a28e7800 nid=0x4003 waiting on
condition [0x751c8000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:632)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:865)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1043)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
- locked <0x0006d9f1e598> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
at org.apache.ignite.Ignition.start(Ignition.java:327)
at continues_query.StressTest$StartStopTask.run(StressTest.java:201)
at java.lang.Thread.run(Thread.java:748)
"main" #1 prio=5 os_prio=31 tid=0x7fd2a3800800 nid=0x2503 waiting on
condition [0x74218000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:632)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:865)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1043)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
- locked <0x0006de0aa3b0> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
at org.apache.ignite.Ignition.start(Ignition.java:327)
at continues_query.StressTest.main(StressTest.java:81)
{code}
I don't see any other stuck threads.
> Cluster hangs during concurrent node restart and continues query registration
> -
>
> Key: IGNITE-9184
> URL: https://issues.apache.org/jira/browse/IGNITE-9184
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Assignee: Dmitriy Govorukhin
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: StressTest.java, logs, stacktrace
>
>
> Please check the attached test case and stack trace.
> I can see: "Failed to wait for initial partition map exchange" message.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9184: -- Attachment: logs > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Priority: Critical > Fix For: 2.7 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
Mikhail Cherkasov created IGNITE-9184: - Summary: Cluster hangs during concurrent node restart and continues query registration Key: IGNITE-9184 URL: https://issues.apache.org/jira/browse/IGNITE-9184 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.6 Reporter: Mikhail Cherkasov Fix For: 2.7 Attachments: StressTest.java, stacktrace Please check the attached test case and stack trace. I can see: "Failed to wait for initial partition map exchange" message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6167) Ability to enabled TLS protocols and cipher suites
[
https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-6167:
--
Summary: Ability to enabled TLS protocols and cipher suites (was: Ability
to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS
protocols and cipher suites)
> Ability to enabled TLS protocols and cipher suites
> ---
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
> Issue Type: Wish
> Components: security
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> It would be very useful to be able to, in addition to the
> {{javax.net.ssl.SSLContext}}, either specify a custom
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the
> enabled TLS protocols and cipher suites.
> I have noticed that the
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for
> the latter but I cannot find a way of getting a reference to the filter
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled
> cipher suites and protocols used by Ignite, without doing it globally for the
> JRE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6167) Ability to enabled TLS protocols and cipher suites
[
https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-6167:
--
Summary: Ability to enabled TLS protocols and cipher suites (was: Ability
to enabled TLS protocols and cipher suites)
> Ability to enabled TLS protocols and cipher suites
> --
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
> Issue Type: Wish
> Components: security
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> It would be very useful to be able to, in addition to the
> {{javax.net.ssl.SSLContext}}, either specify a custom
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the
> enabled TLS protocols and cipher suites.
> I have noticed that the
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for
> the latter but I cannot find a way of getting a reference to the filter
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled
> cipher suites and protocols used by Ignite, without doing it globally for the
> JRE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6167) Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS protocols and cipher suites
[
https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565318#comment-16565318
]
Mikhail Cherkasov commented on IGNITE-6167:
---
[~vozerov] could you please review my changes?
> Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled
> TLS protocols and cipher suites
>
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
> Issue Type: Wish
> Components: security
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> It would be very useful to be able to, in addition to the
> {{javax.net.ssl.SSLContext}}, either specify a custom
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the
> enabled TLS protocols and cipher suites.
> I have noticed that the
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for
> the latter but I cannot find a way of getting a reference to the filter
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled
> cipher suites and protocols used by Ignite, without doing it globally for the
> JRE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9099) IgniteCache java doc does not cover all possible exceptions
Mikhail Cherkasov created IGNITE-9099: - Summary: IgniteCache java doc does not cover all possible exceptions Key: IGNITE-9099 URL: https://issues.apache.org/jira/browse/IGNITE-9099 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov IgniteCache java doc does not cover all possible exceptions. For example on if try to close cache after node stop there would be the following exception: org.apache.ignite.IgniteException: Failed to execute dynamic cache change request, node is stopping. at org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:986) at org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:168) at org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137) at org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.close(GatewayProtectedCacheProxy.java:1346) However, API for close method doesn't mention any exception at all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6167) Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS protocols and cipher suites
[
https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov reassigned IGNITE-6167:
-
Assignee: Mikhail Cherkasov
> Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled
> TLS protocols and cipher suites
>
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
> Issue Type: Wish
> Components: security
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> It would be very useful to be able to, in addition to the
> {{javax.net.ssl.SSLContext}}, either specify a custom
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the
> enabled TLS protocols and cipher suites.
> I have noticed that the
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for
> the latter but I cannot find a way of getting a reference to the filter
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled
> cipher suites and protocols used by Ignite, without doing it globally for the
> JRE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
Mikhail Cherkasov created IGNITE-8985: - Summary: Node segmented itself after connRecoveryTimeout Key: IGNITE-8985 URL: https://issues.apache.org/jira/browse/IGNITE-8985 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov Attachments: Archive.zip I can see the following message in logs: [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect to next nodes in a ring, it seems local node is experiencing connectivity issues. Segmenting local node to avoid case when one node fails a big part of cluster. To disable that behavior set TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, ver=2.4.7#20180710-sha1:a48ae923, isClient=false] I have failure detection time out 60_000 and during the test I had GC <25secs, so I don't expect that node should be segmented. Logs are attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8968) Failed to shutdown node due to "Error saving backup value"
[ https://issues.apache.org/jira/browse/IGNITE-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539304#comment-16539304 ] Mikhail Cherkasov commented on IGNITE-8968: --- [~pvinokurov] I think just adding break would mean that we don't process this propertly and don't send responce to primary(or client might be?) and we will get "long running atomic update future" or something like this. I think we need explicitly check that error was caused by ignite stop and only then break cycle. In this case on node_left event, all futures related to this node will be handled properly(canceled with an error or finished?) > Failed to shutdown node due to "Error saving backup value" > -- > > Key: IGNITE-8968 > URL: https://issues.apache.org/jira/browse/IGNITE-8968 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > On node shutdown ignite prints following logs infinitely: > org.apache.ignite.internal.NodeStoppingException: Operation has been > cancelled (node is stopping). > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3626) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2783) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.process(GridCacheUtils.java:1734) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1782) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1724) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8941) BinaryInvalidTypeException is thrown on invoke
Mikhail Cherkasov created IGNITE-8941: - Summary: BinaryInvalidTypeException is thrown on invoke Key: IGNITE-8941 URL: https://issues.apache.org/jira/browse/IGNITE-8941 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Attachments: MyPocTest.java Reproducer is attached. The following exception is thrown: [2018-07-05 16:31:44,554][ERROR][Thread-6][GridDhtAtomicCache] Unexpected exception during cache update class org.apache.ignite.binary.BinaryInvalidTypeException: invoke0 at org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707) at org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757) at org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) at org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798) at org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143) at org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1312) at org.apache.ignite.internal.processors.cache.GridCacheReturn.addEntryProcessResult(GridCacheReturn.java:253) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2553) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:827) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1417) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1461) at org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1220) at my_poc_test.MyPocTest$InvokeTask.run(MyPocTest.java:172) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.ClassNotFoundException: invoke0 at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8640) at org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:349) at org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:698) ... 22 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8926: -- Attachment: file.jstack > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Attachments: file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8926: -- Attachment: (was: 11948_WorkdayFabricManager.jstack) > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Attachments: file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8926) Deadlock in meta data registration
Mikhail Cherkasov created IGNITE-8926: - Summary: Deadlock in meta data registration Key: IGNITE-8926 URL: https://issues.apache.org/jira/browse/IGNITE-8926 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Assignee: Ilya Lantukh Attachments: 11948_WorkdayFabricManager.jstack Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8908) NPE on discovery message processing
[
https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16532421#comment-16532421
]
Mikhail Cherkasov commented on IGNITE-8908:
---
The issue was reproduced with enabled assertions:
{code:java}
[2018-07-03 14:25:14,889][ERROR][tcp-disco-msg-worker-#2] Failed to unmarshal
discovery custom message.
java.lang.AssertionError: No metadata found for typeId -1381201447
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:442)
~[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:428)
~[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
~[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
~[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5518)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5344)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5378)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2804)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2571)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:6912)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2658)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:6856)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
[2018-07-03 14:25:14,891][ERROR][tcp-disco-msg-worker-#2] Failed to unmarshal
discovery custom message.{code}
> NPE on discovery message processing
> ---
>
> Key: IGNITE-8908
> URL: https://issues.apache.org/jira/browse/IGNITE-8908
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Attachments: ContinuousQueryTask.txt, RegisterTask.txt,
> ServiceTask.txt
>
>
> To reproduce the problem we do the the following steps:
> 1) start 4 server nodes
> 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask
> 3) restart 3 of 4 server nodes.
> The following exception is observed in logs:
> [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify
> direct custom event listener: MetadataUpdateAcceptedMessage
> [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526,
> acceptedVer=1, duplicated=false]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451)
> ~[ignite-core-2.x.x.jar:2.x.x]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418)
> ~[ignite-core-2.x.x.jar:2.x.x]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695)
> [ignite-core-2.x.x.jar:2.x.x]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577)
> [ignite-core-2.x.x.jar:2.x.x]
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453)
> [ignite-core-2.x.x.jar:2.x.x]
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279)
> [ignite-core-2.x.x.jar:2.x.x]
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313)
> [ignite-core-2.x.x.jar:2.x.x]
> at
>
[jira] [Updated] (IGNITE-8908) NPE on discovery message processing
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Summary: NPE on discovery message processing (was: NPE in BinaryMetadataTransport) > NPE on discovery message processing > --- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > Attachments: ContinuousQueryTask.txt, RegisterTask.txt, > ServiceTask.txt > > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes > 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask > 3) restart 3 of 4 server nodes. > The following exception is observed in logs: > [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.x.x.jar:2.x.x] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.x.x.jar:2.x.x] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE in BinaryMetadataTransport
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Attachment: ServiceTask.txt RegisterTask.txt ContinuousQueryTask.txt > NPE in BinaryMetadataTransport > -- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > Attachments: ContinuousQueryTask.txt, RegisterTask.txt, > ServiceTask.txt > > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes > 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask > 3) restart 3 of 4 server nodes. > The following exception is observed in logs: > [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.x.x.jar:2.x.x] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.x.x.jar:2.x.x] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE in BinaryMetadataTransport
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Description: To reproduce the problem we do the the following steps: 1) start 4 server nodes 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask 3) restart 3 of 4 server nodes. The following exception is observed in logs: [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify direct custom event listener: MetadataUpdateAcceptedMessage [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, acceptedVer=1, duplicated=false] java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) ~[ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) ~[ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) [ignite-core-2.x.x.jar:2.x.x] was: To reproduce the problem we run the following scenary: [2018-07-02 10:15:48,199][ERROR][tcp-disco-msg-worker-#2] Failed to notify direct custom event listener: MetadataUpdateAcceptedMessage [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, acceptedVer=1, duplicated=false] java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) [ignite-core-2.4.7.jar:2.4.7] > NPE in BinaryMetadataTransport > -- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes
[jira] [Created] (IGNITE-8908) NPE in BinaryMetadataTransport
Mikhail Cherkasov created IGNITE-8908: - Summary: NPE in BinaryMetadataTransport Key: IGNITE-8908 URL: https://issues.apache.org/jira/browse/IGNITE-8908 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE in BinaryMetadataTransport
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Description: To reproduce the problem we run the following scenary: [2018-07-02 10:15:48,199][ERROR][tcp-disco-msg-worker-#2] Failed to notify direct custom event listener: MetadataUpdateAcceptedMessage [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, acceptedVer=1, duplicated=false] java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) [ignite-core-2.4.7.jar:2.4.7] > NPE in BinaryMetadataTransport > -- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > > To reproduce the problem we run the following scenary: > > [2018-07-02 10:15:48,199][ERROR][tcp-disco-msg-worker-#2] Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.4.7.jar:2.4.7] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.4.7.jar:2.4.7] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8683) Tests fail after IGNITE-6639
[ https://issues.apache.org/jira/browse/IGNITE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527624#comment-16527624 ] Mikhail Cherkasov commented on IGNITE-8683: --- [~agoncharuk] I fixed this, now first I check for port equality, then I check if address equals to local OR if we listens on 0:0:0:0 I check if remote address belongs to any local interface. > Tests fail after IGNITE-6639 > > > Key: IGNITE-8683 > URL: https://issues.apache.org/jira/browse/IGNITE-8683 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > Example of failed tests: > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeSelfTest#testDeployOnEachNodeButClientUpdateTopology > > instead of checking address for loopback we should compare addr with locHost, > because nodes can use the same port, but different local address and both > addresses can be loopback. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8683) Tests fail after IGNITE-6639
[ https://issues.apache.org/jira/browse/IGNITE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527624#comment-16527624 ] Mikhail Cherkasov edited comment on IGNITE-8683 at 6/29/18 1:22 PM: [~agoncharuk] I fixed this, now first I check for port equality, then I check if address equals to local OR if we listen on 0:0:0:0 I check if remote address belongs to any local interface. was (Author: mcherkasov): [~agoncharuk] I fixed this, now first I check for port equality, then I check if address equals to local OR if we listens on 0:0:0:0 I check if remote address belongs to any local interface. > Tests fail after IGNITE-6639 > > > Key: IGNITE-8683 > URL: https://issues.apache.org/jira/browse/IGNITE-8683 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > Example of failed tests: > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeSelfTest#testDeployOnEachNodeButClientUpdateTopology > > instead of checking address for loopback we should compare addr with locHost, > because nodes can use the same port, but different local address and both > addresses can be loopback. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8847) Node doesn't stop on node verification failure
[ https://issues.apache.org/jira/browse/IGNITE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-8847. --- Resolution: Cannot Reproduce I wasn't able to reproduce the problem with the latest version of ignite. > Node doesn't stop on node verification failure > -- > > Key: IGNITE-8847 > URL: https://issues.apache.org/jira/browse/IGNITE-8847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.7 > > > Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8847) Node doesn't stop on node verification failure
[ https://issues.apache.org/jira/browse/IGNITE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8847: -- Fix Version/s: 2.6 > Node doesn't stop on node verification failure > -- > > Key: IGNITE-8847 > URL: https://issues.apache.org/jira/browse/IGNITE-8847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.6 > > > Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8847) Node doesn't stop on node verification failure
Mikhail Cherkasov created IGNITE-8847: - Summary: Node doesn't stop on node verification failure Key: IGNITE-8847 URL: https://issues.apache.org/jira/browse/IGNITE-8847 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8847) Node doesn't stop on node verification failure
[ https://issues.apache.org/jira/browse/IGNITE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8847: -- Affects Version/s: 2.5 > Node doesn't stop on node verification failure > -- > > Key: IGNITE-8847 > URL: https://issues.apache.org/jira/browse/IGNITE-8847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8845) GridUnsafe.allocateMemory throws OutOfMemoryError which isn't handled
Mikhail Cherkasov created IGNITE-8845: - Summary: GridUnsafe.allocateMemory throws OutOfMemoryError which isn't handled Key: IGNITE-8845 URL: https://issues.apache.org/jira/browse/IGNITE-8845 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.5 Reporter: Mikhail Cherkasov Fix For: 2.6 Attachments: Main.java If there's no more native memory then Unsafe.allocateMemor throws java.lang.OutOfMemoryError. Errors - is type of exception after which you can't restore application and you need to close it and restart. I think in this case we can handle it and throw IgniteOOM instead. Reproducer is attached, it throws the following exception: Exception in thread "main" java.lang.OutOfMemoryError at sun.misc.Unsafe.allocateMemory(Native Method) at org.apache.ignite.internal.util.GridUnsafe.allocateMemory(GridUnsafe.java:1068) at org.apache.ignite.internal.mem.unsafe.UnsafeMemoryProvider.nextRegion(UnsafeMemoryProvider.java:80) at org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.addSegment(PageMemoryNoStoreImpl.java:612) at org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.allocatePage(PageMemoryNoStoreImpl.java:287) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8683) Tests fail after IGNITE-6639
[ https://issues.apache.org/jira/browse/IGNITE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512543#comment-16512543 ] Mikhail Cherkasov commented on IGNITE-8683: --- [~dpavlov] TC looks good: [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4109%2Fhead] [~agoncharuk] could you please take a look at this changeset and push it to master repo? > Tests fail after IGNITE-6639 > > > Key: IGNITE-8683 > URL: https://issues.apache.org/jira/browse/IGNITE-8683 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > Example of failed tests: > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeSelfTest#testDeployOnEachNodeButClientUpdateTopology > > instead of checking address for loopback we should compare addr with locHost, > because nodes can use the same port, but different local address and both > addresses can be loopback. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8799) Web agent hides connection exceptions
Mikhail Cherkasov created IGNITE-8799: - Summary: Web agent hides connection exceptions Key: IGNITE-8799 URL: https://issues.apache.org/jira/browse/IGNITE-8799 Project: Ignite Issue Type: Bug Components: visor Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Web agent hides connection exceptions and this discourage analysis of connection problems -- This message was sent by Atlassian JIRA (v7.6.3#76005)
