[jira] [Updated] (IGNITE-13038) Phase out Ignite Web Console
[ https://issues.apache.org/jira/browse/IGNITE-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13038: --- Fix Version/s: (was: 2.9) 2.10 > Phase out Ignite Web Console > > > Key: IGNITE-13038 > URL: https://issues.apache.org/jira/browse/IGNITE-13038 > Project: Ignite > Issue Type: Improvement >Reporter: Denis A. Magda >Assignee: Alexey Kuznetsov >Priority: Critical > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > The community voted to stop the development and maintenance of Ignite Web > Console: > http://apache-ignite-developers.2346864.n4.nabble.com/RESULT-VOTE-Stop-Maintenance-of-Ignite-Web-Console-td47548.html > The following needs to be done: > * Move the tool's source code from the Ignite core to its own repository > (https://github.com/apache/ignite-web-console) > * Update the repository description highlighting that the tool is no longer > supported by the community. > * Unlist Web Console documentation from the navigation and main menus. Do NOT > remove as long as there are many pages referring to the docs. Just hide. > * Put a callout on all the hidden documentation pages saying that the tool's > source code is archived (provide a reference to the repo). > * Close all the JIRA tickets created for Web Console with the notice that the > tool is discontinued and no longer supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12550) Add page read latency histogram per data region
[
https://issues.apache.org/jira/browse/IGNITE-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12550:
---
Fix Version/s: (was: 2.9)
2.10
> Add page read latency histogram per data region
> ---
>
> Key: IGNITE-12550
> URL: https://issues.apache.org/jira/browse/IGNITE-12550
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
>
> During an incident I experienced a large checkpoint mark duration. It was
> impossible to determine whether this was caused by a stalled disk because of
> large number of long page reads or by some other reasons.
> Having a metric showing the page read latency histogram would help in such
> cases.
> We already have a {{pagesRead}} metric, just need to measure the read timings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12694) A possible partition desync if last supplier has left and returned later.
[ https://issues.apache.org/jira/browse/IGNITE-12694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12694: --- Fix Version/s: 2.10 > A possible partition desync if last supplier has left and returned later. > - > > Key: IGNITE-12694 > URL: https://issues.apache.org/jira/browse/IGNITE-12694 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Fix For: 2.10 > > > Consider the scenario: > Two nodes A and B in the grid. > 1. B is rebalancing from A. > 2. Before rebalancing is finished A has left, partitions on B have stale data. > 3. A returns to the topology. > Rebalancing will not start without manual intervention, because update > counters for partitions will be same. > This happens because LWM is assigned during PME before actual updates are > loaded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12694) A possible partition desync if last supplier has left and returned later.
[ https://issues.apache.org/jira/browse/IGNITE-12694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12694: --- Fix Version/s: (was: 2.9) > A possible partition desync if last supplier has left and returned later. > - > > Key: IGNITE-12694 > URL: https://issues.apache.org/jira/browse/IGNITE-12694 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > Consider the scenario: > Two nodes A and B in the grid. > 1. B is rebalancing from A. > 2. Before rebalancing is finished A has left, partitions on B have stale data. > 3. A returns to the topology. > Rebalancing will not start without manual intervention, because update > counters for partitions will be same. > This happens because LWM is assigned during PME before actual updates are > loaded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12610:
---
Fix Version/s: (was: 2.9)
2.10
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12451) Introduce deadlock detection for cache entry reentrant locks
[ https://issues.apache.org/jira/browse/IGNITE-12451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12451: --- Fix Version/s: (was: 2.9) 2.10 > Introduce deadlock detection for cache entry reentrant locks > > > Key: IGNITE-12451 > URL: https://issues.apache.org/jira/browse/IGNITE-12451 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Ivan Rakov >Assignee: Mirza Aliev >Priority: Major > Fix For: 2.10 > > > Aside from IGNITE-12365, we still have possible threat of cache-entry-level > deadlock in case of careless usage of JCache mass operations (putAll, > removeAll): > 1. If two different user threads will perform putAll on the same two keys in > reverse order (primary node for which is the same), there's a chance that > sys-stripe threads will be deadlocked. > 2. Even without direct contract violation from user side, HashMap can be > passed as argument for putAll. Even if user threads have called mass > operations with two keys in the same order, HashMap iteration order is not > strictly defined, which may cause the same deadlock. > Local deadlock detection should mitigate this issue. We can create a wrapper > for ReentrantLock with logic that performs cycle detection in wait-for graph > in case we are waiting for lock acquisition for too long. Exception will be > thrown from one of the threads in such case, failing user operation, but > letting the system make progress. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12414) .NET: Performance: review CopyOnWriteConcurrentDictionary.GetOrAdd usage and locking
[ https://issues.apache.org/jira/browse/IGNITE-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12414: --- Fix Version/s: (was: 2.9) 2.10 > .NET: Performance: review CopyOnWriteConcurrentDictionary.GetOrAdd usage and > locking > > > Key: IGNITE-12414 > URL: https://issues.apache.org/jira/browse/IGNITE-12414 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 3.0, 2.10 > > > CopyOnWriteConcurrentDictionary.GetOrAdd uses lock right away, while the > class assumes frequent reads and infrequent writes. It can be beneficial to > check for the key outside of the lock. > In particular, this often causes contention because of > BinarySystemHandlers.GetWriteHandler call. > Review other usages of this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8260) Transparent data encryption
[ https://issues.apache.org/jira/browse/IGNITE-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-8260: -- Fix Version/s: (was: 2.9) 2.10 > Transparent data encryption > --- > > Key: IGNITE-8260 > URL: https://issues.apache.org/jira/browse/IGNITE-8260 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-18 > Fix For: 2.10 > > > TDE feature should allow to user to protect data stored in the persistence > storage with some cypher algorithm. > Design details described in > [IEP-18|https://cwiki.apache.org/confluence/display/IGNITE/IEP-18%3A+Transparent+Data+Encryption]. > When this task will be done production ready TDE implementation should be > available for Ignite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12203) Rebalance is loading partitions already loading after cancellation without WAL
[ https://issues.apache.org/jira/browse/IGNITE-12203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12203: --- Fix Version/s: (was: 2.9) 2.10 > Rebalance is loading partitions already loading after cancellation without WAL > -- > > Key: IGNITE-12203 > URL: https://issues.apache.org/jira/browse/IGNITE-12203 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > I have seen from log partition miss warnings and after that rebelance was > canceled and was forcibly restarted but already over another suppliers. In > case when added nodes without a storage in persistent cluster it can lead to > several times fully rebalance. It seem to bee because we have not updated > partitions state until rebalance finished. > Should to prevent partition eviction until rebalance on all nodes completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12956) Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads
[
https://issues.apache.org/jira/browse/IGNITE-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12956:
---
Fix Version/s: (was: 2.9)
2.10
> Fully prepared TX rolled back on recovery if TX coordinator failed and some
> primary has only reads
> --
>
> Key: IGNITE-12956
> URL: https://issues.apache.org/jira/browse/IGNITE-12956
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have 3 nodes with partitioned cache with 2 backups.
> A - tx coordinator.
> B and C - other nodes.
> Let's start tx from A and perform
> {noformat}
> cache.put(primaryKeyA, someVal);
> cache.get(primaryKeyB;
> tx.prepare();
> {noformat}
> then kill A.
> Expected: tx recovered and
> {noformat}
> cache.get(primaryKeyA)!=null
> {noformat}
> Actual: tx rolled back and
> and
> {noformat}
> cache.get(primaryKeyA)==null
> {noformat}
> Reason: Node C has only 1 active transaction (because reads not propagated to
> backup), but expect to have 2.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12793) Deadlock in the System Pool on Metadata processing
[
https://issues.apache.org/jira/browse/IGNITE-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12793:
---
Fix Version/s: (was: 2.9)
2.10
> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.7.6
>Reporter: Sergey Kosarev
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.10
>
> Attachments: ignite-12793-threaddump.txt
>
>
> I've recently tried to apply Ilya's idea
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread
> pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only on
> such small pool values.
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to call a job on every server node
> (there are 3 server nodes in the tests).
> Then I've found in logs:
> {noformat}
> [10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
> grid-timeout-worker-#8
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no
> task completed in last 3ms, is system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]
> {noformat}
> I see in threaddumps that all 3 system pool workers do the same - processing
> of job responses:
> {noformat}
> "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
> waiting on condition [0x7b91d000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
> at
>
[jira] [Updated] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9005:
--
Fix Version/s: (was: 2.9)
2.10
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Pavlov
>Assignee: Nikolai Kulagin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13054) Prevent nodes with stale data joining the active topology.
[ https://issues.apache.org/jira/browse/IGNITE-13054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13054: --- Fix Version/s: (was: 2.9) 2.10 > Prevent nodes with stale data joining the active topology. > -- > > Key: IGNITE-13054 > URL: https://issues.apache.org/jira/browse/IGNITE-13054 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Priority: Major > Fix For: 2.10 > > > After IGNITE-13003 LOST state is preserved then nodes with lost data are > retuned to topology after failure. > If resetting is performed on lesser topology, it's possible to get into > sutiation where a node with most recent data is returned to active topology > where some key already could be modified. > This should not be allowed because brings conflicting data into grid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12982) NullPointerException on TcpCommunicationMetricsListener for some of the cases
[
https://issues.apache.org/jira/browse/IGNITE-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12982:
---
Fix Version/s: (was: 2.9)
2.10
> NullPointerException on TcpCommunicationMetricsListener for some of the cases
> -
>
> Key: IGNITE-12982
> URL: https://issues.apache.org/jira/browse/IGNITE-12982
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.10
>
>
> The code block below throws an {{NullPointerException}} for some of the
> cases. Investigation required.
> {code}
> @Override public void onMessageSent(GridNioSession ses, Message
> msg) {
> Object consistentId = ses.meta(CONSISTENT_ID_META);
> if (consistentId != null)
> metricsLsnr.onMessageSent(msg, consistentId);
> }
> {code}
> {code}
> [2020-05-04
> 18:12:12,991][ERROR][grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%][TestRecordingCommunicationSpi]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=0,
> bytesRcvd=42, bytesSent=18, bytesRcvd0=42, bytesSent0=18, select=true,
> super=GridWorker [name=grid-nio-worker-tcp-comm-0,
> igniteInstanceName=snapshot.IgniteClusterSnapshotSelfTest2, finished=false,
> heartbeatTs=1588605131981, hashCode=1038334332, interrupted=false,
> runner=grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%]]],
> writeBuf=java.nio.DirectByteBuffer[pos=10 lim=32768 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> outRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> closeSocket=true,
> outboundMessagesQueueSizeMetric=o.a.i.i.processors.metric.impl.LongAdderMetric@69a257d1,
> super=GridNioSessionImpl [locAddr=/127.0.0.1:47102,
> rmtAddr=/127.0.0.1:50655, createTime=1588605131981, closeTime=0,
> bytesSent=18, bytesRcvd=42, bytesSent0=18, bytesRcvd0=42,
> sndSchedTime=1588605131981, lastSndTime=1588605131981,
> lastRcvTime=1588605131981, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter
> [parser=o.a.i.i.util.nio.GridDirectParser@fc19b0b, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=true, markedForClose=true]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:803)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:472)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.onMessageWritten(GridNioServer.java:1764)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.access$1800(GridNioServer.java:99)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite0(GridNioServer.java:1665)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite(GridNioServer.java:1365)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2437)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2201)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1842)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [2020-05-04
> 18:12:12,993][ERROR][grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%][TestRecordingCommunicationSpi]
[jira] [Updated] (IGNITE-12941) .NET: Support .NET 5
[
https://issues.apache.org/jira/browse/IGNITE-12941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12941:
---
Fix Version/s: (was: 2.9)
2.10
> .NET: Support .NET 5
>
>
> Key: IGNITE-12941
> URL: https://issues.apache.org/jira/browse/IGNITE-12941
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, newbie
> Fix For: 2.10
>
>
> .NET 5 is in preview. Ignite.NET does not seem to work there. Tested on
> Ubuntu:
> * Install .NET 5 SDK from Snap
> * Create new console app, add Apache.Ignite nuget package
> * Add Ignition.Start
> * dotnet run
> {code}
> Unhandled exception. Apache.Ignite.Core.Common.IgniteException: Failed to
> load libjvm.so:
> [option=/usr/bin/java,
> path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
> error=Unknown error]
> [option=/usr/bin/java,
> path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
> error=/snap/core18/current/lib/x86_64-linux-gnu/libm.so.6: version
> `GLIBC_2.29' not found (required by
> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)]
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at dotnet5.Program.Main(String[] args) in
> /home/pavel/w/tests/dotnet5/Program.cs:line 10
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13053) resetLostPartitions is not working if invoked from a node where a cache not started
[ https://issues.apache.org/jira/browse/IGNITE-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13053: --- Fix Version/s: (was: 2.9) 2.10 > resetLostPartitions is not working if invoked from a node where a cache not > started > --- > > Key: IGNITE-13053 > URL: https://issues.apache.org/jira/browse/IGNITE-13053 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Priority: Major > Fix For: 2.10 > > > Reproduced by CachePartitionLossWithRestartsTest and an attemp to reset lost > policies using node with index=nonAffIdx -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13101) Metastore may leave uncompleted write futures during node stop
[
https://issues.apache.org/jira/browse/IGNITE-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13101:
---
Fix Version/s: (was: 2.9)
2.10
> Metastore may leave uncompleted write futures during node stop
> --
>
> Key: IGNITE-13101
> URL: https://issues.apache.org/jira/browse/IGNITE-13101
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
>
> I've got the following thread-dump (only relevant parts are retained) during
> one of the teamcity runs:
> {code}
> "sys-#103862%baseline.IgniteStableBaselineBinObjFieldsQuerySelfTest0%"
> #107048 prio=5 os_prio=0 tid=0x7fa2d8009800 nid=0x480d waiting on
> condition [0x7fa1d1cdc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.remove(GridMetricManager.java:411)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.remove(CacheGroupMetricsImpl.java:497)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:512)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCacheGroup(GridCacheProcessor.java:2901)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCacheGroup(GridCacheProcessor.java:2889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCacheStopRequestOnExchangeDone(GridCacheProcessor.java:2781)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2878)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2431)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$200(GridDhtPartitionsExchangeFuture.java:154)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2994)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2982)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2982)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1989)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.preprocessSingleMessage(GridCachePartitionExchangeManager.java:524)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1100(GridCachePartitionExchangeManager.java:182)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:407)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:389)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3715)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3694)
> at
>
[jira] [Updated] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had been closed before.
[
https://issues.apache.org/jira/browse/IGNITE-13102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13102:
---
Fix Version/s: (was: 2.9)
2.10
> IgniteCache#isClosed() returns false on server node even if the cache had
> been closed before.
> -
>
> Key: IGNITE-13102
> URL: https://issues.apache.org/jira/browse/IGNITE-13102
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.10
>
>
> IgniteCache#isClosed() still returns {{false}} even after
> {{IgniteCache#close()}}. Only server nodes affect by this problem.
> Simple reproducer:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx node = startGrid(0);
> IgniteCache cache =
> node.getOrCreateCache(DEFAULT_CACHE_NAME);
> assertFalse(cache.isClosed());
> cache.close();
> // java.lang.AssertionError
> assertTrue(cache.isClosed());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13169: --- Fix Version/s: (was: 2.9) 2.10 > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.10 > > Time Spent: 50m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13183) Query timeout redesign
[
https://issues.apache.org/jira/browse/IGNITE-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13183:
---
Fix Version/s: (was: 2.9)
2.10
> Query timeout redesign
> --
>
> Key: IGNITE-13183
> URL: https://issues.apache.org/jira/browse/IGNITE-13183
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>
> *Motivation:*
> Now the query timeout is set up for each node separately by the node
> configuration. This property isn't propagated for the all nodes of cluster.
> Also user cannot change / disable query timeout without restart all nodes of
> the cluster.
> *Proposal fix:*
> - Adds the default query timeout property to the
> {{DistributedSqlConfiguration}}. Use distributed metastore to store and
> manage the property.
> - Deprecates the {{SqlConfiguration#defaultQueryTimeout}} property and use it
> to set up initial value of new property
> {{DistributedSqlConfiguration#defaultQueryTimeout}}
> - Adds info about explicit query timeout to {{GridH2QueryRequest}} (boolean
> flag {{explicitTimeout=false}} by default). This is necessary so that the
> default timeout may be used for queries from old nodes.
> - When query timeout is set to zero by old node ({{explicitTimeout=false}})
> we assume this is the default value and use default timeout for this queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13174) C++: Add Windows support to CMake build system
[ https://issues.apache.org/jira/browse/IGNITE-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13174: --- Fix Version/s: (was: 2.9) > C++: Add Windows support to CMake build system > -- > > Key: IGNITE-13174 > URL: https://issues.apache.org/jira/browse/IGNITE-13174 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Ticket IGNITE-13078 adds CMake build system support, but only for Linux. Need > make sure it works on Windows and create TC job for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13116) CPP: Can not compile using msvc 14.1
[ https://issues.apache.org/jira/browse/IGNITE-13116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13116: --- Fix Version/s: (was: 2.9) 2.10 > CPP: Can not compile using msvc 14.1 > > > Key: IGNITE-13116 > URL: https://issues.apache.org/jira/browse/IGNITE-13116 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > There are linking errors when trying to build Ignite C++ with msvc 15. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12509) CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified RebalanceDelay
[ https://issues.apache.org/jira/browse/IGNITE-12509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12509: --- Fix Version/s: (was: 2.9) 2.10 > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified > RebalanceDelay > - > > Key: IGNITE-12509 > URL: https://issues.apache.org/jira/browse/IGNITE-12509 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: newbie > Fix For: 2.10 > > Attachments: RebalanceDelayTest.java > > > Steps to reproduce: > 1. Start in-memory cluster with 2 server nodes > 2. Start 3 caches with different rebalance delays (e.g. 5, 10 and 15 seconds) > and upload some data > 3. Start localListener for EVT_CACHE_REBALANCE_STOPPED event on one of the > nodes. > 4. Start one more server node. > 5. Wait for 5 seconds, till rebalance delay is reached. > 6. EVT_CACHE_REBALANCE_STOPPED event received 3 times (1 for each cache), but > in fact only 1 cache was rebalanced. The same happens for the rest of the > caches. > As result on rebalance finish we're getting event for each cache > [CACHE_COUNT] times, instead of 1. > Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13174) C++: Add Windows support to CMake build system
[ https://issues.apache.org/jira/browse/IGNITE-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13174: --- Fix Version/s: 2.10 > C++: Add Windows support to CMake build system > -- > > Key: IGNITE-13174 > URL: https://issues.apache.org/jira/browse/IGNITE-13174 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Ticket IGNITE-13078 adds CMake build system support, but only for Linux. Need > make sure it works on Windows and create TC job for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12822:
---
Fix Version/s: (was: 2.9)
2.10
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.10
>
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-7369: -- Fix Version/s: (was: 2.9) 2.10 > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, iep-34 > Fix For: 2.10 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13148) Thin Client Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-13148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13148: --- Fix Version/s: (was: 2.9) 2.10 > Thin Client Continuous Query > > > Key: IGNITE-13148 > URL: https://issues.apache.org/jira/browse/IGNITE-13148 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > Original Estimate: 96h > Time Spent: 51h 20m > Remaining Estimate: 9h 10m > > Add Continuous Queries to thin client protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13107) ODBC: Memory leak in the tests
[ https://issues.apache.org/jira/browse/IGNITE-13107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13107: --- Fix Version/s: (was: 2.9) 2.10 > ODBC: Memory leak in the tests > -- > > Key: IGNITE-13107 > URL: https://issues.apache.org/jira/browse/IGNITE-13107 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > The memory leak, which is reproducible on TC Windows debug configuration, > have place in case of odce-test unit tests executing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13282) Fix TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized()
Vladimir Steshin created IGNITE-13282: - Summary: Fix TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized() Key: IGNITE-13282 URL: https://issues.apache.org/jira/browse/IGNITE-13282 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162233#comment-17162233 ] Pavel Tupitsyn commented on IGNITE-7369: [~GuruStron] please see my comments on GitHub > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, iep-34 > Fix For: 2.9 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13281) Test failed: GridIoManagerFileTransmissionSelfTest#testChunkHandlerInitSizeFail
[
https://issues.apache.org/jira/browse/IGNITE-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162212#comment-17162212
]
Stanilovsky Evgeny commented on IGNITE-13281:
-
[~mmuzaf] may be you have ideas ?
> Test failed:
> GridIoManagerFileTransmissionSelfTest#testChunkHandlerInitSizeFail
> ---
>
> Key: IGNITE-13281
> URL: https://issues.apache.org/jira/browse/IGNITE-13281
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Priority: Major
> Attachments: Ignite_Tests_2.4_Java_8_9_10_11_Basic_1_24053.log.zip
>
>
> I found this problem on TC (current master)
> {code:java}
> [14:33:27]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteException: Test exception. Initialization failed
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManagerFileTransmissionSelfTest$16.chunkHandler(GridIoManagerFileTransmissionSelfTest.java:777)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.createReceiver(GridIoManager.java:3062)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2949)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2892)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:243)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1234)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13281) Test failed: GridIoManagerFileTransmissionSelfTest#testChunkHandlerInitSizeFail
Stanilovsky Evgeny created IGNITE-13281:
---
Summary: Test failed:
GridIoManagerFileTransmissionSelfTest#testChunkHandlerInitSizeFail
Key: IGNITE-13281
URL: https://issues.apache.org/jira/browse/IGNITE-13281
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.8.1
Reporter: Stanilovsky Evgeny
Attachments: Ignite_Tests_2.4_Java_8_9_10_11_Basic_1_24053.log.zip
I found this problem on TC (current master)
{code:java}
[14:33:27]W: [org.apache.ignite:ignite-core] class
org.apache.ignite.IgniteException: Test exception. Initialization failed
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManagerFileTransmissionSelfTest$16.chunkHandler(GridIoManagerFileTransmissionSelfTest.java:777)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.createReceiver(GridIoManager.java:3062)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2949)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2892)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:243)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1234)
[14:33:27]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[14:33:27]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13281) Test failed: GridIoManagerFileTransmissionSelfTest#testChunkHandlerInitSizeFail
[
https://issues.apache.org/jira/browse/IGNITE-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-13281:
Description:
I found this problem on TC (current master)
{code:java}
[14:33:27]W: [org.apache.ignite:ignite-core] class
org.apache.ignite.IgniteException: Test exception. Initialization failed
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManagerFileTransmissionSelfTest$16.chunkHandler(GridIoManagerFileTransmissionSelfTest.java:777)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.createReceiver(GridIoManager.java:3062)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2949)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2892)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:243)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1234)
[14:33:27]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[14:33:27]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
{code}
https://ci.ignite.apache.org/viewLog.html?buildId=5481076
was:
I found this problem on TC (current master)
{code:java}
[14:33:27]W: [org.apache.ignite:ignite-core] class
org.apache.ignite.IgniteException: Test exception. Initialization failed
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManagerFileTransmissionSelfTest$16.chunkHandler(GridIoManagerFileTransmissionSelfTest.java:777)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.createReceiver(GridIoManager.java:3062)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2949)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2892)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:243)
[14:33:27]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1234)
[14:33:27]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[14:33:27]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
{code}
> Test failed:
> GridIoManagerFileTransmissionSelfTest#testChunkHandlerInitSizeFail
> ---
>
> Key: IGNITE-13281
> URL: https://issues.apache.org/jira/browse/IGNITE-13281
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Priority: Major
> Attachments: Ignite_Tests_2.4_Java_8_9_10_11_Basic_1_24053.log.zip
>
>
> I found this problem on TC (current master)
> {code:java}
> [14:33:27]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteException: Test exception. Initialization failed
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManagerFileTransmissionSelfTest$16.chunkHandler(GridIoManagerFileTransmissionSelfTest.java:777)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.createReceiver(GridIoManager.java:3062)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2949)
> [14:33:27]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2892)
> [14:33:27]W:
[jira] [Commented] (IGNITE-5848) Ignite should support Hibernate 5.2.X
[
https://issues.apache.org/jira/browse/IGNITE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162143#comment-17162143
]
Scott Feldstein commented on IGNITE-5848:
-
When IGNITE-9893 was implemented it was decided that we would bypass hibernate
5.2. So I don't think this is needed.
> Ignite should support Hibernate 5.2.X
> -
>
> Key: IGNITE-5848
> URL: https://issues.apache.org/jira/browse/IGNITE-5848
> Project: Ignite
> Issue Type: Sub-task
> Components: cache, hibernate
>Affects Versions: 2.0, 2.1
>Reporter: Nikolay Tikhonov
>Priority: Major
> Labels: community, java8
> Fix For: 2.10
>
>
> Currently Ignite supports Hibernate 5.1.X
> With Hibernate version of 5.2.X got the following exception:
> {code:java}
> Handler dispatch failed; nested exception is java.lang.AbstractMethodError:
> org.apache.ignite.cache.hibernate.HibernateEntityRegion$AccessStrategy.putFromLoad(Lorg/hibernate/engine/spi/SharedSessionContractImplementor;Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/Object;Z)Z
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13222) .NET: Consolidate tests - get rid of Tests.DotNetCore folder
[
https://issues.apache.org/jira/browse/IGNITE-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162107#comment-17162107
]
Ignite TC Bot commented on IGNITE-13222:
{panel:title=Branch: [pull/8064/head] Base: [master] : Possible Blockers
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5481811]]
* IgnitePdsWithIndexingCoreTestSuite: IgniteWalRecoveryTest.testRandomCrash -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5481816]]
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5481797]]
{color:#d04437}MVCC PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5481843]]
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testReActivateInReadOnlySimple_5_Servers_4_Clients_FromClient
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5481837]]
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5481776]]
* IgniteBasicTestSuite:
BPlusTreeReuseSelfTest.testSizeForRandomPutRmvMultithreadedAsync_16 - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Continuous Query 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5481807]]
* IgniteCacheQuerySelfTestSuite6:
ContinuousQueryMarshallerTest.testRemoteFilterFactoryServer - Test has low fail
rate in base branch 2,6% and is not flaky
{color:#d04437}Cache (Failover) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5481789]]
* IgniteCacheFailoverTestSuite2:
GridCachePartitionedFailoverSelfTest.testOptimisticRepeatableReadTxTopologyChange
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Web Sessions{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5481767]]
* IgniteWebSessionSelfTestSuite: WebSessionSelfTest.testRestarts - Test has low
fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8064/head] Base: [master] : New Tests
(1274)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Long Running){color} [[tests
42|https://ci.ignite.apache.org/viewLog.html?buildId=5481821]]
* {color:#013220}exe:
ClientReconnectCompatibilityTest.TestReconnectToOldNodeDisablesPartitionAwareness
- PASSED{color}
* {color:#013220}exe:
0,0).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140 -
PASSED{color}
* {color:#013220}exe:
0,0).TestCreateCacheWithFullConfigWorksOnAllVersions - PASSED{color}
* {color:#013220}exe:
0,0).TestComputeOperationsThrowCorrectExceptionWhenFeatureIsMissing -
PASSED{color}
* {color:#013220}exe:
0,0).TestClusterOperationsThrowCorrectExceptionOnVersionsOlderThan150 -
PASSED{color}
* {color:#013220}exe:
0,0).TestClusterGroupOperationsThrowCorrectExceptionWhenFeatureIsMissing
- PASSED{color}
* {color:#013220}exe: 0,0).TestCacheOperationsAreSupportedOnAllVersions -
PASSED{color}
* {color:#013220}exe:
6,2).TestClusterOperationsThrowCorrectExceptionOnVersionsOlderThan150 -
PASSED{color}
* {color:#013220}exe:
6,2).TestClusterGroupOperationsThrowCorrectExceptionWhenFeatureIsMissing
- PASSED{color}
* {color:#013220}exe: 6,2).TestCacheOperationsAreSupportedOnAllVersions -
PASSED{color}
* {color:#013220}exe:
0,1).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150 -
PASSED{color}
... and 31 new tests
{color:#8b}Platform .NET{color} [[tests
31|https://ci.ignite.apache.org/viewLog.html?buildId=5481817]]
* {color:#013220}exe: MarshallerTest.TestExplicitMarshaller - PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestCacheOperationsAreSupportedOnAllProtocols(1)
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestCacheOperationsAreSupportedOnAllProtocols(0)
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestClientOlderThanServerConnectsOnClientVersion(1)
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestClientOlderThanServerConnectsOnClientVersion(0)
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestClientNewerThanServerReconnectsOnServerVersion
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestCacheOperationsAreSupportedOnAllProtocols(6)
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestCacheOperationsAreSupportedOnAllProtocols(5)
- PASSED{color}
* {color:#013220}exe:
ClientProtocolCompatibilityTest.TestCacheOperationsAreSupportedOnAllProtocols(4)
- PASSED{color}
*
[jira] [Updated] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12996: - Release Note: A remote filter of IgniteEvents will run on a remote node inside the Ignite Sandbox if it is turned on. > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13261) Using transactions or scan queries inside the ignite sandbox can throw an AccessControlException
[ https://issues.apache.org/jira/browse/IGNITE-13261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162098#comment-17162098 ] Denis Garus commented on IGNITE-13261: -- [~alex_pl] thank you! > Using transactions or scan queries inside the ignite sandbox can throw an > AccessControlException > > > Key: IGNITE-13261 > URL: https://issues.apache.org/jira/browse/IGNITE-13261 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Any subject should be able to use transactions or scan queries inside the > ignite sandbox without additional permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162099#comment-17162099 ] Denis Garus commented on IGNITE-12996: -- [~alex_pl] thank you! > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162076#comment-17162076
]
Aleksey Plekhanov commented on IGNITE-13016:
Cherry-picked to 2.9
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What we might improve are:
> 1) Addresses checking could be done in parrallel, not sequentially.
> {code:java}
> for (InetSocketAddress addr : nodeAddrs) {
> // Connection refused may be got if node doesn't listen
> // (or blocked by firewall, but anyway assume it is dead).
> if (!isConnectionRefused(addr)) {
> liveAddr = addr;
> break;
> }
> }
> {code}
> 2) Any io-exception should be considered as failed connection, not only
> connection-refused:
> {code:java}
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> {code}
> 3) Timeout on connection checking should not be constant or hardcode:
> {code:java}
> sock.connect(addr, 100);
> {code}
> 4) Decision to check connection should rely on configured exchange timeout,
> no on the ping interval
> {code:java}
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + U.millisToNanos(connCheckInterval) * 2 >= now;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162070#comment-17162070 ] Stanilovsky Evgeny commented on IGNITE-13270: - ok, i try to reproduce it if you give me table and index creation queries for A B and C tables plz. > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13261) Using transactions or scan queries inside the ignite sandbox can throw an AccessControlException
[ https://issues.apache.org/jira/browse/IGNITE-13261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13261: --- Fix Version/s: 2.9 > Using transactions or scan queries inside the ignite sandbox can throw an > AccessControlException > > > Key: IGNITE-13261 > URL: https://issues.apache.org/jira/browse/IGNITE-13261 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Any subject should be able to use transactions or scan queries inside the > ignite sandbox without additional permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13268) Add indexes manipulation commands to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162037#comment-17162037 ] Sergey Chugunov commented on IGNITE-13268: -- [~vmalinovskiy], sure, will take a look. > Add indexes manipulation commands to control.sh > --- > > Key: IGNITE-13268 > URL: https://issues.apache.org/jira/browse/IGNITE-13268 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Vladimir Malinovskiy >Assignee: Vladimir Malinovskiy >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > These subcommands are to be added to the *--cache* command: > h2. --indexes_list > Gets list of indexes info. Although filters can be specified via command > arguments lines of output should still be grepable. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly it will be chosen by grid. > * *--group-name* is a regular expression corresponding to the group name. > * *--cache-name* is a regular expression corresponding to the name of the > cache. > * *--index-name* is a regular expression that matches the name of the index. > h2. --indexes-rebuild-status > Gets list of indexes that are currently being rebuilt. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly indexes rebuild info will be collected from all > nodes. > h2. --indexes_force_rebuild > Triggers force rebuild of indexes. This information should be reported in the > output: > * List of caches that weren’t found. > * List of caches that have index rebuild in progress. Indexes rebuild > shouldn’t be restarted for these caches. > * List of caches for which index rebuild was triggered. > Indexes rebuild should be performed asynchronously. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. > Mandatory parameter. > * *--group-names* is a comma-separated list of group names for which to > rebuild indexes. Either this option or --cache-names must be specified. > * *--cache-names* is a comma-separated list of cache names for which to > rebuild indexes. Either this option or --group-names must be specified. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13271) Add new type of WAL records to track/debug atomic updates on backup nodes
[ https://issues.apache.org/jira/browse/IGNITE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162020#comment-17162020 ] Vyacheslav Koptilin commented on IGNITE-13271: -- Hello [~ivan.glukos], Could you please take a look? > Add new type of WAL records to track/debug atomic updates on backup nodes > - > > Key: IGNITE-13271 > URL: https://issues.apache.org/jira/browse/IGNITE-13271 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, updates of the same key, for atomic caches, can arrive on backup > nodes in a different order and the most actual only is applied. > For instance: > Primary node: update1 -> update2 -> update3 > Backup node: update1-> update3 -> update2(which is skipped) > It seems it would be useful to track/log these updates for testing purposes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13279) Ignition.start failing with error java.lang.IllegalStateException: Failed to parse version: -1595322995-
[
https://issues.apache.org/jira/browse/IGNITE-13279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keshava Munegowda updated IGNITE-13279:
---
Priority: Critical (was: Major)
> Ignition.start failing with error java.lang.IllegalStateException: Failed to
> parse version: -1595322995-
>
>
> Key: IGNITE-13279
> URL: https://issues.apache.org/jira/browse/IGNITE-13279
> Project: Ignite
> Issue Type: Bug
> Components: examples, general
>Affects Versions: 2.8.1
>Reporter: Keshava Munegowda
>Priority: Critical
>
> I am using the Apache ignite : apache-ignite-2.8.1-bin
> I started the apache iginite node using : ./bin/ignite.sh
> ./examples/config/example-ignite.xml
> The node is successful started with this message:
> ```
> [root@mdw apache-ignite-2.8.1-bin]# ./bin/ignite.sh
> ./examples/config/example-ignite.xml
> [02:19:43] __
> [02:19:43] / _/ ___/ |/ / _/_ __/ __/
> [02:19:43] _/ // (7 7 // / / / / _/
> [02:19:43] /___/\___/_/|_/___/ /_/ /___/
> [02:19:43]
> [02:19:43] ver. 2.8.1#20200521-sha1:86422096
> [02:19:43] 2020 Copyright(C) Apache Software Foundation
> [02:19:43]
> [02:19:43] Ignite documentation: http://ignite.apache.org
> [02:19:43]
> [02:19:43] Quiet mode.
> [02:19:43] ^-- Logging to file
> '/data/kmg/apache-ignite-2.8.1-bin/work/log/ignite-4135cf96.0.log'
> [02:19:43] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
> [02:19:43] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.\{sh|bat}
> [02:19:43]
> [02:19:43] OS: Linux 3.10.0-1127.el7.x86_64 amd64
> [02:19:43] VM information: OpenJDK Runtime Environment 1.8.0_252-b09 Oracle
> Corporation OpenJDK 64-Bit Server VM 25.252-b09
> [02:19:43] Please set system property '-Djava.net.preferIPv4Stack=true' to
> avoid possible problems in mixed environments.
> [02:19:43] Configured plugins:
> [02:19:43] ^-- None
> [02:19:43]
> [02:19:43] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
> [tryStop=false, timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT
> [02:19:46] Message queue limit is set to 0 which may lead to potential OOMEs
> when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
> message queues growth on sender and receiver sides.
> [02:19:46] Security status [authentication=off, tls/ssl=off]
> [02:19:48] Performance suggestions for grid (fix if possible)
> [02:19:48] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [02:19:48] ^-- Disable grid events (remove 'includeEventTypes' from
> configuration)
> [02:19:48] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
> [02:19:48] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
> JVM options)
> [02:19:48] ^-- Set max direct memory size if getting 'OOME: Direct buffer
> memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
> [02:19:48] ^-- Disable processing of calls to System.gc() (add
> '-XX:+DisableExplicitGC' to JVM options)
> [02:19:48] ^-- Speed up flushing of dirty pages by OS (alter
> vm.dirty_expire_centisecs parameter by setting to 500)
> [02:19:48] Refer to this page for more performance suggestions:
> https://apacheignite.readme.io/docs/jvm-and-system-tuning
> [02:19:48]
> [02:19:48] To start Console Management & Monitoring run
> ignitevisorcmd.\{sh|bat}
> [02:19:48] Data Regions Configured:
> [02:19:48] ^-- default [initSize=256.0 MiB, maxSize=75.5 GiB,
> persistence=false, lazyMemoryAllocation=true]
> [02:19:48]
> [02:19:48] Ignite node started OK (id=4135cf96)
> [02:19:48] Topology snapshot [ver=1, locNode=4135cf96, servers=1, clients=0,
> state=ACTIVE, CPUs=32, offheap=76.0GB, heap=27.0GB]
> [02:19:48] ^-- Baseline [id=0, size=1, online=1, offline=0]
> ```
> Now, I have benchmarking application, which start the apache iginitition
> using the java API
> Ignition.start("examples/config/example-ignite.xml");
> This method is failing with below error log:
> ```
> 0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemProperties' with lowest search precedence
> 2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemEnvironment' with lowest search precedence
> 3 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
> StandardEnvironment with PropertySources [MapPropertySource@1928301845
> {name='systemProperties', properties={java.runtime.name=OpenJDK Runtime
> Environment,
> sun.boot.library.path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-2.el7_8.x86_64/jre/lib/amd64,
> java.vm.version=25.252-b09, java.vm.vendor=Oracle Corporation,
>
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162018#comment-17162018 ] Tanmay Ambre commented on IGNITE-13270: --- No our caches are transient. We don't use persistence To give you a background of the tests - # we do a complete data wipe of data in ignite (as if its a new install) # activate the cluster # Recreate our caches and indexes # Load data # and then test We followed the same process for testing all 3 versions of ignite. Problem is the same query with same plan works nicely on 2.7.5 but not on 2.8.0 and 2.8.1 - This is the concern. The CPU burn is order of magnitude higher in 2.8.0 and 2.8.1 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13271) Add new type of WAL records to track/debug atomic updates on backup nodes
[
https://issues.apache.org/jira/browse/IGNITE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162017#comment-17162017
]
Ignite TC Bot commented on IGNITE-13271:
{panel:title=Branch: [pull/8060/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8060/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5476089]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=0e87c8c6371-d700b7ab-0f16-4eeb-990c-20c47f96ea3f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=ac5699a3-5f95-430d-bf47-4e99c8ccfb63, topVer=0, msgTemplate=null,
span=null, nodeId8=ac5699a3, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595254012124]], val2=AffinityTopologyVersion
[topVer=6283406109545921379, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=0e87c8c6371-d700b7ab-0f16-4eeb-990c-20c47f96ea3f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=ac5699a3-5f95-430d-bf47-4e99c8ccfb63, topVer=0, msgTemplate=null,
span=null, nodeId8=ac5699a3, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595254012124]], val2=AffinityTopologyVersion
[topVer=6283406109545921379, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=34ad1a01-2fa4-4a73-8982-639970c08a05, topVer=0,
msgTemplate=null, span=null, nodeId8=b67542e3, msg=, type=NODE_JOINED,
tstamp=1595254012124], val2=AffinityTopologyVersion
[topVer=1033303141680072443, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=34ad1a01-2fa4-4a73-8982-639970c08a05, topVer=0,
msgTemplate=null, span=null, nodeId8=b67542e3, msg=, type=NODE_JOINED,
tstamp=1595254012124], val2=AffinityTopologyVersion
[topVer=1033303141680072443, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5476088]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=d1b880b4-2903-4fe8-bd8a-b097ae054561, topVer=0,
msgTemplate=null, span=null, nodeId8=8dc88a81, msg=, type=NODE_JOINED,
tstamp=1595253956807], val2=AffinityTopologyVersion
[topVer=3258640746282525568, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=d1b880b4-2903-4fe8-bd8a-b097ae054561, topVer=0,
msgTemplate=null, span=null, nodeId8=8dc88a81, msg=, type=NODE_JOINED,
tstamp=1595253956807], val2=AffinityTopologyVersion
[topVer=3258640746282525568, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=bc0ab8c6371-e815ee84-834c-45d1-a092-51819bb624c3, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=886e9b10-da14-4ffb-aec8-1d8e21dc7638, topVer=0, msgTemplate=null,
span=null, nodeId8=886e9b10, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595253956807]], val2=AffinityTopologyVersion
[topVer=-2331752221821955656, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=bc0ab8c6371-e815ee84-834c-45d1-a092-51819bb624c3, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=886e9b10-da14-4ffb-aec8-1d8e21dc7638, topVer=0, msgTemplate=null,
span=null, nodeId8=886e9b10, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595253956807]], val2=AffinityTopologyVersion
[topVer=-2331752221821955656, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5476111buildTypeId=IgniteTests24Java8_RunAll]
> Add new type of WAL records to track/debug atomic updates on backup nodes
> -
>
> Key: IGNITE-13271
> URL:
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162019#comment-17162019 ] Tanmay Ambre commented on IGNITE-13270: --- h2 version is 1.4.197 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161990#comment-17161990 ] Sergey Stronchinskiy commented on IGNITE-7369: -- [~ptupitsyn] Submitted for review. > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, iep-34 > Fix For: 2.9 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions
[
https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161988#comment-17161988
]
Ignite TC Bot commented on IGNITE-7369:
---
{panel:title=Branch: [pull/7992/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7992/head] Base: [master] : New Tests
(81)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET{color} [[tests
42|https://ci.ignite.apache.org/viewLog.html?buildId=5477938]]
* {color:#013220}exe: CacheClientAbstractTxTest.TestTxClose - PASSED{color}
* {color:#013220}exe:
CacheClientAbstractTxTest.TestTransactionScopeWithManualIgniteTx - PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestTransactionScopeSingleCache
- PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestTransactionScopeOptions -
PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestTransactionScopeMultiCache
- PASSED{color}
* {color:#013220}exe:
CacheClientAbstractTxTest.TestTransactionScopeAllOperationsSync - PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestThrowsIfMultipleStarted -
PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestThrowsIfMultipleStarted -
PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestSuppressedTransactionScope
- PASSED{color}
* {color:#013220}exe: CacheClientAbstractTxTest.TestNestedTransactionScope -
PASSED{color}
* {color:#013220}exe:
CacheClientAbstractTxTest.TestDifferentClientsCanStartTransactions -
PASSED{color}
... and 31 new tests
{color:#8b}Platform .NET (Core Linux){color} [[tests
39|https://ci.ignite.apache.org/viewLog.html?buildId=5477940]]
* {color:#013220}dll: CachePartitionedTxTest.TestTimeout - PASSED{color}
* {color:#013220}dll: CachePartitionedTxTest.TestThrowsIfMultipleStarted -
PASSED{color}
* {color:#013220}dll:
CachePartitionedTxTest.TestThrowsIfEndAlreadyCompletedTransaction -
PASSED{color}
* {color:#013220}dll: CachePartitionedTxTest.TestSuppressedTransactionScope -
PASSED{color}
* {color:#013220}dll: CachePartitionedTxTest.TestNestedTransactionScope -
PASSED{color}
* {color:#013220}dll:
CachePartitionedTxTest.TestDifferentClientsCanStartTransactions - PASSED{color}
* {color:#013220}dll: CachePartitionedTxTest.TestClientTransactionConfiguration
- PASSED{color}
* {color:#013220}dll: CacheClientLocalTxTest.TestWithLabel - PASSED{color}
* {color:#013220}dll: CachePartitionedTxTest.TestTxClose - PASSED{color}
* {color:#013220}dll:
CachePartitionedTxTest.TestTransactionScopeWithManualIgniteTx - PASSED{color}
* {color:#013220}dll: CachePartitionedTxTest.TestTransactionScopeSingleCache -
PASSED{color}
... and 28 new tests
{panel}
[TeamCity *- Run :: .NET*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5477943buildTypeId=IgniteTests24Java8_RunAllNet]
> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
> Labels: .NET, iep-34
> Fix For: 2.9
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
Stanilovsky Evgeny created IGNITE-13280:
---
Summary: Improper index usage, fields enumeration not used with pk
index creation.
Key: IGNITE-13280
URL: https://issues.apache.org/jira/browse/IGNITE-13280
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.8.1
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
For example:
{code:java}
CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR, ADDRESS
VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
LAST_NAME));
CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
{code}
and further explain:
{code:java}
SELECT
"__Z0"."FIRST_NAME" AS "__C0_0",
"__Z0"."LAST_NAME" AS "__C0_1",
"__Z0"."ADDRESS" AS "__C0_2",
"__Z0"."LANG" AS "__C0_3"
FROM "PUBLIC"."TEST_TABLE" "__Z0"
/* PUBLIC.IDX2: ADDRESS > 0 */
WHERE "__Z0"."ADDRESS" > 0
{code}
this is erroneous to use "idx2" here, because first index field LANG not
equals to predicate ADDRESS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Ignite Flags: (was: Release Notes Required)
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What we might improve are:
> 1) Addresses checking could be done in parrallel, not sequentially.
> {code:java}
> for (InetSocketAddress addr : nodeAddrs) {
> // Connection refused may be got if node doesn't listen
> // (or blocked by firewall, but anyway assume it is dead).
> if (!isConnectionRefused(addr)) {
> liveAddr = addr;
> break;
> }
> }
> {code}
> 2) Any io-exception should be considered as failed connection, not only
> connection-refused:
> {code:java}
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> {code}
> 3) Timeout on connection checking should not be constant or hardcode:
> {code:java}
> sock.connect(addr, 100);
> {code}
> 4) Decision to check connection should rely on configured exchange timeout,
> no on the ping interval
> {code:java}
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + U.millisToNanos(connCheckInterval) * 2 >= now;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161933#comment-17161933
]
Sergey Chugunov commented on IGNITE-13016:
--
[~vladsz83],
The patch looks good to me, I merged it to master branch in commit
*03ee85695014ff6aaa87e256d330d32342d34224*.
Thank you for contribution!
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What we might improve are:
> 1) Addresses checking could be done in parrallel, not sequentially.
> {code:java}
> for (InetSocketAddress addr : nodeAddrs) {
> // Connection refused may be got if node doesn't listen
> // (or blocked by firewall, but anyway assume it is dead).
> if (!isConnectionRefused(addr)) {
> liveAddr = addr;
> break;
> }
> }
> {code}
> 2) Any io-exception should be considered as failed connection, not only
> connection-refused:
> {code:java}
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> {code}
> 3) Timeout on connection checking should not be constant or hardcode:
> {code:java}
> sock.connect(addr, 100);
> {code}
> 4) Decision to check connection should rely on configured exchange timeout,
> no on the ping interval
> {code:java}
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + U.millisToNanos(connCheckInterval) * 2 >= now;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161933#comment-17161933
]
Sergey Chugunov edited comment on IGNITE-13016 at 7/21/20, 10:35 AM:
-
[~vladsz83],
The patch looks good to me, I merged it to master branch in commit
*03ee85695014ff6aaa87e256d330d32342d34224*. Please fill in release notes for
the ticket.
Thank you for contribution!
was (Author: sergeychugunov):
[~vladsz83],
The patch looks good to me, I merged it to master branch in commit
*03ee85695014ff6aaa87e256d330d32342d34224*.
Thank you for contribution!
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Backward node connection checking looks wierd. What we might improve are:
> 1) Addresses checking could be done in parrallel, not sequentially.
> {code:java}
> for (InetSocketAddress addr : nodeAddrs) {
> // Connection refused may be got if node doesn't listen
> // (or blocked by firewall, but anyway assume it is dead).
> if (!isConnectionRefused(addr)) {
> liveAddr = addr;
> break;
> }
> }
> {code}
> 2) Any io-exception should be considered as failed connection, not only
> connection-refused:
> {code:java}
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> {code}
> 3) Timeout on connection checking should not be constant or hardcode:
> {code:java}
> sock.connect(addr, 100);
> {code}
> 4) Decision to check connection should rely on configured exchange timeout,
> no on the ping interval
> {code:java}
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + U.millisToNanos(connCheckInterval) * 2 >= now;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161928#comment-17161928 ] Denis Garus commented on IGNITE-12996: -- [~alex_pl], could you please review the changes. There is one blocker in TC visa that also present on the master branch. Unfortunately, it blocks getting a green visa. > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 10m > Remaining Estimate: 0h > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[
https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161924#comment-17161924
]
Ignite TC Bot commented on IGNITE-12996:
{panel:title=Branch: [pull/8058/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5480797]]
{panel}
{panel:title=Branch: [pull/8058/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5475968]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=68d41105-a043-4d0f-a77c-108878624641, topVer=0,
msgTemplate=null, span=null, nodeId8=1248fea0, msg=, type=NODE_JOINED,
tstamp=1595251915586], val2=AffinityTopologyVersion
[topVer=-5433749287640349845, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=64b7c6c6371-a1f05a7c-6bc7-4094-a9c1-d88629957897, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a4873f81-a45e-4593-98b9-f2acbfcbc5e4, topVer=0, msgTemplate=null,
span=null, nodeId8=a4873f81, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595251915586]], val2=AffinityTopologyVersion
[topVer=7462137751004898471, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=64b7c6c6371-a1f05a7c-6bc7-4094-a9c1-d88629957897, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a4873f81-a45e-4593-98b9-f2acbfcbc5e4, topVer=0, msgTemplate=null,
span=null, nodeId8=a4873f81, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595251915586]], val2=AffinityTopologyVersion
[topVer=7462137751004898471, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=68d41105-a043-4d0f-a77c-108878624641, topVer=0,
msgTemplate=null, span=null, nodeId8=1248fea0, msg=, type=NODE_JOINED,
tstamp=1595251915586], val2=AffinityTopologyVersion
[topVer=-5433749287640349845, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5475967]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=28c9d64f-92a3-4e11-8f7c-dc630dd9352f, topVer=0,
msgTemplate=null, span=null, nodeId8=07e642ac, msg=, type=NODE_JOINED,
tstamp=1595251789472], val2=AffinityTopologyVersion
[topVer=7217010853577529856, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=28c9d64f-92a3-4e11-8f7c-dc630dd9352f, topVer=0,
msgTemplate=null, span=null, nodeId8=07e642ac, msg=, type=NODE_JOINED,
tstamp=1595251789472], val2=AffinityTopologyVersion
[topVer=7217010853577529856, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=4ae8a6c6371-61a125ed-d1c5-4d83-8daf-6c2dc1262756, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=bc66a8b9-f585-450b-8a62-35b39e4da832, topVer=0, msgTemplate=null,
span=null, nodeId8=bc66a8b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595251789472]], val2=AffinityTopologyVersion
[topVer=4583702723832650516, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=4ae8a6c6371-61a125ed-d1c5-4d83-8daf-6c2dc1262756, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=bc66a8b9-f585-450b-8a62-35b39e4da832, topVer=0, msgTemplate=null,
span=null, nodeId8=bc66a8b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595251789472]], val2=AffinityTopologyVersion
[topVer=4583702723832650516, minorTopVer=0]]] - PASSED{color}
{color:#8b}Security{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5475983]]
* {color:#013220}SecurityTestSuite: EventsSandboxTest.testRemoteFilter -
PASSED{color}
* {color:#013220}SecurityTestSuite:
[jira] [Created] (IGNITE-13279) Ignition.start failing with error java.lang.IllegalStateException: Failed to parse version: -1595322995-
Keshava Munegowda created IGNITE-13279:
--
Summary: Ignition.start failing with error
java.lang.IllegalStateException: Failed to parse version: -1595322995-
Key: IGNITE-13279
URL: https://issues.apache.org/jira/browse/IGNITE-13279
Project: Ignite
Issue Type: Bug
Components: examples, general
Affects Versions: 2.8.1
Reporter: Keshava Munegowda
I am using the Apache ignite : apache-ignite-2.8.1-bin
I started the apache iginite node using : ./bin/ignite.sh
./examples/config/example-ignite.xml
The node is successful started with this message:
```
[root@mdw apache-ignite-2.8.1-bin]# ./bin/ignite.sh
./examples/config/example-ignite.xml
[02:19:43] __
[02:19:43] / _/ ___/ |/ / _/_ __/ __/
[02:19:43] _/ // (7 7 // / / / / _/
[02:19:43] /___/\___/_/|_/___/ /_/ /___/
[02:19:43]
[02:19:43] ver. 2.8.1#20200521-sha1:86422096
[02:19:43] 2020 Copyright(C) Apache Software Foundation
[02:19:43]
[02:19:43] Ignite documentation: http://ignite.apache.org
[02:19:43]
[02:19:43] Quiet mode.
[02:19:43] ^-- Logging to file
'/data/kmg/apache-ignite-2.8.1-bin/work/log/ignite-4135cf96.0.log'
[02:19:43] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
[02:19:43] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
"-v" to ignite.\{sh|bat}
[02:19:43]
[02:19:43] OS: Linux 3.10.0-1127.el7.x86_64 amd64
[02:19:43] VM information: OpenJDK Runtime Environment 1.8.0_252-b09 Oracle
Corporation OpenJDK 64-Bit Server VM 25.252-b09
[02:19:43] Please set system property '-Djava.net.preferIPv4Stack=true' to
avoid possible problems in mixed environments.
[02:19:43] Configured plugins:
[02:19:43] ^-- None
[02:19:43]
[02:19:43] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
[tryStop=false, timeout=0, super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT
[02:19:46] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[02:19:46] Security status [authentication=off, tls/ssl=off]
[02:19:48] Performance suggestions for grid (fix if possible)
[02:19:48] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[02:19:48] ^-- Disable grid events (remove 'includeEventTypes' from
configuration)
[02:19:48] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
[02:19:48] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to JVM
options)
[02:19:48] ^-- Set max direct memory size if getting 'OOME: Direct buffer
memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[02:19:48] ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[02:19:48] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
[02:19:48] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[02:19:48]
[02:19:48] To start Console Management & Monitoring run ignitevisorcmd.\{sh|bat}
[02:19:48] Data Regions Configured:
[02:19:48] ^-- default [initSize=256.0 MiB, maxSize=75.5 GiB,
persistence=false, lazyMemoryAllocation=true]
[02:19:48]
[02:19:48] Ignite node started OK (id=4135cf96)
[02:19:48] Topology snapshot [ver=1, locNode=4135cf96, servers=1, clients=0,
state=ACTIVE, CPUs=32, offheap=76.0GB, heap=27.0GB]
[02:19:48] ^-- Baseline [id=0, size=1, online=1, offline=0]
```
Now, I have benchmarking application, which start the apache iginitition using
the java API
Ignition.start("examples/config/example-ignite.xml");
This method is failing with below error log:
```
0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
PropertySource 'systemProperties' with lowest search precedence
2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
PropertySource 'systemEnvironment' with lowest search precedence
3 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
StandardEnvironment with PropertySources [MapPropertySource@1928301845
{name='systemProperties', properties={java.runtime.name=OpenJDK Runtime
Environment,
sun.boot.library.path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-2.el7_8.x86_64/jre/lib/amd64,
java.vm.version=25.252-b09, java.vm.vendor=Oracle Corporation,
java.vendor.url=http://java.oracle.com/, path.separator=:, java.vm.name=OpenJDK
64-Bit Server VM, file.encoding.pkg=sun.io, user.country=US,
sun.java.launcher=SUN_STANDARD, sun.os.patch.level=unknown,
java.vm.specification.name=Java Virtual Machine Specification,
user.dir=/data/kmg/SBK, java.runtime.version=1.8.0_252-b09,
java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment,
[jira] [Created] (IGNITE-13278) Forgotten logger isInfoEnabled check.
Stanilovsky Evgeny created IGNITE-13278:
---
Summary: Forgotten logger isInfoEnabled check.
Key: IGNITE-13278
URL: https://issues.apache.org/jira/browse/IGNITE-13278
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 2.8.1
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
In RO tests with enabled -ea we can obtain near assertion:
{code:java}
java.lang.AssertionError: Logging at INFO level without checking if INFO level
is enabled: Cluster state was changed from ACTIVE to ACTIVE
at
org.apache.ignite.testframework.junits.logger.GridTestLog4jLogger.info(GridTestLog4jLogger.java:481)
~[ignite-core-tests.jar]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[
https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161897#comment-17161897
]
Aleksey Plekhanov commented on IGNITE-12398:
[~ravimsc], can you please provide more information about your case? Where do
you start visor, inside S3 or outside? Do you set some additional properties in
visor configuration ({{IgniteConfiguration.LocalHost}} for example)?
I've checked {{getAddress()}} method with address patterns you provided, and
this method return not null for such values.
I found some problems with daemon nodes (visor uses deamon node to join
cluster), they joined to ring (like server nodes) instead of joining like a
client. When joined to ring IpFinder.registerAddresses is invoked and if some
of addresses passed by visor is unresolvable, exception like yours can be
thrown (I can't imagine how it can happen since Ignite uses IP address if host
is unresolvable). But you can workaround it, just set ClientMode = true in
visor configuration and visor will not join the ring and will connect to
cluster like a client.
I think this ticket is not a blocker (workaround exists, we can't reproduce
it). I've set priority to "critical" and have targeted the ticket to the next
release.
> Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we
> connect Ignite Visor Command Line Interface
> -
>
> Key: IGNITE-12398
> URL: https://issues.apache.org/jira/browse/IGNITE-12398
> Project: Ignite
> Issue Type: Bug
> Components: aws, general, s3, visor
>Affects Versions: 2.7
> Environment: Production
>Reporter: Ravi Kumar Powli
>Assignee: Emmanouil Gkatziouras
>Priority: Critical
> Fix For: 2.10
>
>
> We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
> we connect any one cluster node using Ignite Visor Command Line Interface it
> got hang and automatically cluster nodes(all the three nodes) are going down.
> Please find the below exception stacktrace.
> {noformat}
> [SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at
[jira] [Updated] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[
https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12398:
---
Priority: Critical (was: Blocker)
> Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we
> connect Ignite Visor Command Line Interface
> -
>
> Key: IGNITE-12398
> URL: https://issues.apache.org/jira/browse/IGNITE-12398
> Project: Ignite
> Issue Type: Bug
> Components: aws, general, s3, visor
>Affects Versions: 2.7
> Environment: Production
>Reporter: Ravi Kumar Powli
>Assignee: Emmanouil Gkatziouras
>Priority: Critical
> Fix For: 2.9
>
>
> We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
> we connect any one cluster node using Ignite Visor Command Line Interface it
> got hang and automatically cluster nodes(all the three nodes) are going down.
> Please find the below exception stacktrace.
> {noformat}
> [SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:59] Ignite node stopped OK [name=DataStoreIgniteCache,
> uptime=00:01:13.934]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[
https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12398:
---
Fix Version/s: (was: 2.9)
2.10
> Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we
> connect Ignite Visor Command Line Interface
> -
>
> Key: IGNITE-12398
> URL: https://issues.apache.org/jira/browse/IGNITE-12398
> Project: Ignite
> Issue Type: Bug
> Components: aws, general, s3, visor
>Affects Versions: 2.7
> Environment: Production
>Reporter: Ravi Kumar Powli
>Assignee: Emmanouil Gkatziouras
>Priority: Critical
> Fix For: 2.10
>
>
> We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
> we connect any one cluster node using Ignite Visor Command Line Interface it
> got hang and automatically cluster nodes(all the three nodes) are going down.
> Please find the below exception stacktrace.
> {noformat}
> [SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:59] Ignite node stopped OK [name=DataStoreIgniteCache,
> uptime=00:01:13.934]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161895#comment-17161895 ] Stanilovsky Evgeny commented on IGNITE-13270: - ok, without deep investigation i can suggest only : 1. check that your sql plans are correct now : explain select ... <- you need to find correct index usage here 2. if p 1. is incorrect or cpu burn still in progress try to rebuild current indexes, stop node by node, remove or move index.bin file from all or suspicious caches and start node - index will rebuild automatically. And one point - we are talking about cluster with persistent caches isn`t it ? > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13268) Add indexes manipulation commands to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Malinovskiy updated IGNITE-13268: -- Fix Version/s: 2.10 > Add indexes manipulation commands to control.sh > --- > > Key: IGNITE-13268 > URL: https://issues.apache.org/jira/browse/IGNITE-13268 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Vladimir Malinovskiy >Assignee: Vladimir Malinovskiy >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > These subcommands are to be added to the *--cache* command: > h2. --indexes_list > Gets list of indexes info. Although filters can be specified via command > arguments lines of output should still be grepable. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly it will be chosen by grid. > * *--group-name* is a regular expression corresponding to the group name. > * *--cache-name* is a regular expression corresponding to the name of the > cache. > * *--index-name* is a regular expression that matches the name of the index. > h2. --indexes-rebuild-status > Gets list of indexes that are currently being rebuilt. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly indexes rebuild info will be collected from all > nodes. > h2. --indexes_force_rebuild > Triggers force rebuild of indexes. This information should be reported in the > output: > * List of caches that weren’t found. > * List of caches that have index rebuild in progress. Indexes rebuild > shouldn’t be restarted for these caches. > * List of caches for which index rebuild was triggered. > Indexes rebuild should be performed asynchronously. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. > Mandatory parameter. > * *--group-names* is a comma-separated list of group names for which to > rebuild indexes. Either this option or --cache-names must be specified. > * *--cache-names* is a comma-separated list of cache names for which to > rebuild indexes. Either this option or --group-names must be specified. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13268) Add indexes manipulation commands to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161839#comment-17161839
]
Ignite TC Bot commented on IGNITE-13268:
{panel:title=Branch: [pull/8054/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5478780]]
{panel}
{panel:title=Branch: [pull/8054/head] Base: [master] : New Tests
(30)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5475665]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0544c933-2798-4a18-a361-455cc362a6ce, topVer=0,
msgTemplate=null, span=null, nodeId8=9285b0a4, msg=, type=NODE_JOINED,
tstamp=1595236191043], val2=AffinityTopologyVersion
[topVer=2082538619630230610, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=924d68b6371-89738cef-13a0-465b-9939-f7391d1c2551, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=b88f658f-a2e1-4cb1-a294-6e635be87fc7, topVer=0, msgTemplate=null,
span=null, nodeId8=b88f658f, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595236191043]], val2=AffinityTopologyVersion
[topVer=-8387876848463035692, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=924d68b6371-89738cef-13a0-465b-9939-f7391d1c2551, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=b88f658f-a2e1-4cb1-a294-6e635be87fc7, topVer=0, msgTemplate=null,
span=null, nodeId8=b88f658f, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595236191043]], val2=AffinityTopologyVersion
[topVer=-8387876848463035692, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0544c933-2798-4a18-a361-455cc362a6ce, topVer=0,
msgTemplate=null, span=null, nodeId8=9285b0a4, msg=, type=NODE_JOINED,
tstamp=1595236191043], val2=AffinityTopologyVersion
[topVer=2082538619630230610, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5475664]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=384a1f88-4f9a-4970-b1b4-dd73aa2bceab, topVer=0,
msgTemplate=null, span=null, nodeId8=265bf6fc, msg=, type=NODE_JOINED,
tstamp=1595236109924], val2=AffinityTopologyVersion
[topVer=-8910998317732334030, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=384a1f88-4f9a-4970-b1b4-dd73aa2bceab, topVer=0,
msgTemplate=null, span=null, nodeId8=265bf6fc, msg=, type=NODE_JOINED,
tstamp=1595236109924], val2=AffinityTopologyVersion
[topVer=-8910998317732334030, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=86e4b7b6371-39295c77-2897-42d2-a8f2-1b8bf5d72136, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a6624906-a436-475e-aa01-3599a93b22ad, topVer=0, msgTemplate=null,
span=null, nodeId8=a6624906, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595236109924]], val2=AffinityTopologyVersion
[topVer=7906347396054888457, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=86e4b7b6371-39295c77-2897-42d2-a8f2-1b8bf5d72136, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a6624906-a436-475e-aa01-3599a93b22ad, topVer=0, msgTemplate=null,
span=null, nodeId8=a6624906, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595236109924]], val2=AffinityTopologyVersion
[topVer=7906347396054888457, minorTopVer=0]]] - PASSED{color}
{color:#8b}Control Utility{color} [[tests
22|https://ci.ignite.apache.org/viewLog.html?buildId=5475685]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexForceRebuildTest.testIndexRebuildUnderLoad
[jira] [Comment Edited] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161780#comment-17161780 ] Tanmay Ambre edited comment on IGNITE-13270 at 7/21/20, 7:07 AM: - Have taken multiple snapshots [for the same thread] 1 -- org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read line: 5896 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1365 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind line: 1332 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne line: 1300 org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find line: 360 org.h2.index.BaseIndex.find line: 130 org.h2.index.IndexCursor.find line: 176 org.h2.table.TableFilter.next line: 471 org.h2.table.TableFilter.next line: 541 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line: 2138 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$17 line: 2095 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$$Lambda$482/222427158.onMessage line: not available org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage line: 3379 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener line: 1843 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0 line: 1468 org.apache.ignite.internal.managers.communication.GridIoManager.access$5200 line: 229 org.apache.ignite.internal.managers.communication.GridIoManager$9.run line: 1365 java.util.concurrent.ThreadPoolExecutor.runWorker line: 1149 java.util.concurrent.ThreadPoolExecutor$Worker.run line: 624 java.lang.Thread.run line: 748 was (Author: tambre): Have taken multiple snapshots 1 -- org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read line: 5896 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1365 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind line: 1332 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne line: 1300 org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find line: 360 org.h2.index.BaseIndex.find line: 130 org.h2.index.IndexCursor.find line: 176 org.h2.table.TableFilter.next line: 471 org.h2.table.TableFilter.next line: 541 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line:
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161784#comment-17161784 ] Tanmay Ambre commented on IGNITE-13270: --- Trace 5: org.h2.value.Value.cache line: 410 org.h2.value.ValueString.get line: 153 org.h2.value.ValueString.get line: 134 org.apache.ignite.internal.processors.query.h2.H2Utils.wrap line: 582 org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.wrap line: 169 org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.getValue0 line: 104 org.apache.ignite.internal.processors.query.h2.opt.H2CacheRow.getValue line: 86 org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare line: 392 org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare line: 63 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare line: 5200 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.findLowerBound line: 5317 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer0 line: 5588 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.fillFromBuffer line: 5376 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage line: 5428 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next line: 5661 org.apache.ignite.internal.processors.query.h2.H2Cursor.next line: 66 org.h2.index.IndexCursor.next line: 316 org.h2.table.TableFilter.next line: 502 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line: 2138 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$17 line: 2095 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$$Lambda$482/222427158.onMessage line: not available org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage line: 3379 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener line: 1843 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0 line: 1468 org.apache.ignite.internal.managers.communication.GridIoManager.access$5200 line: 229 org.apache.ignite.internal.managers.communication.GridIoManager$9.run line: 1365 java.util.concurrent.ThreadPoolExecutor.runWorker line: 1149 java.util.concurrent.ThreadPoolExecutor$Worker.run line: 624 java.lang.Thread.run line: 748 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx.
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161783#comment-17161783 ] Tanmay Ambre commented on IGNITE-13270: --- Trace 4: org.apache.ignite.internal.processors.cache.persistence.DataStructure.read line: 341 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read line: 5876 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.askNeighbor line: 2569 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$1300 line: 94 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0 line: 342 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run line: 5709 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run line: 278 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run line: 5695 org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage line: 169 org.apache.ignite.internal.processors.cache.persistence.DataStructure.read line: 364 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read line: 5896 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1365 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind line: 1332 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne line: 1300 org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find line: 360 org.h2.index.BaseIndex.find line: 130 org.h2.index.IndexCursor.find line: 176 org.h2.table.TableFilter.next line: 471 org.h2.table.TableFilter.next line: 541 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line: 2138 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$17 line: 2095 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$$Lambda$482/222427158.onMessage line: not available org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage line: 3379 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener line: 1843 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0 line: 1468 org.apache.ignite.internal.managers.communication.GridIoManager.access$5200 line: 229 org.apache.ignite.internal.managers.communication.GridIoManager$9.run line: 1365 java.util.concurrent.ThreadPoolExecutor.runWorker line: 1149 java.util.concurrent.ThreadPoolExecutor$Worker.run line: 624 java.lang.Thread.run line: 748 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161781#comment-17161781 ] Tanmay Ambre commented on IGNITE-13270: --- Trace 2: org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.acquirePage line: 481 org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage line: 158 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage line: 5858 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage line: 5417 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next line: 5661 org.apache.ignite.internal.processors.query.h2.H2Cursor.next line: 66 org.h2.index.IndexCursor.next line: 316 org.h2.table.TableFilter.next line: 502 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line: 2138 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$17 line: 2095 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$$Lambda$482/222427158.onMessage line: not available org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage line: 3379 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener line: 1843 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0 line: 1468 org.apache.ignite.internal.managers.communication.GridIoManager.access$5200 line: 229 org.apache.ignite.internal.managers.communication.GridIoManager$9.run line: 1365 java.util.concurrent.ThreadPoolExecutor.runWorker line: 1149 java.util.concurrent.ThreadPoolExecutor$Worker.run line: 624 java.lang.Thread.run line: 748 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161782#comment-17161782 ] Tanmay Ambre commented on IGNITE-13270: --- Trace 3: org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage line: 165 org.apache.ignite.internal.processors.cache.persistence.DataStructure.read line: 364 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read line: 5896 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1365 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind line: 1332 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne line: 1300 org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find line: 360 org.h2.index.BaseIndex.find line: 130 org.h2.index.IndexCursor.find line: 176 org.h2.table.TableFilter.next line: 471 org.h2.table.TableFilter.next line: 541 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line: 2138 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$17 line: 2095 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$$Lambda$482/222427158.onMessage line: not available org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage line: 3379 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener line: 1843 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0 line: 1468 org.apache.ignite.internal.managers.communication.GridIoManager.access$5200 line: 229 org.apache.ignite.internal.managers.communication.GridIoManager$9.run line: 1365 java.util.concurrent.ThreadPoolExecutor.runWorker line: 1149 java.util.concurrent.ThreadPoolExecutor$Worker.run line: 624 java.lang.Thread.run line: 748 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161780#comment-17161780 ] Tanmay Ambre commented on IGNITE-13270: --- Have taken multiple snapshots 1 -- org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read line: 5896 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1365 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown line: 1374 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind line: 1332 org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne line: 1300 org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find line: 360 org.h2.index.BaseIndex.find line: 130 org.h2.index.IndexCursor.find line: 176 org.h2.table.TableFilter.next line: 471 org.h2.table.TableFilter.next line: 541 org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow line: 1452 org.h2.result.LazyResult.hasNext line: 79 org.h2.result.LazyResult.next line: 59 org.h2.command.dml.Select.queryFlat line: 527 org.h2.command.dml.Select.queryWithoutCache line: 633 org.h2.command.dml.Query.queryWithoutCacheLazyCheck line: 114 org.h2.command.dml.Query.query line: 352 org.h2.command.dml.Query.query line: 333 org.h2.command.CommandContainer.query line: 114 org.h2.command.Command.executeQuery line: 202 org.h2.jdbc.JdbcPreparedStatement.executeQuery line: 114 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery line: 824 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer line: 912 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0 line: 417 org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest line: 242 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage line: 2138 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$17 line: 2095 org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$$Lambda$482/222427158.onMessage line: not available org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage line: 3379 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener line: 1843 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0 line: 1468 org.apache.ignite.internal.managers.communication.GridIoManager.access$5200 line: 229 org.apache.ignite.internal.managers.communication.GridIoManager$9.run line: 1365 java.util.concurrent.ThreadPoolExecutor.runWorker line: 1149 java.util.concurrent.ThreadPoolExecutor$Worker.run line: 624 java.lang.Thread.run line: 748 > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161756#comment-17161756 ] Stanilovsky Evgeny commented on IGNITE-13270: - you can erase sensitive info, looks like it would be better than only description) > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
