[jira] [Created] (IGNITE-13391) Ignite-hibernate doesn't recreate cache proxies after full reconnect to the cluster
Evgenii Zhuravlev created IGNITE-13391: -- Summary: Ignite-hibernate doesn't recreate cache proxies after full reconnect to the cluster Key: IGNITE-13391 URL: https://issues.apache.org/jira/browse/IGNITE-13391 Project: Ignite Issue Type: Bug Components: hibernate Affects Versions: 2.7.6 Reporter: Evgenii Zhuravlev If there is only one server node in the cluster and user restart it, client node reconnects to the completely new cluster and, in order to continue using the ignite-hibernate integration, it should recreate all the cache proxies. Otherwise, it leads to the issue described in this thread: http://apache-ignite-users.70518.x6.nabble.com/Hibernate-2nd-Level-query-cache-with-Ignite-td33816.html We should add proxies reinitialization on reconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186579#comment-17186579
]
Pavel Tupitsyn commented on IGNITE-12754:
-
Merged to master: f1c00372875a3eb13d592fdcf778115a8f2801af
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12754:
Release Note: .NET: Add thin client service invocation API
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13383) Java thin client improvements: channel reconnect and redundant concurrency structures replacement.
[
https://issues.apache.org/jira/browse/IGNITE-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186558#comment-17186558
]
Aleksey Plekhanov commented on IGNITE-13383:
[~zstan], I see no race here. Handshake should always be synchronous from a
clients point of view (client should not send the next message until receiving
handshake response), so it's just impossible to pass condition {{connCtx ==
null}} twice for one session.
If the client implementation is not correct and can send the next message
before receiving handshake response, there will be problems even with
synchronization, since message processing order is not guaranteed, and regular
message can be processed by server before handshake request.
Do I miss something?
> Java thin client improvements: channel reconnect and redundant concurrency
> structures replacement.
> --
>
> Key: IGNITE-13383
> URL: https://issues.apache.org/jira/browse/IGNITE-13383
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that {code:java}ConcurrentHashMap{code} and
> {code:java}AtomicLong{code} are redundant in java thin client code, yes i fix
> tests a bit but i can`t see any contradictions with thick client behavior
> here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11974) infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress ...
[
https://issues.apache.org/jira/browse/IGNITE-11974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186549#comment-17186549
]
Vladislav Pyatkov commented on IGNITE-11974:
[~kamyshnikov] [~Arroyo]
Hi, I see the thread dump in the ticket is completely old and it does not full.
Please attache your full dump that is happened on Ignite 2.8, or better a
series of dump (five or ten dumps with 10 seconds interval).
When you did it I try to investigate this issue.
> infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress
> ...
>
>
> Key: IGNITE-11974
> URL: https://issues.apache.org/jira/browse/IGNITE-11974
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Igor Kamyshnikov
>Priority: Blocker
> Attachments: image-2019-07-10-16-07-37-185.png,
> server-node-restarts-1.png
>
>
> Note: RCA was not done:
> Sometimes ignite server nodes fall into infinite loop and consume 100% cpu:
> {noformat}
> "sys-#260008" #260285 prio=5 os_prio=0 tid=0x7fabb020a800 nid=0x1e850
> runnable [0x7fab26fef000]
>java.lang.Thread.State: RUNNABLE
> at
> java.util.concurrent.ConcurrentHashMap$Traverser.advance(ConcurrentHashMap.java:3339)
> at
> java.util.concurrent.ConcurrentHashMap$ValueIterator.next(ConcurrentHashMap.java:3439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:84)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:73)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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)
>Locked ownable synchronizers:
> - <0x000649b9cba0> (a
> java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> the following appears in logs each 2 minutes:
> {noformat}
> INFO 2019-07-08 12:21:45.081 (1562581305081) [sys-#98168]
> [GridDhtPartitionsEvictor] > Eviction in progress
> [grp=CUSTPRODINVOICEDISCUSAGE, remainingCnt=102]
> {noformat}
> remainingCnt remains the same once it reached 102 (the very first line in the
> logs was with value equal to 101).
> Some other facts:
> we have a heapdump taken for *topVer = 900* . the problem appeared after
> *topVer = 790*, but it looks like it was silently waiting from *topVer = 641*
> (about 24 hours back).
> There were 259 topology changes between 900 and 641.
> All 102 GridDhtLocalPartitions can be found in the heapdump:
> {noformat}
> select * from
> "org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition"
> t where delayedRenting = true
> {noformat}
> They all have status = 65537 , which means (according to
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition#state):
> reservations(65537) = 1
> getPartState(65537) = OWNING
> There are also 26968 instances of
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$70,
> that are created by
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#checkEvictions
> method.
> 26418 of 26968 refer to AtomicInteger instance with value = 102:
> 26418/102 = 259 = 900 - 641 (see topology info above).
> The key thing seen from the heapdump is that topVer = 641 or topVer = 642 was
> the last topology where these 102 partitions were assigned to the current
> ignite server node.
> {noformat}
> select
> t.this
> ,t.this['clientEvtChange'] as clientEvtChange
> ,t.this['topVer.topVer'] as topVer
>
> ,t.this['assignment.elementData'][555]['elementData'][0]['hostNames.elementData'][0]
> as primary_part
>
> ,t.this['assignment.elementData'][555]['elementData'][1]['hostNames.elementData'][0]
> as secondary_part
> from org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
> t where length(t.this['assignment.elementData']) = 1024
> order by topVer
> {noformat}
> !image-2019-07-10-16-07-37-185.png!
> The connection of a client node at topVer = 790 somehow triggered the
> GridDhtPartitionsEvictor loop to execute.
> Summary:
> 1) it is seen that 102 partitions has one reservation and OWNING state.
> 2) they were backup partitions.
> 3) for some reason their eviction has been
[jira] [Updated] (IGNITE-13390) CLI (control.sh) "get_master_key_name" command should display the current master key name.
[
https://issues.apache.org/jira/browse/IGNITE-13390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-13390:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> CLI (control.sh) "get_master_key_name" command should display the current
> master key name.
> --
>
> Key: IGNITE-13390
> URL: https://issues.apache.org/jira/browse/IGNITE-13390
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Pavel Pereslegin
>Priority: Major
>
> CLI (control.sh) "get_master_key_name" command should display current master
> key name.
> Current output is the following:
> {noformat}
> Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
> 2020 Copyright(C) Apache Software Foundation
> User: xtern
> Time: 2020-08-28T16:06:04.264
> Command [ENCRYPTION] started
> Arguments: --encryption get_master_key_name --yes
>
> Command [ENCRYPTION] finished with code: 0
> Control utility has completed execution at: 2020-08-28T16:06:04.328
> Execution time: 64 ms{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[
https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186534#comment-17186534
]
Ignite TC Bot commented on IGNITE-13308:
{panel:title=Branch: [pull/8118/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8118/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5535186]]
* {color:#013220}IgniteRestHandlerTestSuite:
GridQueryCommandHandlerTest.testNullCache - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535220]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0d4c214a-0a29-4e5c-aed9-afe1501b69c1, topVer=0,
msgTemplate=null, span=null, nodeId8=4bb32685, msg=, type=NODE_JOINED,
tstamp=1597212247090], val2=AffinityTopologyVersion
[topVer=-346328448263174824, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0d4c214a-0a29-4e5c-aed9-afe1501b69c1, topVer=0,
msgTemplate=null, span=null, nodeId8=4bb32685, msg=, type=NODE_JOINED,
tstamp=1597212247090], val2=AffinityTopologyVersion
[topVer=-346328448263174824, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c7ede41e371-8f914aa7-634a-470a-8047-67af042f51c2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e793e599-948d-46b4-8f1c-23a50dbcafcb, topVer=0, msgTemplate=null,
span=null, nodeId8=e793e599, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212247090]], val2=AffinityTopologyVersion
[topVer=-9190901870636014568, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c7ede41e371-8f914aa7-634a-470a-8047-67af042f51c2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e793e599-948d-46b4-8f1c-23a50dbcafcb, topVer=0, msgTemplate=null,
span=null, nodeId8=e793e599, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212247090]], val2=AffinityTopologyVersion
[topVer=-9190901870636014568, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535219]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bed0715c-0e9b-41b9-8732-f6f277c9073c, topVer=0,
msgTemplate=null, span=null, nodeId8=16670220, msg=, type=NODE_JOINED,
tstamp=1597212260080], val2=AffinityTopologyVersion
[topVer=8094284346878037296, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9b4ce41e371-df862fe8-e79a-4148-93c1-9c25ceae3357, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e4a3032-01d1-48d3-bedf-95f6dcdac7b2, topVer=0, msgTemplate=null,
span=null, nodeId8=6e4a3032, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212260080]], val2=AffinityTopologyVersion
[topVer=3572399462961787821, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9b4ce41e371-df862fe8-e79a-4148-93c1-9c25ceae3357, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e4a3032-01d1-48d3-bedf-95f6dcdac7b2, topVer=0, msgTemplate=null,
span=null, nodeId8=6e4a3032, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212260080]], val2=AffinityTopologyVersion
[topVer=3572399462961787821, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bed0715c-0e9b-41b9-8732-f6f277c9073c, topVer=0,
msgTemplate=null, span=null, nodeId8=16670220, msg=, type=NODE_JOINED,
tstamp=1597212260080], val2=AffinityTopologyVersion
[topVer=8094284346878037296, minorTopVer=0]]] - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5569121]]
*
[jira] [Commented] (IGNITE-13383) Java thin client improvements: channel reconnect and redundant concurrency structures replacement.
[
https://issues.apache.org/jira/browse/IGNITE-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186524#comment-17186524
]
Stanilovsky Evgeny commented on IGNITE-13383:
-
[~alex_pl] i recognize that transparent txId numeration can be implemented such
way, because of changing ClientListenerNioListener and as consequence -
session, the only fix i want to store here is [1] possible race, what do you
think ?
[1]
https://github.com/apache/ignite/pull/8184/files#diff-6f1053ded0ee927b46750b0260159bfcR154
> Java thin client improvements: channel reconnect and redundant concurrency
> structures replacement.
> --
>
> Key: IGNITE-13383
> URL: https://issues.apache.org/jira/browse/IGNITE-13383
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that {code:java}ConcurrentHashMap{code} and
> {code:java}AtomicLong{code} are redundant in java thin client code, yes i fix
> tests a bit but i can`t see any contradictions with thick client behavior
> here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13390) CLI (control.sh) "get_master_key_name" command should display the current master key name.
Pavel Pereslegin created IGNITE-13390:
-
Summary: CLI (control.sh) "get_master_key_name" command should
display the current master key name.
Key: IGNITE-13390
URL: https://issues.apache.org/jira/browse/IGNITE-13390
Project: Ignite
Issue Type: Bug
Components: control.sh
Reporter: Pavel Pereslegin
CLI (control.sh) "get_master_key_name" command should display current master
key name.
Current output is the following:
{noformat}
Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
2020 Copyright(C) Apache Software Foundation
User: xtern
Time: 2020-08-28T16:06:04.264
Command [ENCRYPTION] started
Arguments: --encryption get_master_key_name --yes
Command [ENCRYPTION] finished with code: 0
Control utility has completed execution at: 2020-08-28T16:06:04.328
Execution time: 64 ms{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13383) Java thin client improvements: channel reconnect and redundant concurrency structures replacement.
[
https://issues.apache.org/jira/browse/IGNITE-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186524#comment-17186524
]
Stanilovsky Evgeny edited comment on IGNITE-13383 at 8/28/20, 1:11 PM:
---
[~alex_pl] i recognize that transparent txId enumeration can`t be implemented
such way, because of changing ClientListenerNioListener and as consequence -
session, the only fix i want to store here is [1] possible race, what do you
think ?
[1]
https://github.com/apache/ignite/pull/8184/files#diff-6f1053ded0ee927b46750b0260159bfcR154
was (Author: zstan):
[~alex_pl] i recognize that transparent txId numeration can be implemented such
way, because of changing ClientListenerNioListener and as consequence -
session, the only fix i want to store here is [1] possible race, what do you
think ?
[1]
https://github.com/apache/ignite/pull/8184/files#diff-6f1053ded0ee927b46750b0260159bfcR154
> Java thin client improvements: channel reconnect and redundant concurrency
> structures replacement.
> --
>
> Key: IGNITE-13383
> URL: https://issues.apache.org/jira/browse/IGNITE-13383
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that {code:java}ConcurrentHashMap{code} and
> {code:java}AtomicLong{code} are redundant in java thin client code, yes i fix
> tests a bit but i can`t see any contradictions with thick client behavior
> here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13390) CLI (control.sh) "get_master_key_name" command should display the current master key name.
[
https://issues.apache.org/jira/browse/IGNITE-13390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-13390:
--
Description:
CLI (control.sh) "get_master_key_name" command should display current master
key name.
Current output is the following:
{noformat}
Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
2020 Copyright(C) Apache Software Foundation
User: xtern
Time: 2020-08-28T16:06:04.264
Command [ENCRYPTION] started
Arguments: --encryption get_master_key_name --yes
Command [ENCRYPTION] finished with code: 0
Control utility has completed execution at: 2020-08-28T16:06:04.328
Execution time: 64 ms{noformat}
was:
CLI (control.sh) "get_master_key_name" command should display current master
key name.
Current output is the following:
{noformat}
Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
2020 Copyright(C) Apache Software Foundation
User: xtern
Time: 2020-08-28T16:06:04.264
Command [ENCRYPTION] started
Arguments: --encryption get_master_key_name --yes
Command [ENCRYPTION] finished with code: 0
Control utility has completed execution at: 2020-08-28T16:06:04.328
Execution time: 64 ms{noformat}
> CLI (control.sh) "get_master_key_name" command should display the current
> master key name.
> --
>
> Key: IGNITE-13390
> URL: https://issues.apache.org/jira/browse/IGNITE-13390
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Pavel Pereslegin
>Priority: Major
>
> CLI (control.sh) "get_master_key_name" command should display current master
> key name.
> Current output is the following:
> {noformat}
> Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
> 2020 Copyright(C) Apache Software Foundation
> User: xtern
> Time: 2020-08-28T16:06:04.264
> Command [ENCRYPTION] started
> Arguments: --encryption get_master_key_name --yes
>
> Command [ENCRYPTION] finished with code: 0
> Control utility has completed execution at: 2020-08-28T16:06:04.328
> Execution time: 64 ms{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13390) CLI (control.sh) "get_master_key_name" command should display the current master key name.
[
https://issues.apache.org/jira/browse/IGNITE-13390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-13390:
--
Affects Version/s: 2.9
> CLI (control.sh) "get_master_key_name" command should display the current
> master key name.
> --
>
> Key: IGNITE-13390
> URL: https://issues.apache.org/jira/browse/IGNITE-13390
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.9
>Reporter: Pavel Pereslegin
>Priority: Major
>
> CLI (control.sh) "get_master_key_name" command should display current master
> key name.
> Current output is the following:
> {noformat}
> Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
> 2020 Copyright(C) Apache Software Foundation
> User: xtern
> Time: 2020-08-28T16:06:04.264
> Command [ENCRYPTION] started
> Arguments: --encryption get_master_key_name --yes
>
> Command [ENCRYPTION] finished with code: 0
> Control utility has completed execution at: 2020-08-28T16:06:04.328
> Execution time: 64 ms{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-11974) infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress ...
[
https://issues.apache.org/jira/browse/IGNITE-11974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186537#comment-17186537
]
Henrique edited comment on IGNITE-11974 at 8/28/20, 1:22 PM:
-
Hi [~kamyshnikov], thanks for the reply.
This is unfortunate indeed, we are using Ignite 2.8.0, and on this version we
can eventually see this issue impacting our cluster. It is very disastrous
since the whole cluster starts to behave a lot slower, increasing our latency,
which is the key point of using Ignite for us.
I think I'll try 2.7.6 and see how it goes, maybe it is something that was
introduced later after the updates.
was (Author: arroyo):
This is unfortunate indeed, we are using Ignite 2.8.0, and on this version we
can eventually see this issue impacting our cluster. It is very disastrous
since the whole cluster starts to behave a lot slower, increasing our latency,
which is the key point of using Ignite for us.
I think I'll try 2.7.6 and see how it goes, maybe it is something that was
introduced later after the updates.
> infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress
> ...
>
>
> Key: IGNITE-11974
> URL: https://issues.apache.org/jira/browse/IGNITE-11974
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Igor Kamyshnikov
>Priority: Blocker
> Attachments: image-2019-07-10-16-07-37-185.png,
> server-node-restarts-1.png
>
>
> Note: RCA was not done:
> Sometimes ignite server nodes fall into infinite loop and consume 100% cpu:
> {noformat}
> "sys-#260008" #260285 prio=5 os_prio=0 tid=0x7fabb020a800 nid=0x1e850
> runnable [0x7fab26fef000]
>java.lang.Thread.State: RUNNABLE
> at
> java.util.concurrent.ConcurrentHashMap$Traverser.advance(ConcurrentHashMap.java:3339)
> at
> java.util.concurrent.ConcurrentHashMap$ValueIterator.next(ConcurrentHashMap.java:3439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:84)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:73)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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)
>Locked ownable synchronizers:
> - <0x000649b9cba0> (a
> java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> the following appears in logs each 2 minutes:
> {noformat}
> INFO 2019-07-08 12:21:45.081 (1562581305081) [sys-#98168]
> [GridDhtPartitionsEvictor] > Eviction in progress
> [grp=CUSTPRODINVOICEDISCUSAGE, remainingCnt=102]
> {noformat}
> remainingCnt remains the same once it reached 102 (the very first line in the
> logs was with value equal to 101).
> Some other facts:
> we have a heapdump taken for *topVer = 900* . the problem appeared after
> *topVer = 790*, but it looks like it was silently waiting from *topVer = 641*
> (about 24 hours back).
> There were 259 topology changes between 900 and 641.
> All 102 GridDhtLocalPartitions can be found in the heapdump:
> {noformat}
> select * from
> "org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition"
> t where delayedRenting = true
> {noformat}
> They all have status = 65537 , which means (according to
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition#state):
> reservations(65537) = 1
> getPartState(65537) = OWNING
> There are also 26968 instances of
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$70,
> that are created by
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#checkEvictions
> method.
> 26418 of 26968 refer to AtomicInteger instance with value = 102:
> 26418/102 = 259 = 900 - 641 (see topology info above).
> The key thing seen from the heapdump is that topVer = 641 or topVer = 642 was
> the last topology where these 102 partitions were assigned to the current
> ignite server node.
> {noformat}
> select
> t.this
> ,t.this['clientEvtChange'] as clientEvtChange
> ,t.this['topVer.topVer'] as topVer
>
> ,t.this['assignment.elementData'][555]['elementData'][0]['hostNames.elementData'][0]
> as primary_part
>
>
[jira] [Commented] (IGNITE-11974) infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress ...
[
https://issues.apache.org/jira/browse/IGNITE-11974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186537#comment-17186537
]
Henrique commented on IGNITE-11974:
---
This is unfortunate indeed, we are using Ignite 2.8.0, and on this version we
can eventually see this issue impacting our cluster. It is very disastrous
since the whole cluster starts to behave a lot slower, increasing our latency,
which is the key point of using Ignite for us.
I think I'll try 2.7.6 and see how it goes, maybe it is something that was
introduced later after the updates.
> infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress
> ...
>
>
> Key: IGNITE-11974
> URL: https://issues.apache.org/jira/browse/IGNITE-11974
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Igor Kamyshnikov
>Priority: Blocker
> Attachments: image-2019-07-10-16-07-37-185.png,
> server-node-restarts-1.png
>
>
> Note: RCA was not done:
> Sometimes ignite server nodes fall into infinite loop and consume 100% cpu:
> {noformat}
> "sys-#260008" #260285 prio=5 os_prio=0 tid=0x7fabb020a800 nid=0x1e850
> runnable [0x7fab26fef000]
>java.lang.Thread.State: RUNNABLE
> at
> java.util.concurrent.ConcurrentHashMap$Traverser.advance(ConcurrentHashMap.java:3339)
> at
> java.util.concurrent.ConcurrentHashMap$ValueIterator.next(ConcurrentHashMap.java:3439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:84)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:73)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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)
>Locked ownable synchronizers:
> - <0x000649b9cba0> (a
> java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> the following appears in logs each 2 minutes:
> {noformat}
> INFO 2019-07-08 12:21:45.081 (1562581305081) [sys-#98168]
> [GridDhtPartitionsEvictor] > Eviction in progress
> [grp=CUSTPRODINVOICEDISCUSAGE, remainingCnt=102]
> {noformat}
> remainingCnt remains the same once it reached 102 (the very first line in the
> logs was with value equal to 101).
> Some other facts:
> we have a heapdump taken for *topVer = 900* . the problem appeared after
> *topVer = 790*, but it looks like it was silently waiting from *topVer = 641*
> (about 24 hours back).
> There were 259 topology changes between 900 and 641.
> All 102 GridDhtLocalPartitions can be found in the heapdump:
> {noformat}
> select * from
> "org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition"
> t where delayedRenting = true
> {noformat}
> They all have status = 65537 , which means (according to
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition#state):
> reservations(65537) = 1
> getPartState(65537) = OWNING
> There are also 26968 instances of
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$70,
> that are created by
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#checkEvictions
> method.
> 26418 of 26968 refer to AtomicInteger instance with value = 102:
> 26418/102 = 259 = 900 - 641 (see topology info above).
> The key thing seen from the heapdump is that topVer = 641 or topVer = 642 was
> the last topology where these 102 partitions were assigned to the current
> ignite server node.
> {noformat}
> select
> t.this
> ,t.this['clientEvtChange'] as clientEvtChange
> ,t.this['topVer.topVer'] as topVer
>
> ,t.this['assignment.elementData'][555]['elementData'][0]['hostNames.elementData'][0]
> as primary_part
>
> ,t.this['assignment.elementData'][555]['elementData'][1]['hostNames.elementData'][0]
> as secondary_part
> from org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
> t where length(t.this['assignment.elementData']) = 1024
> order by topVer
> {noformat}
> !image-2019-07-10-16-07-37-185.png!
> The connection of a client node at topVer = 790 somehow triggered the
> GridDhtPartitionsEvictor loop to execute.
> Summary:
> 1) it is seen that 102 partitions has one reservation and OWNING
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186536#comment-17186536 ] Stanilovsky Evgeny commented on IGNITE-13308: - [~isapego] thanks for review, i fix all you mentioned, all tests are passed. > C++: Thin client transactions > - > > Key: IGNITE-13308 > URL: https://issues.apache.org/jira/browse/IGNITE-13308 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: C++, iep-34 > Fix For: 2.10 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13382) DurableBackgroundTask can abandon incomplete task
[ https://issues.apache.org/jira/browse/IGNITE-13382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Makedonskaya updated IGNITE-13382: Reviewer: (was: Anton Kalashnikov) > DurableBackgroundTask can abandon incomplete task > - > > Key: IGNITE-13382 > URL: https://issues.apache.org/jira/browse/IGNITE-13382 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > DurableBackgroundTasks are tracked using metastorage, there's a specific > marker for every task, and it is removed right after the task is complete. > But there's a race between checkpointer and metastorage. End-marker removal > is a logical operation, while task itself is mostly physical (at least the > existing one). So, following scenario is possible: > * Checkpoint occurs in the middle of the task; > * Task is completed before the next checkpoint; > * Metastorage record is deleted, this fact if written to WAL and synced to > the storage; > * Node failed; > * Recovery process applies deletion from metastorage, this means that > DurableBackgroundTasks info is lost; > * But part of the index is still present in the storage. > I think that we should remove markers from metastorage only after the next > checkpoint, this will 100% save us from such situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[
https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186486#comment-17186486
]
Ignite TC Bot commented on IGNITE-13308:
{panel:title=Branch: [pull/8118/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Win x64 / Debug){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=5569115]]
{panel}
{panel:title=Branch: [pull/8118/head] Base: [master] : New Tests
(888)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
879|https://ci.ignite.apache.org/viewLog.html?buildId=5569115]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr -
PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToLong - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToTiny - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText
- PASSED{color}
... and 868 new tests
{color:#8b}Platform C++ CMake (Linux){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5569121]]
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestTxOps -
PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestCacheOpsWithTx -
PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestTxWithLabel -
PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5569120]]
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestTxOps -
PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestCacheOpsWithTx -
PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestTxWithLabel -
PASSED{color}
{color:#8b}Platform C++ (Win x64 / Release){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5569116]]
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestTxOps -
PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestCacheOpsWithTx -
PASSED{color}
* {color:#013220}IgniteThinClientTest: IgniteTxTestSuite: TestTxWithLabel -
PASSED{color}
{panel}
[TeamCity *- Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5569122buildTypeId=IgniteTests24Java8_RunCpp]
> C++: Thin client transactions
> -
>
> Key: IGNITE-13308
> URL: https://issues.apache.org/jira/browse/IGNITE-13308
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: C++, iep-34
> Fix For: 2.10
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13380) Output IgniteSystemProperties via ignite.sh
[
https://issues.apache.org/jira/browse/IGNITE-13380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186474#comment-17186474
]
Amelchev Nikita commented on IGNITE-13380:
--
[~nizhikov], Hi.
I have prepared PR. Could you take a look, please?
> Output IgniteSystemProperties via ignite.sh
> ---
>
> Key: IGNITE-13380
> URL: https://issues.apache.org/jira/browse/IGNITE-13380
> Project: Ignite
> Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide the ability output of all available Ignite properties
> ({{IgniteSystemProperties}}) with its descriptions in the {{ignite.sh}}
> command. For example,
> {noformat}
> ignite.sh -systemProps
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13320) TDE - Phase-3. CLI management
[ https://issues.apache.org/jira/browse/IGNITE-13320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-13320: -- Description: Provide the ability to manage the process of key rotation (and cache re-encryption) through the command line. - Launch key rotation (distributed) - View keys (id, hash) for cache group - View re-encryption status for cache group. - Launch re-encryption - Stop re-encryption was: Provide the ability to manage the process of key rotation (and cache re-encryption) through the command line. - Launch key rotation (distributed) Local - Launch re-encryption - Stop re-encryption - View keys (id, hash) for cache group > TDE - Phase-3. CLI management > - > > Key: IGNITE-13320 > URL: https://issues.apache.org/jira/browse/IGNITE-13320 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: IEP-18, tde-phase-3 > > Provide the ability to manage the process of key rotation (and cache > re-encryption) through the command line. > - Launch key rotation (distributed) > - View keys (id, hash) for cache group > - View re-encryption status for cache group. > - Launch re-encryption > - Stop re-encryption -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13383) Java thin client improvements: channel reconnect and redundant concurrency structures replacement.
[
https://issues.apache.org/jira/browse/IGNITE-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186341#comment-17186341
]
Stanilovsky Evgeny commented on IGNITE-13383:
-
1. My position - no need to defense from users buggy code on server side,
performance - possible i agree here, but without bench this still unclear.
2. All thin clients need to implement the same.
> Moreover, you introduce memory leak again on the server-side (current
> connection context has reference to the ses - I nullify it, thanks for point.
> and next started transaction will intersect old transactions by id - tests
> are green, i double check them.
> Java thin client improvements: channel reconnect and redundant concurrency
> structures replacement.
> --
>
> Key: IGNITE-13383
> URL: https://issues.apache.org/jira/browse/IGNITE-13383
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that {code:java}ConcurrentHashMap{code} and
> {code:java}AtomicLong{code} are redundant in java thin client code, yes i fix
> tests a bit but i can`t see any contradictions with thick client behavior
> here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13383) Java thin client improvements: channel reconnect and redundant concurrency structures replacement.
[
https://issues.apache.org/jira/browse/IGNITE-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186328#comment-17186328
]
Aleksey Plekhanov commented on IGNITE-13383:
[~zstan], I don't think this ticket should be fixed at all. Both "improvements"
didn't look like improvements.
1. Concurrent structures were introduced for a reason, they prevent memory
leaks (https://github.com/apache/ignite/pull/6734#pullrequestreview-278104733).
Their performance worth nothing compared to other logic (perhaps micropercents
of total request time). Why should we sacrifice correctness for this?
2. What's wrong with the channel check on the client's side? It's a "fail-fast"
approach. With your change client will get the same result, but should send
request to the server to get an error. Moreover, you introduce memory leak
again on the server-side (current connection context has reference to the
{{ses}}, which has reference to the previous connection context, which has
reference to the {{ses}} and so on). And it doesn't protect from txId
intersection. For example, you have 2 clients, both connects to the server,
initial txId for first will be 0, initial txId for the second will be 1, then
first creates three transactions (txId=1, txId=2, txId=3) and lost connection,
after reconnect initial txId will be 2, and next started transaction will
intersect old transactions by id. I think simple and reasonable check on
client-side is better than complex, unclear, and error-prone logic on
server-side.
> Java thin client improvements: channel reconnect and redundant concurrency
> structures replacement.
> --
>
> Key: IGNITE-13383
> URL: https://issues.apache.org/jira/browse/IGNITE-13383
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that {code:java}ConcurrentHashMap{code} and
> {code:java}AtomicLong{code} are redundant in java thin client code, yes i fix
> tests a bit but i can`t see any contradictions with thick client behavior
> here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
