[jira] [Created] (IGNITE-9804) SSL: Expired certificates are not refused
Andrew Medvedev created IGNITE-9804: --- Summary: SSL: Expired certificates are not refused Key: IGNITE-9804 URL: https://issues.apache.org/jira/browse/IGNITE-9804 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev Expired certificate scenarios are not covered by current tests # Set date to 2038: sudo date --set='@2147483647' # Run org.apache.ignite.client.SecurityTest#testEncryption Connection is accepted although certificate expires in 2032. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9782) Webconsole: Form too large
Andrew Medvedev created IGNITE-9782:
---
Summary: Webconsole: Form too large
Key: IGNITE-9782
URL: https://issues.apache.org/jira/browse/IGNITE-9782
Project: Ignite
Issue Type: Bug
Reporter: Andrew Medvedev
Attachments: image.png
On large topologies form size increases jetty defaults
Consider increasing "{{org.mortbay.jetty.Request.maxFormContentSize}}"
!image.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9381) p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node disconnect
Andrew Medvedev created IGNITE-9381: --- Summary: p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node disconnect Key: IGNITE-9381 URL: https://issues.apache.org/jira/browse/IGNITE-9381 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev Attachments: AndmedScanFilterClassLoadingTest.java, snapshots.xml Once deployed via scan query, an IgniteBiPredicate filter does not change if client reconnects (with a modified filter) Steps to reproduce: * start server node in separate jvm with attached configuration (persistence enabled) * run attached reproducer AndmedScanFilterClassLoadingTest. It includes a task and a scan filter, both print "FOO" on server side * modify FOO -> BAR for both * re-run modifed AndmedScanFilterClassLoadingTest . Expected: Both print "BAR". Actual behavior: task prints "BAR", scan filter prints "FOO" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9235) Transitivity violation in GridMergeIndex Comparator
Andrew Medvedev created IGNITE-9235:
---
Summary: Transitivity violation in GridMergeIndex Comparator
Key: IGNITE-9235
URL: https://issues.apache.org/jira/browse/IGNITE-9235
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrew Medvedev
Currently comparator is
private final Comparator streamCmp = new Comparator() {
@Override public int compare(RowStream o1, RowStream o2) {
// Nulls at the beginning.
if (o1 == null)
return -1;
if (o2 == null)
return 1;
return compareRows(o1.get(), o2.get());
}
};
This comparator violates transitivity when both RowStream are null. Thus we get
excetption in JDK1.8:
WA: use -Djava.util.Arrays.useLegacyMergeSort=true
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9115) org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation o
Andrew Medvedev created IGNITE-9115: --- Summary: org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. Key: IGNITE-9115 URL: https://issues.apache.org/jira/browse/IGNITE-9115 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. More detailed logging should be made if reservation of partition fails -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9114) Fail fast in org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query
Andrew Medvedev created IGNITE-9114: --- Summary: Fail fast in org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query Key: IGNITE-9114 URL: https://issues.apache.org/jira/browse/IGNITE-9114 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. Exception should be thrown and method should return if no partition reservation can be made in reasonable time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8999) WebConsole should correct parsing trace error messages introduced by #8971
Andrew Medvedev created IGNITE-8999: --- Summary: WebConsole should correct parsing trace error messages introduced by #8971 Key: IGNITE-8999 URL: https://issues.apache.org/jira/browse/IGNITE-8999 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8971) GridRestProcessor should propagate error message
Andrew Medvedev created IGNITE-8971: --- Summary: GridRestProcessor should propagate error message Key: IGNITE-8971 URL: https://issues.apache.org/jira/browse/IGNITE-8971 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev GridRestProcessor should propagate error message (stack trace) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8943) Deactivation in large cluster hangs during rebalance
Andrew Medvedev created IGNITE-8943: --- Summary: Deactivation in large cluster hangs during rebalance Key: IGNITE-8943 URL: https://issues.apache.org/jira/browse/IGNITE-8943 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev In large cluster (> 100 nodes) deactivation during rebalance does not finish (we have waited for at least an hour). All nodes log "Start deactivation process" message, but on all nodes exchange-worker threads in cluster are WAITING with this stack: "exchange-worker-#152%DPL_GRID%DplGridNodeName%" #520 daemon prio=5 os_prio=0 tid=0x7f5cfb2b6000 nid=0x2dc7bc waiting on condition [0x7f59a05b2000] 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.query.continuous.CacheContinuousQueryManager.cancelInternalQuery(CacheContinuousQueryManager.java:575) at org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.onKernalStop(DataStructuresProcessor.java:253) at org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.onDeActivate(DataStructuresProcessor.java:299) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:650) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:745) This is reproducible -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8901) Duplicate messages in TcpCommunicationSpi result in "Cache is restarting" messages
Andrew Medvedev created IGNITE-8901: --- Summary: Duplicate messages in TcpCommunicationSpi result in "Cache is restarting" messages Key: IGNITE-8901 URL: https://issues.apache.org/jira/browse/IGNITE-8901 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev We have several cases with duplicate "Accepted incoming communication connection" messages in TcpCommunicationSpi for a job from client. Messages are identical including timestamp and tcp comm worker thread Server node sends duplicate outgoing messages to other cluster nodes (duplicate incoming communication connection messages can be seen in their logs). Then on some of those nodes we got [o.a.i.i.processors.job.GridJobWorker] Failed to execute job, Caused by: org.apache.ignite.IgniteCacheRestartingException: Cache is restarting Cache is started and indexed, no messages that that the cache has been stopped are logged. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8787) Striped Executor thread failure is not processed by IgniteFailureProcessor
Andrew Medvedev created IGNITE-8787: --- Summary: Striped Executor thread failure is not processed by IgniteFailureProcessor Key: IGNITE-8787 URL: https://issues.apache.org/jira/browse/IGNITE-8787 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev Attachments: after.jstack, before.jstack org.apache.ignite.internal.util.StripedExecutor.Stripe#run currently does not invoke IgniteFailureProcessor upon thread death. This can lead to dying all striped threads on a running node. see jstacks attach before and after killing all striped threads (via JMX). If striped executor threads are considered critical, they should be processed by IgniteFailureProcessor as well -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close()
Andrew Medvedev created IGNITE-8612:
---
Summary: NPE in GridCacheTtlManager#expire on commit() or close()
Key: IGNITE-8612
URL: https://issues.apache.org/jira/browse/IGNITE-8612
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrew Medvedev
We have got NPE in
org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
several times during 4 minutes from tx.close() and tx.commit() here
[https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
{{Caused by: java.lang.NullPointerException}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
This could have been IgniteCacheOffheapManager == null, cctx.offheap()
returning null, but I could not reproduce it. To debug this further, a PR with
assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8533) Timeout collision in Client Nodes test suite
Andrew Medvedev created IGNITE-8533: --- Summary: Timeout collision in Client Nodes test suite Key: IGNITE-8533 URL: https://issues.apache.org/jira/browse/IGNITE-8533 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev Fix For: 2.6 IGNITE-8085 increased NODE_START_CHECK_LIMIT so "remote" node log is parsed for longer (set now to 25 * 2000ms) https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L85 This exceeds total timeout set up for remote node startup in [https://github.com/apache/ignite/blob/282b334f76479460613f28347d8cea97ba23f795/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L1054] (40 * 1000ms) This leads to debug message with ref to remote log file being never shown because 5 timeout will never be reached [https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8351) PME isStaleUpdate() method documentation mismatch
Andrew Medvedev created IGNITE-8351: --- Summary: PME isStaleUpdate() method documentation mismatch Key: IGNITE-8351 URL: https://issues.apache.org/jira/browse/IGNITE-8351 Project: Ignite Issue Type: Bug Affects Versions: 2.4 Reporter: Andrew Medvedev Method org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#isStaleUpdate documents: "New partition map is stale if topology version or update sequence are less than of current map" Code however checks for non-strong equality for updateSequence(): ```return currentMap != null && (newMap.topologyVersion().compareTo(currentMap.topologyVersion()) < 0 || newMap.topologyVersion().compareTo(currentMap.topologyVersion()) == 0 && newMap.updateSequence() <= currentMap.updateSequence());``` We have lots of Stale update WARN msgs as in https://issues.apache.org/jira/browse/IGNITE-8226 (status is proposed to change from WARN to DEBUG, not yet merged) and on further research it looks that the code is right, the documentation is wrong. Coupled together with WARN status messages however, documentation for org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#isStaleUpdate causes concerns... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7848) On Date type mismatch DDL functionality is broken
Andrew Medvedev created IGNITE-7848: --- Summary: On Date type mismatch DDL functionality is broken Key: IGNITE-7848 URL: https://issues.apache.org/jira/browse/IGNITE-7848 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev Attachments: DateCannotBeCastTest.java when Date type in value object is originally set as java.util.Date, then after CREATE INDEX SQL queries (see attach), basic DDL functionality (SELECT) is broken -- This message was sent by Atlassian JIRA (v7.6.3#76005)
