[jira] [Created] (IGNITE-14292) Change permissions required to create/destroy caches in GridRestProcessor
Andrey Kuznetsov created IGNITE-14292:
-
Summary: Change permissions required to create/destroy caches in
GridRestProcessor
Key: IGNITE-14292
URL: https://issues.apache.org/jira/browse/IGNITE-14292
Project: Ignite
Issue Type: Improvement
Components: security
Affects Versions: 2.9.1
Reporter: Andrey Kuznetsov
{{GridRestProcessor}} authorizes {{ADMIN_CACHE}} permission before cache
creation/destruction. This is inconsistent with thin client connector behavior
and looks counterintuitive. {{ADMIN_CACHE}} should be replaced with
{{CACHE_CREATE}} and {{CACHE_DESTROY}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14207) Access to system views is not controlled by security processor
Andrey Kuznetsov created IGNITE-14207:
-
Summary: Access to system views is not controlled by security
processor
Key: IGNITE-14207
URL: https://issues.apache.org/jira/browse/IGNITE-14207
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Andrey Kuznetsov
As of now, it is impossible to restrict access to system views (SYS scheme)
with {{IgniteSecurityProcessor}}; this should be fixed.
Suggestions:
- add new {{SecurityPermission}};
- authorize this permission before accessing any system view.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14160) Issue log warning when GridNioSslHandler.handshake() takes too long
Andrey Kuznetsov created IGNITE-14160: - Summary: Issue log warning when GridNioSslHandler.handshake() takes too long Key: IGNITE-14160 URL: https://issues.apache.org/jira/browse/IGNITE-14160 Project: Ignite Issue Type: Task Affects Versions: 2.9.1 Reporter: Andrey Kuznetsov This will be helpful in investigating client connectivity/performance issues. Threshold duration can be just a reasonable constant, say, 1 second. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13505) WalCompactionAfterRestartTest fails stabilly
Andrey Kuznetsov created IGNITE-13505: - Summary: WalCompactionAfterRestartTest fails stabilly Key: IGNITE-13505 URL: https://issues.apache.org/jira/browse/IGNITE-13505 Project: Ignite Issue Type: Bug Affects Versions: 2.8.1 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov And also, the test is not included to any test suite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12832) Add user attributes support to control.sh
Andrey Kuznetsov created IGNITE-12832:
-
Summary: Add user attributes support to control.sh
Key: IGNITE-12832
URL: https://issues.apache.org/jira/browse/IGNITE-12832
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.8
Reporter: Andrey Kuznetsov
Change [1] introduced user attributes for various thin clients.
{{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
impossible to set user attributes in corresponding {{GridClientConfiguration}}
currenly. I suggest to add such an ability by adding
{{--attr-some-attr-name=attrValue}} command line option.
To prevent command line pollution I also suggest to implement {{.properties}}
file support, so that command line arguments (including {{--attr*}} arguments)
could be hidden in a file specified by {{--config filename.properties}}. In
case of duplication explicit command line arguments should take precedence over
arguments set in {{.properties}} file.
[1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12744) Add user attributes to GridRestRequest creation routine
Andrey Kuznetsov created IGNITE-12744:
-
Summary: Add user attributes to GridRestRequest creation routine
Key: IGNITE-12744
URL: https://issues.apache.org/jira/browse/IGNITE-12744
Project: Ignite
Issue Type: Improvement
Components: rest
Affects Versions: 2.8
Reporter: Andrey Kuznetsov
Improvement [1] has added user attributes support to Ignite thin clients. REST
API connections should also support this feature:
{{GridJettyRestHandler.createRequest}} can read user attributes from HTTP
request parameters.
[1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12718) Python Thin Client: add an ability to specify keyfile password
Andrey Kuznetsov created IGNITE-12718:
-
Summary: Python Thin Client: add an ability to specify keyfile
password
Key: IGNITE-12718
URL: https://issues.apache.org/jira/browse/IGNITE-12718
Project: Ignite
Issue Type: Improvement
Components: thin client
Affects Versions: 2.8
Reporter: Andrey Kuznetsov
In pyignite, there is no way to specify password for keyfile being used to
establish TLS connection to Ignite cluster. If keyfile is encrypted, then
OpenSSL library prompts for password interactively.
In order to add configurable password, one can set up explicit {{SSLContext}}
instead of {{ssl.wrap_socket}} call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12304) All DataRegionMetrics should be documented
Andrey Kuznetsov created IGNITE-12304:
-
Summary: All DataRegionMetrics should be documented
Key: IGNITE-12304
URL: https://issues.apache.org/jira/browse/IGNITE-12304
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Andrey Kuznetsov
Fix For: 2.8
All metrics added to {{DataRegionMetrics}} interface by [1] should be
documented.
[1] https://issues.apache.org/jira/browse/IGNITE-8078
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
Andrey Kuznetsov created IGNITE-12220:
-
Summary: Allow to use cache-related permissions both at system and
per-cache levels
Key: IGNITE-12220
URL: https://issues.apache.org/jira/browse/IGNITE-12220
Project: Ignite
Issue Type: Task
Components: security
Affects Versions: 2.7.6
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.8
Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
be system-level permissions, see for instance
{{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks inflexible:
Ignite Security implementations are not able to manage cache creation and
deletion permissions on per-cache basis (unlike get/put/remove permissions).
All such limitations should be found and removed on order to allow all
{{CACHE_*}} permissions to be set both at system and per-cache levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-11286) Add console prompt for password in control.(sh|bat) script
Andrey Kuznetsov created IGNITE-11286:
-
Summary: Add console prompt for password in control.(sh|bat) script
Key: IGNITE-11286
URL: https://issues.apache.org/jira/browse/IGNITE-11286
Project: Ignite
Issue Type: Task
Affects Versions: 2.7
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
For security reasons we are to add interactive alternative to {{--password}}.
Other password-related options already have this alternative, see [1].
[1] https://jira.apache.org/jira/browse/IGNITE-10257
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11268) Unable to run control.bat or ignite.bat from Ignite source tree with compiled classes
Andrey Kuznetsov created IGNITE-11268:
-
Summary: Unable to run control.bat or ignite.bat from Ignite
source tree with compiled classes
Key: IGNITE-11268
URL: https://issues.apache.org/jira/browse/IGNITE-11268
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Under Windows, {{control}} and {{ignite}} scripts collect Java classpath value
from {{%IGNITE_HOME%\modules\*\target}} directories into a variable. Batch
script variable length is limited to 8k characters, and this leads to error
when there are many compiled/packaged modules in a source tree.
Possible (yet imperfect) solutions:
- Limit modules list to some minimal required sublist.
- Create Class-Path-header-only jar "on the fly".
- (Java 9+ only) Generate command-line arguments file, see [1].
[1]
https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11267) Print Warn user when keystore password arguments
Andrey Kuznetsov created IGNITE-11267: - Summary: Print Warn user when keystore password arguments Key: IGNITE-11267 URL: https://issues.apache.org/jira/browse/IGNITE-11267 Project: Ignite Issue Type: Bug Reporter: Andrey Kuznetsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10813) Run CheckpointReadLockFailureTest with JUnit4 runner
Andrey Kuznetsov created IGNITE-10813: - Summary: Run CheckpointReadLockFailureTest with JUnit4 runner Key: IGNITE-10813 URL: https://issues.apache.org/jira/browse/IGNITE-10813 Project: Ignite Issue Type: Bug Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov The test fails on TeamCity. Should be run in JUnit4 manner. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10079) FileWriteAheadLogManager may return invalid lastCompactedSegment
Andrey Kuznetsov created IGNITE-10079:
-
Summary: FileWriteAheadLogManager may return invalid
lastCompactedSegment
Key: IGNITE-10079
URL: https://issues.apache.org/jira/browse/IGNITE-10079
Project: Ignite
Issue Type: Bug
Components: persistence
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.8
Attachments: WalCompactionAfterRestartTest.java
As of current {{master}} branch,
{{FileWriteAheadLogManager#lastCompactedSegment}} may report -1 even after some
segments have been actually compressed. Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
Andrey Kuznetsov created IGNITE-10003:
-
Summary: Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR
when checkpoint read lock timeout detected
Key: IGNITE-10003
URL: https://issues.apache.org/jira/browse/IGNITE-10003
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Andrey Kuznetsov
Fix For: 2.8
{{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
{{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9932) Exchanger blocking session bounds can be accessed from invalid thread
Andrey Kuznetsov created IGNITE-9932:
Summary: Exchanger blocking session bounds can be accessed from
invalid thread
Key: IGNITE-9932
URL: https://issues.apache.org/jira/browse/IGNITE-9932
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
{{GridDhtPartitionExchangeFuture}} uses critical sections surrounded by
{{exchangerBlockingSectionBegin}} and {{exchangerBlockingSectionEnd}}.
Currently, these begin/end bounds assert they are called from
partition-exchanger thread. It appeared that this assertion can be failed
reasonably. So it is better to make begin/end bounds no-op unless they are
called from partition-exchanger thread.
{{IgniteStableBaselineBinObjFieldsQuerySelfTest#testQueryReplicatedTransactional}}
may hang due to this issue, see [1]. Exception stack trace leading to critical
failure follows.
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.exchangerBlockingSectionBegin(GridCachePartitionExchangeManager.java:2351)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitUntilNewCachesAreRegistered(GridDhtPartitionsExchangeFuture.java:2261)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2066)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:3980)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$2100(GridDhtPartitionsExchangeFuture.java:141)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$7.apply(GridDhtPartitionsExchangeFuture.java:3667)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$7.apply(GridDhtPartitionsExchangeFuture.java:3655)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:3655)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1655)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:393)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3178)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3157)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
[1]
https://ci.ignite.apache.org/viewLog.html?buildId=2111470=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperQueries
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9860) Unreliable listener invocation order in GridDhtPartitionsExchangeFuture#onDone
Andrey Kuznetsov created IGNITE-9860:
Summary: Unreliable listener invocation order in
GridDhtPartitionsExchangeFuture#onDone
Key: IGNITE-9860
URL: https://issues.apache.org/jira/browse/IGNITE-9860
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Fix For: 2.8
Listener being added right before {{super.onDone()}} call is intended to be
invoked earlier than all other listeners. There is a small probability of
breaking this guarantee: some other thread can call {{listen()}} before
future-completing thread enters {{super.onDone()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9838) TxStateChangeEventTest fails sometimes on TeamCity
Andrey Kuznetsov created IGNITE-9838: Summary: TxStateChangeEventTest fails sometimes on TeamCity Key: IGNITE-9838 URL: https://issues.apache.org/jira/browse/IGNITE-9838 Project: Ignite Issue Type: Test Reporter: Andrey Kuznetsov Fix For: 2.8 Both test methods may fail to acquire transaction lock. Presumably, timeout increasing can be enough to fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9776) FsyncModeFileWriteAheadLogManager can block forever in log() call
Andrey Kuznetsov created IGNITE-9776:
Summary: FsyncModeFileWriteAheadLogManager can block forever in
log() call
Key: IGNITE-9776
URL: https://issues.apache.org/jira/browse/IGNITE-9776
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Fix For: 2.7
Attachments: FsyncWalRolloverDoesNotBlockTest.java
If WAL archiver is disabled and WALRecord being logged has {{rollOver() ==
true}}, then {{log()}} call blocks forever in {{FileArchiver}}'s (!) method:
{noformat}
nextAbsoluteSegmentIndex:1707, FsyncModeFileWriteAheadLogManager$FileArchiver
(org.apache.ignite.internal.processors.cache.persistence.wal)
access$3200:1437, FsyncModeFileWriteAheadLogManager$FileArchiver
(org.apache.ignite.internal.processors.cache.persistence.wal)
pollNextFile:1384, FsyncModeFileWriteAheadLogManager
(org.apache.ignite.internal.processors.cache.persistence.wal)
initNextWriteHandle:1243, FsyncModeFileWriteAheadLogManager
(org.apache.ignite.internal.processors.cache.persistence.wal)
rollOver:1130, FsyncModeFileWriteAheadLogManager
(org.apache.ignite.internal.processors.cache.persistence.wal)
log:712, FsyncModeFileWriteAheadLogManager
(org.apache.ignite.internal.processors.cache.persistence.wal)
{noformat}
Reporoducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9744) Fix SYSTEM_WORKER_TERMINATION detection in general case
Andrey Kuznetsov created IGNITE-9744:
Summary: Fix SYSTEM_WORKER_TERMINATION detection in general case
Key: IGNITE-9744
URL: https://issues.apache.org/jira/browse/IGNITE-9744
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.7
All existing critical workers handle unintended termination individually. This
should be done for arbitrtary critical worker as well. There is a test to check
this situation, {{SystemWorkersTerminationTest.testTermination}}, but now it
passes in fact due to {{SYSTEM_WORKER_BLOCKED}} instead of
{{SYSTEM_WORKER_TERMINATION}}, and this should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9731) NPE is possible during WAL flushing
Andrey Kuznetsov created IGNITE-9731:
Summary: NPE is possible during WAL flushing
Key: IGNITE-9731
URL: https://issues.apache.org/jira/browse/IGNITE-9731
Project: Ignite
Issue Type: Task
Reporter: Andrey Kuznetsov
Fix For: 2.7
Attachments: WalRolloverRecordLoggingTest.java
{{FileWriteAheadLogManager.flush()}} seems to be not thread-safe anymore in
master branch. The test attached produces the following NPE:
{noformat}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileHandle.getSegmentId(FileWriteAheadLogManager.java:2371)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.needFsync(FileWriteAheadLogManager.java:2642)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2668)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1900(FileWriteAheadLogManager.java:2445)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:866)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3633)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3126)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:3025)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
This could be possibly brought by commit [1].
[1]
https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9695) Add a way to prevent per-cache WAL disabling in WalStateManager
Andrey Kuznetsov created IGNITE-9695:
Summary: Add a way to prevent per-cache WAL disabling in
WalStateManager
Key: IGNITE-9695
URL: https://issues.apache.org/jira/browse/IGNITE-9695
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.8
When this prevention is on, {{WalStateManager.init()}} should return an
error-holding future immediately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9679) Document critical workers liveness checking implementation
Andrey Kuznetsov created IGNITE-9679:
Summary: Document critical workers liveness checking implementation
Key: IGNITE-9679
URL: https://issues.apache.org/jira/browse/IGNITE-9679
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Andrey Kuznetsov
Assignee: Denis Magda
Fix For: 2.7
Newly implemented critical worker thread liveness checks should be mentioned in
Ignite Documentation. Brief description of the functionality follows.
Ignite node has a number of critical worker threads that should be alive and
responsive, otherwise node's health is not guaranteed. These threads monitor
each other periodically and track two aspects for a thread being checked:
- whether it's alive;
- whether it updates its internal heartbeat timestamp.
Both checks use {{IgniteConfiguration.failureDetectionTimeout}} property as a
threshold value.
Whenever at least one of the above conditions is violated, checker thread logs
the error and calls currently configured {{FailureHandler}}.
Liveness checks are enabled by default, but can be disabled through
{{WorkersControlMXBean.healthMonitoringEnabled}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9666) TxPessimisticDeadlockDetectionCrossCacheTest.testDeadlockAnotherNear is flaky on master
Andrey Kuznetsov created IGNITE-9666:
Summary:
TxPessimisticDeadlockDetectionCrossCacheTest.testDeadlockAnotherNear is flaky
on master
Key: IGNITE-9666
URL: https://issues.apache.org/jira/browse/IGNITE-9666
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Andrey Kuznetsov
Fix For: 2.8
Sometimes the test cannot pass {{assertTrue(deadlock.get())}}.
Presumably, it's due to ignoring possible long JVM pauses. For example, one can
see near the first 'put' pair (note timestamps) :
{noformat}
[2018-09-23 11:16:55,975][INFO ][tx-thread-1][root] >>> Performs put
[node=TcpDiscoveryNode [id=dd46ab0e-ed28-4c67-b3c4-98900bb0,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1537690615852, loc=true,
ver=2.7.0#19700101-sha1:, isClient=false], tx=TransactionProxyImpl
[tx=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=149170604,
order=1537690611182, nodeOrder=1], writeVer=null, implicit=false, loc=true,
threadId=129, startTime=1537690615791,
nodeId=dd46ab0e-ed28-4c67-b3c4-98900bb0, startVer=GridCacheVersion
[topVer=149170604, order=1537690611182, nodeOrder=1], endVer=null,
isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=500,
sysInvalidate=false, sys=false, plc=2, commitVer=null, finalizing=NONE,
invalidParts=null, state=ACTIVE, timedOut=false, topVer=AffinityTopologyVersion
[topVer=-1, minorTopVer=0],
txCounters=org.apache.ignite.internal.processors.cache.transactions.TxCounters@31c7393f,
duration=155ms, onePhaseCommit=false]IgniteTxLocalAdapter [completedBase=null,
sndTransformedVals=false, depEnabled=false, txState=IgniteTxStateImpl
[activeCacheIds=[], recovery=null, mvccEnabled=null, txMap=EmptySet []],
mvccWaitTxs=null, qryEnlisted=false, super=, size=0]GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=KeySetView [], dhtNodes=KeySetView [],
explicitLock=false, super=]GridNearTxLocal [mappings=IgniteTxMappingsImpl [],
nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null,
hasRemoteLocks=false, trackTimeout=true, lb=null, mvccTracker=null, sql=null,
thread=tx-thread-1, mappings=IgniteTxMappingsImpl [], super=], async=false,
asyncRes=null], key=2, cache=cache0]
[2018-09-23 11:16:55,975][INFO ][tx-thread-2][root] >>> Performs put
[node=TcpDiscoveryNode [id=dd46ab0e-ed28-4c67-b3c4-98900bb0,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1537690615852, loc=true,
ver=2.7.0#19700101-sha1:, isClient=false], tx=TransactionProxyImpl
[tx=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=149170604,
order=1537690611181, nodeOrder=1], writeVer=null, implicit=false, loc=true,
threadId=130, startTime=1537690615791,
nodeId=dd46ab0e-ed28-4c67-b3c4-98900bb0, startVer=GridCacheVersion
[topVer=149170604, order=1537690611182, nodeOrder=1], endVer=null,
isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=500,
sysInvalidate=false, sys=false, plc=2, commitVer=null, finalizing=NONE,
invalidParts=null, state=ACTIVE, timedOut=false, topVer=AffinityTopologyVersion
[topVer=-1, minorTopVer=0],
txCounters=org.apache.ignite.internal.processors.cache.transactions.TxCounters@14d54c9c,
duration=155ms, onePhaseCommit=false]IgniteTxLocalAdapter [completedBase=null,
sndTransformedVals=false, depEnabled=false, txState=IgniteTxStateImpl
[activeCacheIds=[], recovery=null, mvccEnabled=null, txMap=EmptySet []],
mvccWaitTxs=null, qryEnlisted=false, super=, size=0]GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=KeySetView [], dhtNodes=KeySetView [],
explicitLock=false, super=]GridNearTxLocal [mappings=IgniteTxMappingsImpl [],
nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null,
hasRemoteLocks=false, trackTimeout=true, lb=null, mvccTracker=null, sql=null,
thread=tx-thread-2, mappings=IgniteTxMappingsImpl [], super=], async=false,
asyncRes=null], key=2, cache=cache1]
[2018-09-23 11:16:56,378][INFO
][exchange-worker-#38%transactions.TxPessimisticDeadlockDetectionCrossCacheTest0%][time]
Started exchange init [topVer=AffinityTopologyVersion [topVer=2,
minorTopVer=3], mvccCrd=MvccCoordinator
[nodeId=dd46ab0e-ed28-4c67-b3c4-98900bb0, crdVer=1537690602134,
topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0]], mvccCrdChange=false,
crd=true, evt=DISCOVERY_CUSTOM_EVT,
evtNode=dd46ab0e-ed28-4c67-b3c4-98900bb0,
customEvt=CacheAffinityChangeMessage
[id=d7540850661-799b6d10-6e53-4f8b-9595-98f8c060efa1,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], exchId=null,
partsMsg=null, exchangeNeeded=true], allowMerge=false]
{noformat}
And then, transactions have to roll back due to 500 ms timeout, leaving no
possibility to produce deadlock.
--
This message was sent by
[jira] [Created] (IGNITE-9660) Switch default test FailureHandler to StopNodeFailureHandler
Andrey Kuznetsov created IGNITE-9660:
Summary: Switch default test FailureHandler to
StopNodeFailureHandler
Key: IGNITE-9660
URL: https://issues.apache.org/jira/browse/IGNITE-9660
Project: Ignite
Issue Type: Test
Affects Versions: 2.6
Reporter: Andrey Kuznetsov
Fix For: 2.8
{{GridAbstractTest.getFailureHandler()}} returns {{NoOpFailureHandler}}
instance. This often leads to hiding bugs occurring in tests.
{{getFailureFailureHandler()}} should return {{StopNodeFailureHandler}} instead.
The change assumes re-checking failed tests and set handler to
{{NoOpFailureHandler}} in subclasses where it's really a must.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9653) StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch
Andrey Kuznetsov created IGNITE-9653: Summary: StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch Key: IGNITE-9653 URL: https://issues.apache.org/jira/browse/IGNITE-9653 Project: Ignite Issue Type: Bug Reporter: Andrey Kuznetsov Fix For: 2.8 ``` junit.framework.AssertionFailedError at org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93) ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9640) [TC Bot] Determine repetitive failure types by analyzing build log
Andrey Kuznetsov created IGNITE-9640:
Summary: [TC Bot] Determine repetitive failure types by analyzing
build log
Key: IGNITE-9640
URL: https://issues.apache.org/jira/browse/IGNITE-9640
Project: Ignite
Issue Type: Task
Reporter: Andrey Kuznetsov
When someone is analyzing flaky test failure, it's important to distinguish
between newly created failure and pre-existing one. In the latter case, the bot
should not attract contributor's attention to the test.
In more detail, TC build log fragments starts with identical substrings for
identical failures very often, e.g.
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.internal.GridVersionSelfTest.testVersions(GridVersionSelfTest.java:54)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9601) Write rollover WAL record as the last
Andrey Kuznetsov created IGNITE-9601: Summary: Write rollover WAL record as the last Key: IGNITE-9601 URL: https://issues.apache.org/jira/browse/IGNITE-9601 Project: Ignite Issue Type: Task Affects Versions: 2.6 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.8 Currently, rollover WAL record gets to the next segment when being logged. Moreover, the implementation does allows data races, and rollover record is not necessarily the first record in the next segment. We are to add an option to logging facility to allow writing rollover record to the end of the current segment; subsequent records should get to the next segment then. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9280) Decrease WAL archive compaction latency
Andrey Kuznetsov created IGNITE-9280:
Summary: Decrease WAL archive compaction latency
Key: IGNITE-9280
URL: https://issues.apache.org/jira/browse/IGNITE-9280
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.6
Reporter: Andrey Kuznetsov
Fix For: 2.7
If {{n}} is the index of WAL segment containing latest checkpoint mark, then
the segment {{n-1}} is prevented from compaction currently. This limitation can
be removed safely (while the requirement of preserving raw segment {{n-1}}
should remain untouched).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8887) IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAccessAndModificationTimeUpwardsPropagation fails flakily on master
Andrey Kuznetsov created IGNITE-8887:
Summary:
IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAccessAndModificationTimeUpwardsPropagation
fails flakily on master
Key: IGNITE-8887
URL: https://issues.apache.org/jira/browse/IGNITE-8887
Project: Ignite
Issue Type: Bug
Components: igfs
Affects Versions: 2.5
Reporter: Andrey Kuznetsov
Fix For: 2.7
{noformat}
junit.framework.AssertionFailedError: expected: but was:
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
at junit.framework.TestCase.assertEquals(TestCase.java:253)
at
org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest.testAccessAndModificationTimeUpwardsPropagation(IgfsDualAbstractSelfTest.java:1544)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8862) IgniteChangeGlobalStateTest hangs on TeamCity
Andrey Kuznetsov created IGNITE-8862: Summary: IgniteChangeGlobalStateTest hangs on TeamCity Key: IGNITE-8862 URL: https://issues.apache.org/jira/browse/IGNITE-8862 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8570) Create lighter version of GridStringLogger
Andrey Kuznetsov created IGNITE-8570:
Summary: Create lighter version of GridStringLogger
Key: IGNITE-8570
URL: https://issues.apache.org/jira/browse/IGNITE-8570
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Fix For: 2.6
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node. Then, after some activity on
that node, log content is searched for some predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to store
log contents, older contents gets dropped on exaustion. Thus, changes that add
more logging may damage some independent tests that use {{GridStringLogger}}.
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs.
* It allows to set the listener that fires when log message matches certain
regular expression, {{Matcher}} can be passed to the listener.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8562) Turn system-critical Ignite threads into GridWorkers
Andrey Kuznetsov created IGNITE-8562:
Summary: Turn system-critical Ignite threads into GridWorkers
Key: IGNITE-8562
URL: https://issues.apache.org/jira/browse/IGNITE-8562
Project: Ignite
Issue Type: Improvement
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.6
The goal of the change is to make system-critical threads (in terms of IEP-14,
[1]) available to {{WorkersControlMXBean}}.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc
Andrey Kuznetsov created IGNITE-8406:
Summary: Update IgniteDataStreamer.flush() javadoc
Key: IGNITE-8406
URL: https://issues.apache.org/jira/browse/IGNITE-8406
Project: Ignite
Issue Type: Task
Components: streaming
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Fix For: 2.6
Current {{flush()}} implementation can throw {{CacheException}} if one or more
futures previously returned by {{addData()}} have been completed exceptionally.
This behavior should be described in {{IgniteDataStreamer}} javadoc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8329) Clarify TransactionRollbackException-related paragraph in documentation
Andrey Kuznetsov created IGNITE-8329: Summary: Clarify TransactionRollbackException-related paragraph in documentation Key: IGNITE-8329 URL: https://issues.apache.org/jira/browse/IGNITE-8329 Project: Ignite Issue Type: Task Reporter: Andrey Kuznetsov As documentation states currently [1], TransactionRollbackException is thrown "if the transaction was rolled back automatically". This should be extended to manual rollback as well, if it took place before commit for some reason. [1] https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8312) .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure
Andrey Kuznetsov created IGNITE-8312:
Summary: .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly
failure
Key: IGNITE-8312
URL: https://issues.apache.org/jira/browse/IGNITE-8312
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.5
{noformat}
Test(s) failed. Expected:
But was: (Invalid transaction
state for prepare [state=MARKED_ROLLBACK, tx=GridNearPessimisticTxPrepareFuture
[innerFuts=[], super=GridCompoundFuture
[rdc=org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareFutureAdapter$1@62e703a4,
initFlag=0, lsnrCalls=0, done=false, cancelled=false, err=null, futs=[)
{noformat}
Caused by changes made in [1]
[1] https://issues.apache.org/jira/browse/IGNITE-7770
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8311) IgniteClientRejoinTest.testClientsReconnectDisabled causes exchange-worker to terminate via NPE
Andrey Kuznetsov created IGNITE-8311:
Summary: IgniteClientRejoinTest.testClientsReconnectDisabled
causes exchange-worker to terminate via NPE
Key: IGNITE-8311
URL: https://issues.apache.org/jira/browse/IGNITE-8311
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Fix For: 2.6
Currently, tests use {{NoOpFailureHandler}} by default, hence this
exchange-worker termination is masked. We are to fix it: test code should not
be able to terminate system-critical thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8297) TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily
Andrey Kuznetsov created IGNITE-8297:
Summary:
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily
Key: IGNITE-8297
URL: https://issues.apache.org/jira/browse/IGNITE-8297
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.6
Transactions sometimes don't stop on timeout. Speaking more detailed,
{{GridNearOptimisticTxPrepareFuture}} and
{{GridNearOptimisticSerializableTxPrepareFuture}} has {{keyLockFut}} field that
can remain uncompleted after timeout occured.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8223) GridNearTxLocal.clearPrepareFuture does effectively nothing
Andrey Kuznetsov created IGNITE-8223:
Summary: GridNearTxLocal.clearPrepareFuture does effectively
nothing
Key: IGNITE-8223
URL: https://issues.apache.org/jira/browse/IGNITE-8223
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Fix For: 2.6
It's unclear whether {{GridNearTxLocal.clearPrepareFuture}} is called at all,
but the method does nothing, since its argument type is never used as target
field value. Proposed change is to make the method no-op explicitly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8061) GridCachePartitionedDataStructuresFailoverSelfTest.testCountDownLatchConstantMultipleTopologyChange may hang on TeamCity
Andrey Kuznetsov created IGNITE-8061: Summary: GridCachePartitionedDataStructuresFailoverSelfTest.testCountDownLatchConstantMultipleTopologyChange may hang on TeamCity Key: IGNITE-8061 URL: https://issues.apache.org/jira/browse/IGNITE-8061 Project: Ignite Issue Type: Bug Components: data structures Affects Versions: 2.4 Reporter: Andrey Kuznetsov Fix For: 2.5 Attachments: log.txt The log attached contains 'Test has been timed out and will be interrupted' message, but does not contain subsequent 'Test has been timed out [test=...'. Known facts: * There is pending GridDhtColocatedLockFuture in the log. * On timeout, InterruptedException comes to doTestCountDownLatch, but finally-block contains the code leading to distributed locking. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8025) Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() implementation
Andrey Kuznetsov created IGNITE-8025: Summary: Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() implementation Key: IGNITE-8025 URL: https://issues.apache.org/jira/browse/IGNITE-8025 Project: Ignite Issue Type: Bug Affects Versions: 2.4 Reporter: Andrey Kuznetsov Fix For: 2.5 Attachments: BugRunMTAsyncTest.java GridTestUtils.runMultiThreadedAsync returns a future with cancel() support, but cancellation implementation never interrupts threads that execute user-provided tasks. That is, those threads can continue their execution even after test method finishes. The reproducer attached demonstrates activity from threads created by test0 after test0 finished and test1 is being run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7983) NPE in TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations
Andrey Kuznetsov created IGNITE-7983:
Summary: NPE in
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations
Key: IGNITE-7983
URL: https://issues.apache.org/jira/browse/IGNITE-7983
Project: Ignite
Issue Type: Task
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.5
{{get}} inside transaction sometimes returns {{null}}. This should be
impossible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7823) Enrich IgniteCache with asSet method
Andrey Kuznetsov created IGNITE-7823:
Summary: Enrich IgniteCache with asSet method
Key: IGNITE-7823
URL: https://issues.apache.org/jira/browse/IGNITE-7823
Project: Ignite
Issue Type: New Feature
Components: data structures
Reporter: Andrey Kuznetsov
Fix For: 2.5
Existing {{IgniteSet}} datastructure is good enough for small sets. For big
sets it's too expensive to maintain redundant onheap data copies. Thus we'd
better to add new {{IgniteCache::asSet}} method returning set adapter to
existing cache. The difference between these two kinds of sets should be
properly documented afterwards.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7518) Get rid of org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom
Andrey Kuznetsov created IGNITE-7518: Summary: Get rid of org.jsr166.LongAdder8, org.jsr166.ThreadLocalRandom Key: IGNITE-7518 URL: https://issues.apache.org/jira/browse/IGNITE-7518 Project: Ignite Issue Type: Sub-task Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7517) Get rid of org.jsr166.ConcurrentLinkedDeque8
Andrey Kuznetsov created IGNITE-7517: Summary: Get rid of org.jsr166.ConcurrentLinkedDeque8 Key: IGNITE-7517 URL: https://issues.apache.org/jira/browse/IGNITE-7517 Project: Ignite Issue Type: Sub-task Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7516) Get rid of org.jsr166.ConcurrentLinkedHashMap
Andrey Kuznetsov created IGNITE-7516: Summary: Get rid of org.jsr166.ConcurrentLinkedHashMap Key: IGNITE-7516 URL: https://issues.apache.org/jira/browse/IGNITE-7516 Project: Ignite Issue Type: Sub-task Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8
Andrey Kuznetsov created IGNITE-7513: Summary: Get rid of org.jsr166.ConcurrentHashMap8 Key: IGNITE-7513 URL: https://issues.apache.org/jira/browse/IGNITE-7513 Project: Ignite Issue Type: Task Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.5 This class was made of ConcurrentHashMapV8, an intermadiate implementation of Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, we'll have to check for performance implications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7491) Documentation: add new data region metrics description
Andrey Kuznetsov created IGNITE-7491: Summary: Documentation: add new data region metrics description Key: IGNITE-7491 URL: https://issues.apache.org/jira/browse/IGNITE-7491 Project: Ignite Issue Type: Task Components: documentation Reporter: Andrey Kuznetsov Assignee: Denis Magda Fix For: 2.4 Newly created data region metrics should be documented. * `getTotalAllocatedSize` -- same as `getTotalAllocatedPages` but in bytes. * `getPhysicalMemorySize` -- same as `getPhysicalMemoryPages` but in bytes. * `getCheckpointBufferPages` -- gets checkpoint buffer size in pages. * `getCheckpointBufferSize` -- gets checkpoint buffer size in bytes. * `getPageSize` -- gets memory page size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7312) Make use of plain java.util.Base64 instead of reflective alternatives
Andrey Kuznetsov created IGNITE-7312:
Summary: Make use of plain java.util.Base64 instead of reflective
alternatives
Key: IGNITE-7312
URL: https://issues.apache.org/jira/browse/IGNITE-7312
Project: Ignite
Issue Type: Task
Components: general
Reporter: Andrey Kuznetsov
Reflective Base64 encoding should be changed to {{java.util.Base64$Encoder}} as
soon as language level becomes equal to 8.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7171) .NET: Support additional Data Region metrics
Andrey Kuznetsov created IGNITE-7171: Summary: .NET: Support additional Data Region metrics Key: IGNITE-7171 URL: https://issues.apache.org/jira/browse/IGNITE-7171 Project: Ignite Issue Type: New Feature Reporter: Andrey Kuznetsov Fix For: 2.4 Issue [1] adds two new Data Region metrics. Both should be added to .NET as well. [1] https://issues.apache.org/jira/browse/IGNITE-6902 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6963) TotalAllocatedPages metric does not match PhysicalMemoryPages when persistence is disabled
Andrey Kuznetsov created IGNITE-6963:
Summary: TotalAllocatedPages metric does not match
PhysicalMemoryPages when persistence is disabled
Key: IGNITE-6963
URL: https://issues.apache.org/jira/browse/IGNITE-6963
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.3
Reporter: Andrey Kuznetsov
As javadoc states for DataRegionMetrics#getPhysicalMemoryPages()
{noformat}
When persistence is disabled, this metric is equal to getTotalAllocatedPages()
{noformat}
and this seems to be sane requirement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6940) Provide metric to monitor Thread Starvation
Andrey Kuznetsov created IGNITE-6940:
Summary: Provide metric to monitor Thread Starvation
Key: IGNITE-6940
URL: https://issues.apache.org/jira/browse/IGNITE-6940
Project: Ignite
Issue Type: Improvement
Security Level: Public (Viewable by anyone)
Reporter: Andrey Kuznetsov
There is an existing code in {{IgniteKernal.start()}} that logs warnings when
detects starvation. It should be improved to support more thread pools and
update some metrics.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6520) IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout)
Andrey Kuznetsov created IGNITE-6520: Summary: IgniteCacheGetRestartTest.testGetRestartReplicated fails sometimes (timeout) Key: IGNITE-6520 URL: https://issues.apache.org/jira/browse/IGNITE-6520 Project: Ignite Issue Type: Bug Affects Versions: 2.2 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
Andrey Kuznetsov created IGNITE-6186: Summary: Remove redundant parameter of GridFutureAdapter::unregisterWaiter() Key: IGNITE-6186 URL: https://issues.apache.org/jira/browse/IGNITE-6186 Project: Ignite Issue Type: Improvement Affects Versions: 2.1 Reporter: Andrey Kuznetsov Priority: Minor Fix For: 2.2 The method is not thread-safe unless actual parameter is currentThread. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6137) Inaccurate CAS handling in GridNearTxLocal async commit
Andrey Kuznetsov created IGNITE-6137: Summary: Inaccurate CAS handling in GridNearTxLocal async commit Key: IGNITE-6137 URL: https://issues.apache.org/jira/browse/IGNITE-6137 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.1 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.2 CAS for commitFuture is handled inaccurate in commitNearTxLocalAsync method. Can fail on muliple calls, either concurrent or sequential. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics
Andrey Kuznetsov created IGNITE-6043:
Summary: Fix GridCacheSemaphoreImpl methods semantics
Key: IGNITE-6043
URL: https://issues.apache.org/jira/browse/IGNITE-6043
Project: Ignite
Issue Type: Bug
Components: data structures
Affects Versions: 2.1
Reporter: Andrey Kuznetsov
Priority: Critical
Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted
method semantics: {{acquire()}} releases the permit and {{release()}} acquires
it. Also, debug-level method {{availablePermits()}} returns permits acquired so
far. This confusing behaviour should be fixed.
Also, it's worth noting in IgniteSemaphore's javadoc it's unbounded nature, as
opposed to {{java.util.concurrent.Semaphore}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
