[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=17029084#comment-17029084 ] Pavel Tupitsyn commented on IGNITE-12049: - [~ascherbakov] [~SomeFire] I'm a little bit lost here. We changed the attributes to String, and we agreed to avoid using them for authentication (which is a dirty hack), right? Overall, is there any value whatsoever in this feature? > 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: 2h > 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] [Commented] (IGNITE-12468) ClassCastException on thinClient in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029056#comment-17029056
]
Ivan Pavlukhin commented on IGNITE-12468:
-
[~alex_pl], I checked some corner cases and found 2 generally unpleasant
things.
List having a direct reference to itself among elements leads to
{{StackOverflowError}}.
{code}
List l = new ArrayList<>();
l.add(l);
{code}
List having indirect self-reference leads to creation of 2 list objects instead
of only one as was initially.
{code}
List l = new ArrayList<>();
l.add(new Wrapper(l));
{code}
I.e. after put/get into a cache we will receive a top level _list1_ containing
a _wrapper_ wrapping _list2_. _list2_ will contain the same _wrapper_.
Good news for us are that both peculiarities takes place for a thick client as
well.
Additionally, I noticed a following. In PR there are changes on a
{{ClientUtils#readObject}} execution path handling nested deserialization of
collections. And as I understood it has an effect only for top-level
collections (a value inserted into a cache is a collection). If a collection is
wrapped into binary object, then a collection deserialization will go another
path. And actually it looks like a duplication again. In my mind we need 2
things here. Fist is a justification of the duplication if it is unavoidable.
Second is tests ensuring that thin and thick client behave the same.
> ClassCastException on thinClient in Apache Ignite
> -
>
> Key: IGNITE-12468
> URL: https://issues.apache.org/jira/browse/IGNITE-12468
> Project: Ignite
> Issue Type: Bug
> Components: binary, clients, thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Assignee: Aleksey Plekhanov
>Priority: Major
>
>
> {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-12618) Affinity cache for version of last server event can be wiped from history
[ https://issues.apache.org/jira/browse/IGNITE-12618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-12618: - Description: After IGNITE-11465 implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. was: After IGNITE-11465 RESOLVED implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. > Affinity cache for version of last server event can be wiped from history > - > > Key: IGNITE-12618 > URL: https://issues.apache.org/jira/browse/IGNITE-12618 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.9 > > > After IGNITE-11465 implemented, there's still a corner case when we can get > "Getting affinity for topology version earlier than affinity is calculated" > error. > If the whole history (not more than > GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow > copies for client events, we may be not able to fetch affinity cache for last > affinity change version. > We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity > version no less than [last affinity change version] is passed as an argument. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12618) Affinity cache for version of last server event can be wiped from history
Vyacheslav Koptilin created IGNITE-12618: Summary: Affinity cache for version of last server event can be wiped from history Key: IGNITE-12618 URL: https://issues.apache.org/jira/browse/IGNITE-12618 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.9 After IGNITE-11465 RESOLVED implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. -- 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=17028981#comment-17028981 ] Ryabov Dmitrii commented on IGNITE-12049: - They are accessible through connection, so, when we want to do something with attributes besides authentication, we just take them from the connection. > 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: 2h > 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] [Comment Edited] (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=17028974#comment-17028974 ] Alexey Scherbakov edited comment on IGNITE-12049 at 2/3/20 2:07 PM: But ticket description states otherwise: "Add user attributes to thin clients (like node attributes for server nodes). Make sure that custom authenticators can use these attributes." I think authAttrs should be renamed to userAttrs for other currently not implemented cases. What about support for other client types ? How user attributes usage can be generalized besides authentication ? [~ptupitsyn] [~isapego] what do you think ? was (Author: ascherbakov): But ticket description state otherwise: "Add user attributes to thin clients (like node attributes for server nodes). Make sure that custom authenticators can use these attributes." I think authAttrs should be renamed to userAttrs for other currently not implemented cases. What about support for other client types ? How user attributes usage can be generalized besides authentication ? [~ptupitsyn] [~isapego] what do you think ? > 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: 2h > 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] [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=17028974#comment-17028974 ] Alexey Scherbakov commented on IGNITE-12049: But ticket description state otherwise: "Add user attributes to thin clients (like node attributes for server nodes). Make sure that custom authenticators can use these attributes." I think authAttrs should be renamed to userAttrs for other currently not implemented cases. What about support for other client types ? How user attributes usage can be generalized besides authentication ? [~ptupitsyn] [~isapego] what do you think ? > 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: 2h > 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] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[ https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028907#comment-17028907 ] Ilya Kasnacheev commented on IGNITE-6804: - [~agura] I have fixed the remaining javadocs, please review. > Print a warning if HashMap is passed into bulk update operations > > > Key: IGNITE-6804 > URL: https://issues.apache.org/jira/browse/IGNITE-6804 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Denis A. Magda >Assignee: Ilya Kasnacheev >Priority: Critical > Labels: usability > Time Spent: 3h 20m > Remaining Estimate: 0h > > Ignite newcomers tend to stumble on deadlocks simply because the keys are > passed in an unordered HashMap. Propose to do the following: > * update bulk operations Java docs. > * print out a warning if not SortedMap (e.g. HashMap, > Weak/Identity/Concurrent/Linked HashMap etc) is passed into > a bulk method (instead of SortedMap) and contains more than 1 element. > However, we should make sure that we only print that warning once and not > every time the API is called. > * do not produce warning for explicit optimistic transactions > More details are here: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12617) PME-free switch should wait for recovery only at affected nodes.
Anton Vinogradov created IGNITE-12617: - Summary: PME-free switch should wait for recovery only at affected nodes. Key: IGNITE-12617 URL: https://issues.apache.org/jira/browse/IGNITE-12617 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Obviously, we should wait for recovery before finishing the switch. We should wait for replicated caches recovery globally. As to partitioned caches, we have to minimize the waiting group to allow upcoming operations where possible during the switch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-10970:
---
Labels: newbie usability (was: usability)
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Priority: Minor
> Labels: newbie, usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12613) Scala (Visor Console) test failed on Java 9+
[ https://issues.apache.org/jira/browse/IGNITE-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-12613: -- Fix Version/s: 2.9 > Scala (Visor Console) test failed on Java 9+ > > > Key: IGNITE-12613 > URL: https://issues.apache.org/jira/browse/IGNITE-12613 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: mas >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Failed test on TC agents with Java 9+ > [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900] > Noticed that Scala libraries and scalatest library are different for > different java versions. > Scala libraries and scalatest library should be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12613) Scala (Visor Console) test failed on Java 9+
[ https://issues.apache.org/jira/browse/IGNITE-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-12613: -- Fix Version/s: (was: mas) > Scala (Visor Console) test failed on Java 9+ > > > Key: IGNITE-12613 > URL: https://issues.apache.org/jira/browse/IGNITE-12613 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: mas >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Failed test on TC agents with Java 9+ > [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900] > Noticed that Scala libraries and scalatest library are different for > different java versions. > Scala libraries and scalatest library should be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12613) Scala (Visor Console) test failed on Java 9+
[ https://issues.apache.org/jira/browse/IGNITE-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028879#comment-17028879 ] Alexey Kuznetsov commented on IGNITE-12613: --- Looks good to me. > Scala (Visor Console) test failed on Java 9+ > > > Key: IGNITE-12613 > URL: https://issues.apache.org/jira/browse/IGNITE-12613 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: mas >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: mas > > Time Spent: 10m > Remaining Estimate: 0h > > Failed test on TC agents with Java 9+ > [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900] > Noticed that Scala libraries and scalatest library are different for > different java versions. > Scala libraries and scalatest library should be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12613) Scala (Visor Console) test failed on Java 9+
[
https://issues.apache.org/jira/browse/IGNITE-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028877#comment-17028877
]
Ignite TC Bot commented on IGNITE-12613:
{panel:title=Branch: [pull/7345/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=4976879buildTypeId=IgniteTests24Java8_RunAll]
> Scala (Visor Console) test failed on Java 9+
>
>
> Key: IGNITE-12613
> URL: https://issues.apache.org/jira/browse/IGNITE-12613
> Project: Ignite
> Issue Type: Improvement
> Components: visor
>Affects Versions: mas
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: mas
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed test on TC agents with Java 9+
> [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900]
> Noticed that Scala libraries and scalatest library are different for
> different java versions.
> Scala libraries and scalatest library should be updated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12613) Scala (Visor Console) test failed on Java 9+
[ https://issues.apache.org/jira/browse/IGNITE-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-12613: -- Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Scala (Visor Console) test failed on Java 9+ > > > Key: IGNITE-12613 > URL: https://issues.apache.org/jira/browse/IGNITE-12613 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: mas >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: mas > > Time Spent: 10m > Remaining Estimate: 0h > > Failed test on TC agents with Java 9+ > [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900] > Noticed that Scala libraries and scalatest library are different for > different java versions. > Scala libraries and scalatest library should be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11494: --- Labels: newbie usability (was: usability) > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: newbie, usability > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) SQL: Fix incorrect check for conflict of field names in key and value.
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12561:
--
Summary: SQL: Fix incorrect check for conflict of field names in key and
value. (was: Add a check for conflict of field names in key and value)
> SQL: Fix incorrect check for conflict of field names in key and value.
> --
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
> Fix For: 2.9
>
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) Add a check for conflict of field names in key and value
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12561:
--
Fix Version/s: 2.9
> Add a check for conflict of field names in key and value
>
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
> Fix For: 2.9
>
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) Add a check for conflict of field names in key and value
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12561:
--
Ignite Flags: Docs Required,Release Notes Required (was: Docs Required)
> Add a check for conflict of field names in key and value
>
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
> Fix For: 2.9
>
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) Add a check for conflict of field names in key and value
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12561:
--
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Add a check for conflict of field names in key and value
>
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
> Fix For: 2.9
>
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) Add a check for conflict of field names in key and value
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12561:
--
Description:
If key and value types of an SQL-enabled cache have the same fields annotated
with `@QuerySqlEntity` the cache will start without errors but the key's field
will not be queryable:
{noformat}
// here, you can't query Key.a via SQL
class Key {
@QuerySqlField int a;
@QuerySqlField int b;
}
class Value {
@QuerySqlField int a;
@QuerySqlField int c;
}
{noformat}
To workaround that, one needs to specify a different name for one of the `a`
fields:
{noformat}
class Key {
@QuerySqlField(name = "key_a") int a;
@QuerySqlField int b;
}
class Value {
@QuerySqlField int a;
@QuerySqlField int c;
}
{noformat}
The first configuration is obviously incorrect - one can't use the `Key.a` in
SQL but annotates it as queryable. We need to issue an error or at least a
warning for starting a configuration like this.
was:
If key and value types of an SQL-enabled cache have the same fields annotated
with `@QuerySqlEntity` the cache will start without errors but the key's field
will not be queryable:
{color:#172b4d}{{{color:#505f79}// here, you can't query Key.a via
SQL{color}{color:#0052cc}class{color} {color:#6554c0}Key{color} {
@QuerySqlField {color:#0052cc}int{color} a; @QuerySqlField
{color:#0052cc}int{color} b; }{color:#0052cc}class{color}
{color:#6554c0}Value{color} { @QuerySqlField {color:#0052cc}int{color} a;
@QuerySqlField {color:#0052cc}int{color} c; }}}{color}
To workaround that, one needs to specify a different name for one of the `a`
fields:
{color:#172b4d}{{{color:#0052cc}class{color} {color:#6554c0}Key{color} {
@QuerySqlField(name = {color:#36b37e}"key_a"{color}) {color:#0052cc}int{color}
a; @QuerySqlField {color:#0052cc}int{color} b; }{color:#0052cc}class{color}
{color:#6554c0}Value{color} { @QuerySqlField {color:#0052cc}int{color} a;
@QuerySqlField {color:#0052cc}int{color} c; }}}{color}
The first configuration is obviously incorrect - one can't use the `Key.a` in
SQL but annotates it as queryable. We need to issue an error or at least a
warning for starting a configuration like this.
> Add a check for conflict of field names in key and value
>
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
>
>
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
>
>
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a`
> in SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) Add a check for conflict of field names in key and value
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12561:
--
Description:
If key and value types of an SQL-enabled cache have the same fields annotated
with `@QuerySqlEntity` the cache will start without errors but the key's field
will not be queryable:
{noformat}
// here, you can't query Key.a via SQL
class Key {
@QuerySqlField int a;
@QuerySqlField int b;
}
class Value {
@QuerySqlField int a;
@QuerySqlField int c;
}
{noformat}
To workaround that, one needs to specify a different name for one of the `a`
fields:
{noformat}
class Key {
@QuerySqlField(name = "key_a") int a;
@QuerySqlField int b;
}
class Value {
@QuerySqlField int a;
@QuerySqlField int c;
}
{noformat}
The first configuration is obviously incorrect - one can't use the `Key.a` in
SQL but annotates it as queryable. We need to issue an error or at least a
warning for starting a configuration like this.
was:
If key and value types of an SQL-enabled cache have the same fields annotated
with `@QuerySqlEntity` the cache will start without errors but the key's field
will not be queryable:
{noformat}
// here, you can't query Key.a via SQL
class Key {
@QuerySqlField int a;
@QuerySqlField int b;
}
class Value {
@QuerySqlField int a;
@QuerySqlField int c;
}
{noformat}
To workaround that, one needs to specify a different name for one of the `a`
fields:
{noformat}
class Key {
@QuerySqlField(name = "key_a") int a;
@QuerySqlField int b;
}
class Value {
@QuerySqlField int a;
@QuerySqlField int c;
}
{noformat}
The first configuration is obviously incorrect - one can't use the `Key.a` in
SQL but annotates it as queryable. We need to issue an error or at least a
warning for starting a configuration like this.
> Add a check for conflict of field names in key and value
>
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12493) Test refactoring. Explicit method for starting client nodes
[
https://issues.apache.org/jira/browse/IGNITE-12493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028851#comment-17028851
]
Ignite TC Bot commented on IGNITE-12493:
{panel:title=Branch: [pull/7216/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=4977117buildTypeId=IgniteTests24Java8_RunAll]
> Test refactoring. Explicit method for starting client nodes
> ---
>
> Key: IGNITE-12493
> URL: https://issues.apache.org/jira/browse/IGNITE-12493
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: newbie
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> Right now there is almost 500 explicit usage of {{setClientMode}} in tests.
> Seems we should support the starting of client nodes in test framework.
> We should refactor tests to use {{startClientNode(String name)}}.
> This will simplify tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12615) Add warning that cluster deactivation purges data from memory
[ https://issues.apache.org/jira/browse/IGNITE-12615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12615: - Component/s: documentation > Add warning that cluster deactivation purges data from memory > - > > Key: IGNITE-12615 > URL: https://issues.apache.org/jira/browse/IGNITE-12615 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.7.6 >Reporter: Denis A. Magda >Assignee: Artem Budnikov >Priority: Blocker > Fix For: 2.8 > > > Baseline topology [1] and control script's [2] documentation needs to have a > warning callout saying that a cluster deactivation procedure will purge data > from memory requiring users to reload data back after the activation. For > caches that persist data in the native persistence, this will happen > automatically, for all the other cases the user has to reload data manually. > [1] https://apacheignite.readme.io/docs/baseline-topology > [2] > https://apacheignite-tools.readme.io/docs/control-script#section-activation-deactivation-and-topology-management -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12020) SQL: Metrics of using memory quotas.
[ https://issues.apache.org/jira/browse/IGNITE-12020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-12020. Resolution: Invalid > SQL: Metrics of using memory quotas. > > > Key: IGNITE-12020 > URL: https://issues.apache.org/jira/browse/IGNITE-12020 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > Only local (per node) metrics are in scope. > Metrics to implement: > 1) How many times memory quota have been requested on the node by all the > queries in total. > (org.apache.ignite.internal.processors.query.h2.QueryMemoryManager) > 2) How much memory all the queries are allowed to reserve on this node in > total. (Possibly constant value until node reboot) > 3) How much memory currently available for the queries on this node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12603) Questions regarding Data Availability/Replication.
[ https://issues.apache.org/jira/browse/IGNITE-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12603: - Ignite Flags: (was: Docs Required,Release Notes Required) > Questions regarding Data Availability/Replication. > -- > > Key: IGNITE-12603 > URL: https://issues.apache.org/jira/browse/IGNITE-12603 > Project: Ignite > Issue Type: Wish >Reporter: Aditya >Priority: Blocker > > Scenario: > Datacenter 1 (Main) -> One Application Server (Client Node CN1) and One DB > Server (Server Node SN1). > Datacenter 2 (Recovery) -> One Application Server (Client Node CN2) and One > DB Server (Server Node SN2). > Usually, all the user requests go to CN1 but not CN2. So, technically we will > not run CN2. So forget about CN2. I will tell you why it's used later. > So there are three nodes here running -> CN1, SN1, SN2. > Question 1: > We don't use Apache Ignite for cache purposes, but we will use it for disk > persistent storage. And we don't need Ignite for partitioning data (we will > think about it later). Now, how to make sure that the data that is being > stored in SN1 will be replicated to SN2. We want SN2 to be backup node for > SN1. Is that possible? If so, how? > Conditions: > 1. CN1 usually should not make connections with SN2 (since it's backup). > 2. SN1 and SN2 link will be very fragile and of less bandwidth. Usually, > both will be in different network segments. > Question 2: > Let's say SN1 is down. Now, will the queries automatically reach SN2 without > doing anything? And if SN1 is restarted, can we expect the queries to reach > SN1 instead of SN2, as CN1 - SN2 link is slow? > Question 3 : > After a few months, we will flip the entire setup, making DC2 as Main and > DC1 as Recovery. In this case, CN2 will make connections to SN2 and CN1 will > not be running. How to quickly switch so that SN2 is replicated almost with > SN1 and be ready to serve requests from CN2? > > PS: We are using JDBC Thin Client, so if possible please answer in that > context with examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12603) Questions regarding Data Availability/Replication.
[ https://issues.apache.org/jira/browse/IGNITE-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028836#comment-17028836 ] Ilya Kasnacheev commented on IGNITE-12603: -- Please use u...@ignite.apache.org mailing list or Stack Overflow to ask Ignite-related questions. JIRA is strictly for development process. > Questions regarding Data Availability/Replication. > -- > > Key: IGNITE-12603 > URL: https://issues.apache.org/jira/browse/IGNITE-12603 > Project: Ignite > Issue Type: Wish >Reporter: Aditya >Priority: Blocker > > Scenario: > Datacenter 1 (Main) -> One Application Server (Client Node CN1) and One DB > Server (Server Node SN1). > Datacenter 2 (Recovery) -> One Application Server (Client Node CN2) and One > DB Server (Server Node SN2). > Usually, all the user requests go to CN1 but not CN2. So, technically we will > not run CN2. So forget about CN2. I will tell you why it's used later. > So there are three nodes here running -> CN1, SN1, SN2. > Question 1: > We don't use Apache Ignite for cache purposes, but we will use it for disk > persistent storage. And we don't need Ignite for partitioning data (we will > think about it later). Now, how to make sure that the data that is being > stored in SN1 will be replicated to SN2. We want SN2 to be backup node for > SN1. Is that possible? If so, how? > Conditions: > 1. CN1 usually should not make connections with SN2 (since it's backup). > 2. SN1 and SN2 link will be very fragile and of less bandwidth. Usually, > both will be in different network segments. > Question 2: > Let's say SN1 is down. Now, will the queries automatically reach SN2 without > doing anything? And if SN1 is restarted, can we expect the queries to reach > SN1 instead of SN2, as CN1 - SN2 link is slow? > Question 3 : > After a few months, we will flip the entire setup, making DC2 as Main and > DC1 as Recovery. In this case, CN2 will make connections to SN2 and CN1 will > not be running. How to quickly switch so that SN2 is replicated almost with > SN1 and be ready to serve requests from CN2? > > PS: We are using JDBC Thin Client, so if possible please answer in that > context with examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12603) Questions regarding Data Availability/Replication.
[ https://issues.apache.org/jira/browse/IGNITE-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12603: - Release Note: (was: Please use u...@ignite.apache.org mailing list or Stack Overflow to ask Ignite-related questions. JIRA is strictly for development process.) > Questions regarding Data Availability/Replication. > -- > > Key: IGNITE-12603 > URL: https://issues.apache.org/jira/browse/IGNITE-12603 > Project: Ignite > Issue Type: Wish >Reporter: Aditya >Priority: Blocker > > Scenario: > Datacenter 1 (Main) -> One Application Server (Client Node CN1) and One DB > Server (Server Node SN1). > Datacenter 2 (Recovery) -> One Application Server (Client Node CN2) and One > DB Server (Server Node SN2). > Usually, all the user requests go to CN1 but not CN2. So, technically we will > not run CN2. So forget about CN2. I will tell you why it's used later. > So there are three nodes here running -> CN1, SN1, SN2. > Question 1: > We don't use Apache Ignite for cache purposes, but we will use it for disk > persistent storage. And we don't need Ignite for partitioning data (we will > think about it later). Now, how to make sure that the data that is being > stored in SN1 will be replicated to SN2. We want SN2 to be backup node for > SN1. Is that possible? If so, how? > Conditions: > 1. CN1 usually should not make connections with SN2 (since it's backup). > 2. SN1 and SN2 link will be very fragile and of less bandwidth. Usually, > both will be in different network segments. > Question 2: > Let's say SN1 is down. Now, will the queries automatically reach SN2 without > doing anything? And if SN1 is restarted, can we expect the queries to reach > SN1 instead of SN2, as CN1 - SN2 link is slow? > Question 3 : > After a few months, we will flip the entire setup, making DC2 as Main and > DC1 as Recovery. In this case, CN2 will make connections to SN2 and CN1 will > not be running. How to quickly switch so that SN2 is replicated almost with > SN1 and be ready to serve requests from CN2? > > PS: We are using JDBC Thin Client, so if possible please answer in that > context with examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12603) Questions regarding Data Availability/Replication.
[ https://issues.apache.org/jira/browse/IGNITE-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-12603. -- Release Note: Please use u...@ignite.apache.org mailing list or Stack Overflow to ask Ignite-related questions. JIRA is strictly for development process. Resolution: Not A Problem > Questions regarding Data Availability/Replication. > -- > > Key: IGNITE-12603 > URL: https://issues.apache.org/jira/browse/IGNITE-12603 > Project: Ignite > Issue Type: Wish >Reporter: Aditya >Priority: Blocker > > Scenario: > Datacenter 1 (Main) -> One Application Server (Client Node CN1) and One DB > Server (Server Node SN1). > Datacenter 2 (Recovery) -> One Application Server (Client Node CN2) and One > DB Server (Server Node SN2). > Usually, all the user requests go to CN1 but not CN2. So, technically we will > not run CN2. So forget about CN2. I will tell you why it's used later. > So there are three nodes here running -> CN1, SN1, SN2. > Question 1: > We don't use Apache Ignite for cache purposes, but we will use it for disk > persistent storage. And we don't need Ignite for partitioning data (we will > think about it later). Now, how to make sure that the data that is being > stored in SN1 will be replicated to SN2. We want SN2 to be backup node for > SN1. Is that possible? If so, how? > Conditions: > 1. CN1 usually should not make connections with SN2 (since it's backup). > 2. SN1 and SN2 link will be very fragile and of less bandwidth. Usually, > both will be in different network segments. > Question 2: > Let's say SN1 is down. Now, will the queries automatically reach SN2 without > doing anything? And if SN1 is restarted, can we expect the queries to reach > SN1 instead of SN2, as CN1 - SN2 link is slow? > Question 3 : > After a few months, we will flip the entire setup, making DC2 as Main and > DC1 as Recovery. In this case, CN2 will make connections to SN2 and CN1 will > not be running. How to quickly switch so that SN2 is replicated almost with > SN1 and be ready to serve requests from CN2? > > PS: We are using JDBC Thin Client, so if possible please answer in that > context with examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12600) Baseline auto-adjust makes it impossible to assemble mixed persistence clusters
[
https://issues.apache.org/jira/browse/IGNITE-12600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028834#comment-17028834
]
Ilya Kasnacheev commented on IGNITE-12600:
--
Right now it seems to me that mixed persistence clusters are broken in both
2.7.x and upcoming 2.8.
Maybe we should drop their support completely by disabling their creation on
discovery level.
> Baseline auto-adjust makes it impossible to assemble mixed persistence
> clusters
> ---
>
> Key: IGNITE-12600
> URL: https://issues.apache.org/jira/browse/IGNITE-12600
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> If you try to start a cluster of two nodes, where A only has default
> non-persistent region, and B also has a persistent non-default region, it
> will fail with:
> {code}
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Joining
> persistence node to in-memory cluster couldn't be allowed due to baseline
> auto-adjust is enabled and timeout equal to 0
> {code}
> However, there seem to be no configuration settings to actually disable this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12607) PartitionsExchangeAwareTest is flaky
[ https://issues.apache.org/jira/browse/IGNITE-12607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028778#comment-17028778 ] Vyacheslav Koptilin commented on IGNITE-12607: -- Hello [~ivan.glukos], The fix looks good to me. Please proceed with the merge. > PartitionsExchangeAwareTest is flaky > > > Key: IGNITE-12607 > URL: https://issues.apache.org/jira/browse/IGNITE-12607 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Proof: > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6/4972239 > Seems like cache update sometimes is not possible even before topologies are > locked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: (was: Vladimir Steshin) > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12504) Auto-adjust breaks existing code, should be disabled by default
[
https://issues.apache.org/jira/browse/IGNITE-12504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov resolved IGNITE-12504.
Resolution: Duplicate
> Auto-adjust breaks existing code, should be disabled by default
> ---
>
> Key: IGNITE-12504
> URL: https://issues.apache.org/jira/browse/IGNITE-12504
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.8
>
>
> We have automatic baseline adjustment now. However, it is 'on' by default,
> which means it breaks existing code. I see new exceptions when starting an
> existing project after bumping Ignite dependency version:
> {code}
> Caused by:
> org.apache.ignite.internal.processors.cluster.BaselineAdjustForbiddenException:
> Baseline auto-adjust is enabled, please turn-off it before try to adjust
> baseline manually
> {code}
> (Please see reproducer from attached UL discussion)
> I think we should disable auto-adjust by default, let people enable it when
> they see it fit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: Vladimir Steshin > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
