[jira] [Commented] (IGNITE-12167) Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999817#comment-16999817
]
Denis Chudov commented on IGNITE-12167:
---
[~amashenkov] could you please review my code?
> Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
> --
>
> Key: IGNITE-12167
> URL: https://issues.apache.org/jira/browse/IGNITE-12167
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should move logic for clearing custom pageHndWrapperin
> {{afterTestsStopped()}} in {{GridCommonAbstractTest}} or {{GridAbstractTest
> to ensure that we will not have problems in any tests which set custom
> wrapper}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12167) Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999814#comment-16999814
]
Ignite TC Bot commented on IGNITE-12167:
{panel:title=Branch: [pull/6962/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4851907buildTypeId=IgniteTests24Java8_RunAll]
> Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
> --
>
> Key: IGNITE-12167
> URL: https://issues.apache.org/jira/browse/IGNITE-12167
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should move logic for clearing custom pageHndWrapperin
> {{afterTestsStopped()}} in {{GridCommonAbstractTest}} or {{GridAbstractTest
> to ensure that we will not have problems in any tests which set custom
> wrapper}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12465) Extend test coverage [IGNITE-11995] control.sh if experimental command disabled - don't show help for experemental commands
[
https://issues.apache.org/jira/browse/IGNITE-12465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999784#comment-16999784
]
Ignite TC Bot commented on IGNITE-12465:
{panel:title=Branch: [pull/7158/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4850211buildTypeId=IgniteTests24Java8_RunAll]
> Extend test coverage [IGNITE-11995] control.sh if experimental command
> disabled - don't show help for experemental commands
> ---
>
> Key: IGNITE-12465
> URL: https://issues.apache.org/jira/browse/IGNITE-12465
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Extend test coverage for IGNITE-11995
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[ https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-9913: - Fix Version/s: 2.8 > Prevent data updates blocking in case of backup BLT server node leave > - > > Key: IGNITE-9913 > URL: https://issues.apache.org/jira/browse/IGNITE-9913 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.8 > > Attachments: 9913_yardstick.png, master_yardstick.png > > Time Spent: 10h 20m > Remaining Estimate: 0h > > Ignite cluster performs distributed partition map exchange when any server > node leaves or joins the topology. > Distributed PME blocks all updates and may take a long time. If all > partitions are assigned according to the baseline topology and server node > leaves, there's no actual need to perform distributed PME: every cluster node > is able to recalculate new affinity assigments and partition states locally. > If we'll implement such lightweight PME and handle mapping and lock requests > on new topology version correctly, updates won't be stopped (except updates > of partitions that lost their primary copy). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12457) Cache 6 test suite fails with exit code 137
[ https://issues.apache.org/jira/browse/IGNITE-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999757#comment-16999757 ] Ivan Pavlukhin commented on IGNITE-12457: - TC run of Cache 6 for PR https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7142%2Fhead=overview Still unstable but looks better than in master. > Cache 6 test suite fails with exit code 137 > --- > > Key: IGNITE-12457 > URL: https://issues.apache.org/jira/browse/IGNITE-12457 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > Recently Cache 6 test suite started failing with uplesantly with exit code > 137. Whole suite fails with no details about passed and failed tests. > IgniteCache150ClientsTest seems to be a root cause. > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E=overview -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12467) Python Thin Client Support for Transactions
[ https://issues.apache.org/jira/browse/IGNITE-12467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999741#comment-16999741 ] Ivan Pavlukhin commented on IGNITE-12467: - [~rje], yes, currently only Java thin client transactions support was implemented (mentioned IGNITE-9410). Perhaps, [~isapego] knows more about other platforms. > Python Thin Client Support for Transactions > --- > > Key: IGNITE-12467 > URL: https://issues.apache.org/jira/browse/IGNITE-12467 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.7.6 >Reporter: Robert Emanuele >Priority: Major > > I see that https://issues.apache.org/jira/browse/IGNITE-9410 is marked as > resolved but I have not seen the changes in the python thin client, pyignite. > Am I looking in the wrong place > ([https://github.com/apache/ignite/tree/master/modules/platforms/python]), or > is there more work to do? > If there is more work, are there changes that I can port? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999670#comment-16999670 ] Ryabov Dmitrii commented on IGNITE-12049: - # How? I create `ctx`, put it into writer and it should be used in `writeMap()` # Some troubles with Cache 6 suite, which is failed on the [master|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=] too. # Agree. > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Time Spent: 1.5h > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12468) ClassCastException on thinClient in Apache Ignite
LEE PYUNG BEOM created IGNITE-12468:
---
Summary: ClassCastException on thinClient in Apache Ignite
Key: IGNITE-12468
URL: https://issues.apache.org/jira/browse/IGNITE-12468
Project: Ignite
Issue Type: Bug
Components: clients
Affects Versions: 2.6
Reporter: LEE PYUNG BEOM
{code:java}
ClientConfiguration cfg = new
ClientConfiguration().setAddresses("127.0.0.1:10800");
try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
System.out.println(">>> Thin client put-get example started.");
final String CACHE_NAME = "put-get-example";
ClientCache cache =
igniteClient.getOrCreateCache(CACHE_NAME);
Person p = new Person();
//put
HashMap hm = new HashMap();
hm.put(1, p);
cache.put(1, hm);
//get
HashMap map = (HashMap)cache.get(1);
Person p2 = map.get(1);
System.out.format(">>> Loaded [%s] from the cache.\n",p2);
}
catch (ClientException e) {
System.err.println(e.getMessage());
e.printStackTrace();
}
catch (Exception e) {
System.err.format("Unexpected failure: %s\n", e);
e.printStackTrace();
}
{code}
I use the thin client of apache-ignite.
I Create a hashmap and put the Person
class(org.apache.ignite.examples.model.Person) object into it.
And when I take it out of the hashmap, I get the following exceptions:
{code:java}
> java.lang.ClassCastException:
> org.apache.enite.internal.binary.BinaryObjectImpl cannot be cast to
> org.apache.engite.examples.model.Person.
{code}
An exception is given in the code below.
{code:java}
Person p2 = map.get(1);
{code}
However, there is no exception if I modify the code as follows:
{code:java}
BinaryObject bo = (BinaryObject) map.get(1);
Person p2 = bo.deserialize();
{code}
I don't think that's necessary. Is there another solution?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12467) Python Thin Client Support for Transactions
[ https://issues.apache.org/jira/browse/IGNITE-12467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Emanuele updated IGNITE-12467: - Summary: Python Thin Client Support for Transactions (was: Thing Client Support for Transactions) > Python Thin Client Support for Transactions > --- > > Key: IGNITE-12467 > URL: https://issues.apache.org/jira/browse/IGNITE-12467 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.7.6 >Reporter: Robert Emanuele >Priority: Major > > I see that https://issues.apache.org/jira/browse/IGNITE-9410 is marked as > resolved but I have not seen the changes in the python thin client, pyignite. > Am I looking in the wrong place > ([https://github.com/apache/ignite/tree/master/modules/platforms/python]), or > is there more work to do? > If there is more work, are there changes that I can port? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12467) Thing Client Support for Transactions
Robert Emanuele created IGNITE-12467: Summary: Thing Client Support for Transactions Key: IGNITE-12467 URL: https://issues.apache.org/jira/browse/IGNITE-12467 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.7.6 Reporter: Robert Emanuele I see that https://issues.apache.org/jira/browse/IGNITE-9410 is marked as resolved but I have not seen the changes in the python thin client, pyignite. Am I looking in the wrong place ([https://github.com/apache/ignite/tree/master/modules/platforms/python]), or is there more work to do? If there is more work, are there changes that I can port? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8775) Memory leak in ignite-cassandra module while using RoundRobinPolicy LoadBalancingPolicy
[
https://issues.apache.org/jira/browse/IGNITE-8775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999427#comment-16999427
]
Stefan Miklosovic commented on IGNITE-8775:
---
[~irudyak] [~kotamrajuyashasvi] I check this one and it seems to me that the
problem is not existing "out of the box".
If there is not lbp used in DataSource, Cassandra Driver, by default, uses this
when "withLoadBalancingPolicy" is used on it:
{quote}Configures the load balancing policy to use for the new cluster.
If no load balancing policy is set through this method,
Policies.defaultLoadBalancingPolicy() will be used instead
{quote}
Investigating further, "Policies.defaultLoadBalancingPolicy()" uses:
{quote}
The default load balancing policy is DCAwareRoundRobinPolicy with token
awareness (so new TokenAwarePolicy(new DCAwareRoundRobinPolicy())).
Note that this policy shuffles the replicas when token awareness is used, see
TokenAwarePolicy.TokenAwarePolicy(LoadBalancingPolicy, boolean) for an
explanation of the tradeoffs
{quote}
If you check the implementation of that policy and its "init" method, there is
not any case when we add "more" hosts. It is added only in case it does not
exist.
This problem does exist in the implementation of "RoundRobinPolicy" in its
init, that is true. But the only place you are using this policy is in tests.
Hence, if one uses his own RoundBalancingPolicy (as it seems to be the case, I
wonder why it is so because you should use DCAwareRoundRobinPolicy over
"primitive" RoundRobinPolicy whenever it is needed), it is up to the user to
implement own policy which does not have this problem, in this particular case,
by extending RoundRobinPolicy and overriding its init() method and all other
methods which are using private fields in the old policy (as we would just
re-declared them in our custom policy).
> Memory leak in ignite-cassandra module while using RoundRobinPolicy
> LoadBalancingPolicy
> ---
>
> Key: IGNITE-8775
> URL: https://issues.apache.org/jira/browse/IGNITE-8775
> Project: Ignite
> Issue Type: Bug
> Components: cassandra
>Reporter: Yashasvi Kotamraju
>Assignee: Igor Rudyak
>Priority: Major
>
> OutOfMemory Exception is observed when encountered with the issue
> IGNITE-8354. Though the issue is solved, preventing OOM by preventing
> unnecessary refresh of Cassandra session refresh, there seems to be a memory
> leak in ignite-cassandra module while using RoundRobinPolicy
> LoadBalancingPolicy while refreshing cassandra session. which seems to be the
> root cause of OOM.
> In org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.java
> when refresh() method is invoked to handle Exceptions, new Cluster is build
> with same LoadBalancingPolicy Object. We are using RoundRobinPolicy so same
> RoundRobinPolicy object would be used while building Cluster when refresh()
> is invoked. In RoundRobinPolicy there is a CopyOnWriteArrayList
> liveHosts. When ever init(Cluster cluster, Collection hosts) is called
> on RoundRobinPolicy it calls liveHosts.addAll(hosts) adding all the Host
> Object Collection to liveHosts.
> When ever Cluster is build during refresh() the Host Collection are added
> during init call,
> again to the liveHosts of the same RoundRobinPolicy .Thus same Hosts are
> added again to liveHosts for every refresh() and the size would grow
> indefinitely after many refresh() calls causing OOM. Even in the heap dump
> post OOM we found huge number of Objects in liveHosts of RoundRobinPolicy
> Object.
> Some possible solutions would be
> 1. To use new LoadBalancingPolicy object while building new Cluster during
> refresh().
> 2. Somehow clear Objects in liveHosts during refresh().
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-5270) Cassandra store should support binary objects with POJO strategy
[ https://issues.apache.org/jira/browse/IGNITE-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999365#comment-16999365 ] Stefan Miklosovic commented on IGNITE-5270: --- [~vkulichenko] [~irudyak] I would love to see this in action. Manual deployment is rather annoying. If you give me some hints how this might work, I will gladly help. > Cassandra store should support binary objects with POJO strategy > > > Key: IGNITE-5270 > URL: https://issues.apache.org/jira/browse/IGNITE-5270 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Affects Versions: 2.0 >Reporter: Valentin Kulichenko >Assignee: Igor Rudyak >Priority: Major > > Currently Cassandra store requires to have POJO classes on server nodes when > POJO strategy is used. We should improve it and allow to support binary > objects directly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-4555) Make KeyValuePersistenceSettings configuration class Spring compatible
[
https://issues.apache.org/jira/browse/IGNITE-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999361#comment-16999361
]
Stefan Miklosovic commented on IGNITE-4555:
---
[~irudyak] is this still an issue? As of now (Ignite 2.7 / 2.8), I can clearly
create this in the code by passing persistence xml String into its constructor.
Can not be this just closed?
> Make KeyValuePersistenceSettings configuration class Spring compatible
> --
>
> Key: IGNITE-4555
> URL: https://issues.apache.org/jira/browse/IGNITE-4555
> Project: Ignite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Igor Rudyak
>Priority: Major
>
> Currently {{KeyValuePersistenceSettings}} uses a special XML format which is
> OK, but limits usability in following cases:
> * Spring is used for all other components of Ignite.
> * User wants to start dynamic cache and does not know persistence
> configuration in advance.
> We should add getter and setter methods to {{KeyValuePersistenceSettings}}
> and make it possible to create via Spring or directly in code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-3588) Cassandra store should use batching in writeAll and deleteAll methods
[
https://issues.apache.org/jira/browse/IGNITE-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999355#comment-16999355
]
Stefan Miklosovic commented on IGNITE-3588:
---
I agree with [~irudyak] here, can not this be just closed?
> Cassandra store should use batching in writeAll and deleteAll methods
> -
>
> Key: IGNITE-3588
> URL: https://issues.apache.org/jira/browse/IGNITE-3588
> Project: Ignite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Igor Rudyak
>Priority: Major
>
> In current implementation Cassandra store executes all updates one by one
> when {{writeAll}} or {{deleteAll}} method is called.
> We should add an option to use {{BatchStatement}} instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12167) Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999323#comment-16999323
]
Ignite TC Bot commented on IGNITE-12167:
{panel:title=Branch: [pull/6962/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=4851883]]
* IgniteBinaryCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.testReadWriteSafeWithPersistence[TRANSACTIONAL]
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite: SqlViewExporterSpiTest.testSchemas - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4851878]]
* dll: ClientConnectionTest.TestServerConnectionAborted - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Client Nodes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4851798]]
* IgniteClientReconnectTestSuite:
IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4851907buildTypeId=IgniteTests24Java8_RunAll]
> Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
> --
>
> Key: IGNITE-12167
> URL: https://issues.apache.org/jira/browse/IGNITE-12167
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should move logic for clearing custom pageHndWrapperin
> {{afterTestsStopped()}} in {{GridCommonAbstractTest}} or {{GridAbstractTest
> to ensure that we will not have problems in any tests which set custom
> wrapper}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999316#comment-16999316 ] Alexey Scherbakov commented on IGNITE-12049: [~SomeFire] Overall looks good. My questions: 1. Can you explain how this works for you: BinaryContext ctx = new BinaryContext(BinaryCachingMetadataHandler.create(), new IgniteConfiguration(), null); BinaryWriterExImpl writer = new BinaryWriterExImpl(ctx, new BinaryHeapOutputStream(32), null, null); ... writer.writeMap(..) For me this throws an exception because a marshaller context is null. 2. The TC bot visa is missing. 3. Shouldn't we rename userAttributes to userAttributesFactory ? > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Time Spent: 1.5h > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12415) .NET: Thin client does not connect to old server nodes
[
https://issues.apache.org/jira/browse/IGNITE-12415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-12415.
-
Resolution: Fixed
> .NET: Thin client does not connect to old server nodes
> --
>
> Key: IGNITE-12415
> URL: https://issues.apache.org/jira/browse/IGNITE-12415
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.8
>
>
> Exception when trying to connect .NET Thin Client from current master
> (https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20191203) to the
> 2.7.6 server node:
> {code}
> Unhandled exception. Apache.Ignite.Core.Client.IgniteClientException: Client
> handshake failed: 'Unsupported version.'. Client version: 1.6.0. Server
> version: 1.2.0
>at
> Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(IgniteClientConfiguration
> clientConfiguration, ClientProtocolVersion version)
>at
> Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration
> clientConfiguration, EndPoint endPoint, String host, Nullable`1 version,
> Action`1 topVerCallback)
>at Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.Connect()
>at
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket..ctor(IgniteClientConfiguration
> config, Marshaller marsh)
>at
> Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration
> clientConfiguration)
>at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration
> clientConfiguration)
>at ConsoleApp2.Program.Main(String[] args) in
> /home/pavel/RiderProjects/ConsoleApp2/ConsoleApp2/Program.cs:line 14
> [StatusCode=Fail]
> {code}
> This is caused by buggy version handling logic in Handshake method. Otherwise
> we support any older protocol version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12415) .NET: Thin client does not connect to old server nodes
[
https://issues.apache.org/jira/browse/IGNITE-12415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999308#comment-16999308
]
Pavel Tupitsyn commented on IGNITE-12415:
-
Fixed as part of IGNITE-12387 (compatibility tests added there too).
> .NET: Thin client does not connect to old server nodes
> --
>
> Key: IGNITE-12415
> URL: https://issues.apache.org/jira/browse/IGNITE-12415
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.8
>
>
> Exception when trying to connect .NET Thin Client from current master
> (https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20191203) to the
> 2.7.6 server node:
> {code}
> Unhandled exception. Apache.Ignite.Core.Client.IgniteClientException: Client
> handshake failed: 'Unsupported version.'. Client version: 1.6.0. Server
> version: 1.2.0
>at
> Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(IgniteClientConfiguration
> clientConfiguration, ClientProtocolVersion version)
>at
> Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration
> clientConfiguration, EndPoint endPoint, String host, Nullable`1 version,
> Action`1 topVerCallback)
>at Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.Connect()
>at
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket..ctor(IgniteClientConfiguration
> config, Marshaller marsh)
>at
> Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration
> clientConfiguration)
>at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration
> clientConfiguration)
>at ConsoleApp2.Program.Main(String[] args) in
> /home/pavel/RiderProjects/ConsoleApp2/ConsoleApp2/Program.cs:line 14
> [StatusCode=Fail]
> {code}
> This is caused by buggy version handling logic in Handshake method. Otherwise
> we support any older protocol version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11320) JDBC Thin: add support for individual reconnect in case of best effort affinity mode.
[ https://issues.apache.org/jira/browse/IGNITE-11320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999288#comment-16999288 ] Taras Ledkov commented on IGNITE-11320: --- [~amashenkov], the patch is OK with me. > JDBC Thin: add support for individual reconnect in case of best effort > affinity mode. > - > > Key: IGNITE-11320 > URL: https://issues.apache.org/jira/browse/IGNITE-11320 > Project: Ignite > Issue Type: Bug > Components: jdbc >Reporter: Alexander Lapin >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-23 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently in case of best effort affinity mode we either connect to all nodes > specified by user or throw SQLException. Given logic needs to be improved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12387) .NET Thin Client: Handle unsupported features on older server nodes gracefully
[ https://issues.apache.org/jira/browse/IGNITE-12387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999274#comment-16999274 ] Pavel Tupitsyn commented on IGNITE-12387: - Cherry-picked to ignite-2.8: e3744613550f9e665e54afd6991f8b2aa11f59cb > .NET Thin Client: Handle unsupported features on older server nodes gracefully > -- > > Key: IGNITE-12387 > URL: https://issues.apache.org/jira/browse/IGNITE-12387 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Right now we don't check server version before doing requests for newer > features like Affinity Awareness and Cluster API. This causes exceptions like > "Invalid re > quest op code: 5000", which are cryptic for the user. > Fix this: > * Affinity Awareness: disable it automatically if there is no server support; > log a warning to the log (add logging by adding > IgniteClientConfiguration.Logger property) > * Individual methods and features like Cluster API - throw an exception with > user-friendly explanation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12387) .NET Thin Client: Handle unsupported features on older server nodes gracefully
[ https://issues.apache.org/jira/browse/IGNITE-12387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999269#comment-16999269 ] Pavel Tupitsyn commented on IGNITE-12387: - `Platform .NET (Long Running)` project fixed (added Maven to PATH), all tests are green. Merged to master: 44075e0285f65e7276a03f98970cb0ac7c87f6d8 > .NET Thin Client: Handle unsupported features on older server nodes gracefully > -- > > Key: IGNITE-12387 > URL: https://issues.apache.org/jira/browse/IGNITE-12387 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Right now we don't check server version before doing requests for newer > features like Affinity Awareness and Cluster API. This causes exceptions like > "Invalid re > quest op code: 5000", which are cryptic for the user. > Fix this: > * Affinity Awareness: disable it automatically if there is no server support; > log a warning to the log (add logging by adding > IgniteClientConfiguration.Logger property) > * Individual methods and features like Cluster API - throw an exception with > user-friendly explanation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999197#comment-16999197 ] Kirill Tkalenko commented on IGNITE-12447: -- [~ascherbakov], I think your options are good too, but my change does not spoil the code. Let it be at the discretion of the committer. > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999177#comment-16999177 ] Alexey Scherbakov commented on IGNITE-12447: [~ktkale...@gridgain.com] Two options: 1. Long is a Number, therefore Collection accepts Long values 2. S.compact(F.viewReadOnly(tmp, Long::intValue)) > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999173#comment-16999173 ] Kirill Tkalenko commented on IGNITE-12447: -- [~ascherbakov] And if needed for a long values? > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999165#comment-16999165 ] Alexey Scherbakov commented on IGNITE-12447: [~ktkale...@gridgain.com] I do not think this change is necessary. To pass a collection of Number to the existing method do the following: S.compact(F.viewReadOnly(tmp, Number::intValue)) > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12461) Jdbc Thin: Failover connections support for JDBC thin driver.
[
https://issues.apache.org/jira/browse/IGNITE-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999122#comment-16999122
]
Ignite TC Bot commented on IGNITE-12461:
{panel:title=Branch: [pull/7154/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4848564buildTypeId=IgniteTests24Java8_RunAll]
> Jdbc Thin: Failover connections support for JDBC thin driver.
> -
>
> Key: IGNITE-12461
> URL: https://issues.apache.org/jira/browse/IGNITE-12461
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to to support failover connections for JDBC driver.
> In case user defined few connection points and server became unavailable
> during request, driver should try send the same request to another server.
> Please be aware we can do it only for idempotent requests like a SELECT
> without transaction context.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11320) JDBC Thin: add support for individual reconnect in case of best effort affinity mode.
[
https://issues.apache.org/jira/browse/IGNITE-11320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999119#comment-16999119
]
Ignite TC Bot commented on IGNITE-11320:
{panel:title=Branch: [pull/7152/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4848330buildTypeId=IgniteTests24Java8_RunAll]
> JDBC Thin: add support for individual reconnect in case of best effort
> affinity mode.
> -
>
> Key: IGNITE-11320
> URL: https://issues.apache.org/jira/browse/IGNITE-11320
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Reporter: Alexander Lapin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: iep-23
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently in case of best effort affinity mode we either connect to all nodes
> specified by user or throw SQLException. Given logic needs to be improved.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12387) .NET Thin Client: Handle unsupported features on older server nodes gracefully
[ https://issues.apache.org/jira/browse/IGNITE-12387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999117#comment-16999117 ] Igor Sapego commented on IGNITE-12387: -- [~ptupitsyn] Looks good to me. > .NET Thin Client: Handle unsupported features on older server nodes gracefully > -- > > Key: IGNITE-12387 > URL: https://issues.apache.org/jira/browse/IGNITE-12387 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Right now we don't check server version before doing requests for newer > features like Affinity Awareness and Cluster API. This causes exceptions like > "Invalid re > quest op code: 5000", which are cryptic for the user. > Fix this: > * Affinity Awareness: disable it automatically if there is no server support; > log a warning to the log (add logging by adding > IgniteClientConfiguration.Logger property) > * Individual methods and features like Cluster API - throw an exception with > user-friendly explanation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12459) Searching checkpoint record in WAL doesn't work with segment compaction
[ https://issues.apache.org/jira/browse/IGNITE-12459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999112#comment-16999112 ] Sergey Chugunov commented on IGNITE-12459: -- [~akalashnikov], Change looks good to me, as we have all green tests for it, lets merge it to master branch. Thank you! > Searching checkpoint record in WAL doesn't work with segment compaction > --- > > Key: IGNITE-12459 > URL: https://issues.apache.org/jira/browse/IGNITE-12459 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > During iteration over WAL we have two invariants about > result(Tuple): > * WALPointer equal to WALRecord.position() when segment is uncompacted > * WALPointer not equal to WALRecord.position() when the segment is compacted > Unfortunately, the second variant is broken in > FileWriteAheadLogManager#read(WALPointer ptr) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12459) Searching checkpoint record in WAL doesn't work with segment compaction
[ https://issues.apache.org/jira/browse/IGNITE-12459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-12459: - Fix Version/s: 2.9 > Searching checkpoint record in WAL doesn't work with segment compaction > --- > > Key: IGNITE-12459 > URL: https://issues.apache.org/jira/browse/IGNITE-12459 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > During iteration over WAL we have two invariants about > result(Tuple): > * WALPointer equal to WALRecord.position() when segment is uncompacted > * WALPointer not equal to WALRecord.position() when the segment is compacted > Unfortunately, the second variant is broken in > FileWriteAheadLogManager#read(WALPointer ptr) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12459) Searching checkpoint record in WAL doesn't work with segment compaction
[
https://issues.apache.org/jira/browse/IGNITE-12459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999075#comment-16999075
]
Ignite TC Bot commented on IGNITE-12459:
{panel:title=Branch: [pull/7148/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4847125buildTypeId=IgniteTests24Java8_RunAll]
> Searching checkpoint record in WAL doesn't work with segment compaction
> ---
>
> Key: IGNITE-12459
> URL: https://issues.apache.org/jira/browse/IGNITE-12459
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During iteration over WAL we have two invariants about
> result(Tuple):
> * WALPointer equal to WALRecord.position() when segment is uncompacted
> * WALPointer not equal to WALRecord.position() when the segment is compacted
> Unfortunately, the second variant is broken in
> FileWriteAheadLogManager#read(WALPointer ptr)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12387) .NET Thin Client: Handle unsupported features on older server nodes gracefully
[ https://issues.apache.org/jira/browse/IGNITE-12387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999067#comment-16999067 ] Alexandr Shapkin commented on IGNITE-12387: --- [~ptupitsyn] looks good to me, thanks! > .NET Thin Client: Handle unsupported features on older server nodes gracefully > -- > > Key: IGNITE-12387 > URL: https://issues.apache.org/jira/browse/IGNITE-12387 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Right now we don't check server version before doing requests for newer > features like Affinity Awareness and Cluster API. This causes exceptions like > "Invalid re > quest op code: 5000", which are cryptic for the user. > Fix this: > * Affinity Awareness: disable it automatically if there is no server support; > log a warning to the log (add logging by adding > IgniteClientConfiguration.Logger property) > * Individual methods and features like Cluster API - throw an exception with > user-friendly explanation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12456) Cluster Data Store grid gets Corrupted for Load test
[ https://issues.apache.org/jira/browse/IGNITE-12456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravi Kumar Powli updated IGNITE-12456: -- Description: We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery.we are into AWS cloud environment with Microservice model with 8 microservices.we are using Ignite for session data store.While performing load test we are facing data grid issues if the number of clients reached 40 , Once data grid got corrupted we will lost the session store data and Application will not respond due to session data also corrupted and all the instances will auto scaled down to initial size 8.We need to restart Apache Ignite to make the Application up.Please find the attached Apache Ignite Configuration for your reference. This is Impacting the scalability for the micro-services. It is very evident that the current state based architecture will not scale beyond a certain TPS and the state store, especially Ignite becomes the single point of failure, stalling the full Micro-service cluster. Apache Ignite Version : 2.7.0 07:24:46,678][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][G] Blocked system-critical thread has been detected. This can lead to cluster-wide undefined behaviour [threadName=sys-stripe-5, blockedFor=21s]07:24:46,678][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][G] Blocked system-critical thread has been detected. This can lead to cluster-wide undefined behaviour [threadName=sys-stripe-5, blockedFor=21s][07:24:46,680][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][] Critical system error detected. Will be handled accordingly to configured handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker [name=sys-stripe-5, igniteInstanceName=DataStoreIgniteCache, finished=false, heartbeatTs=1575271465499]]]class org.apache.ignite.IgniteException: GridWorker [name=sys-stripe-5, igniteInstanceName=DataStoreIgniteCache, finished=false, heartbeatTs=1575271465499] at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826) at org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233) at org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297) at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2663) at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7181) at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119) at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)[07:24:52,692][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][G] Blocked system-critical thread has been detected. This can lead to cluster-wide undefined behaviour [threadName=ttl-cleanup-worker, blockedFor=27s][07:24:52,692][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][] Critical system error detected. Will be handled accordingly to configured handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker [name=ttl-cleanup-worker, igniteInstanceName=DataStoreIgniteCache, finished=false, heartbeatTs=1575271465044]]]class org.apache.ignite.IgniteException: GridWorker [name=ttl-cleanup-worker, igniteInstanceName=DataStoreIgniteCache, finished=false, heartbeatTs=1575271465044] at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826) at org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233) at org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297) at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2663) at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7181) at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119) at
[jira] [Commented] (IGNITE-12463) Inconsistancy of checkpoint progress future with its state
[
https://issues.apache.org/jira/browse/IGNITE-12463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999005#comment-16999005
]
Ignite TC Bot commented on IGNITE-12463:
{panel:title=Branch: [pull/7153/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4848448buildTypeId=IgniteTests24Java8_RunAll]
> Inconsistancy of checkpoint progress future with its state
> ---
>
> Key: IGNITE-12463
> URL: https://issues.apache.org/jira/browse/IGNITE-12463
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It needs to reorganize checkpoint futures(start, finish) so they should be
> matched to states.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12460) Cluster fails to find the node by consistent ID
[
https://issues.apache.org/jira/browse/IGNITE-12460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998998#comment-16998998
]
Ignite TC Bot commented on IGNITE-12460:
{panel:title=Branch: [pull/7151/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4848079buildTypeId=IgniteTests24Java8_RunAll]
> Cluster fails to find the node by consistent ID
> ---
>
> Key: IGNITE-12460
> URL: https://issues.apache.org/jira/browse/IGNITE-12460
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps to reproduce 1:
> * Start cluster of three nodes
> * Navigate to Baseline screen
> * Start one more node
> * Include it into baseline
> * Hit 'Save' btn
> Expected:
> * Success alert, node enters baseline
> Actual:
> * Exception is thrown and is displayed
> Steps to reproduce 2:
> # Start topology with 2 nodes.
> # Activate cluster.
> # Start third node.
> # Stop second node.
> # Try to add third node to baseline in Web console.
> Also reproduced with *control.sh --baseline set* command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12442) Fix unnecessary synchronized on PagesCache#add.
[ https://issues.apache.org/jira/browse/IGNITE-12442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998997#comment-16998997 ] Stanilovsky Evgeny commented on IGNITE-12442: - fixed, rerun TC. > Fix unnecessary synchronized on PagesCache#add. > --- > > Key: IGNITE-12442 > URL: https://issues.apache.org/jira/browse/IGNITE-12442 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.7.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > After [IGNITE-6930|https://issues.apache.org/jira/browse/IGNITE-6930] was > implemented, there are some synchronization extra usage found. > 1. > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#add > 2. > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#emptyFlushCnt > hope need to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12466) Monitor query pool starvation
Kirill Tkalenko created IGNITE-12466: Summary: Monitor query pool starvation Key: IGNITE-12466 URL: https://issues.apache.org/jira/browse/IGNITE-12466 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 We are having a periodical starvation check ones of IGNITE_STARVATION_CHECK_INTERVAL interval. But that had by system and public pool only. I want to see the same monitor by query pool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12193) [Phase-1] Rebalancing cache group keys metric counters
[ https://issues.apache.org/jira/browse/IGNITE-12193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998907#comment-16998907 ] Nikolai Kulagin commented on IGNITE-12193: -- [~mmuzaf], please, review my change. I fixed your remarks. > [Phase-1] Rebalancing cache group keys metric counters > -- > > Key: IGNITE-12193 > URL: https://issues.apache.org/jira/browse/IGNITE-12193 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Assignee: Nikolai Kulagin >Priority: Critical > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 2h > Remaining Estimate: 0h > > Implement metrics counters related to the cache group: > * rebalancingPartitionsLeft long metric > * rebalancingReceivedKeys long metric > * rebalancingReceivedBytes long metric > * rebalancingStartTime long metric > * rebalancingFinishTime long metric -- This message was sent by Atlassian Jira (v8.3.4#803005)
