[jira] [Created] (IGNITE-14120) select count * returns multiple rows
Isaac Zhu created IGNITE-14120: -- Summary: select count * returns multiple rows Key: IGNITE-14120 URL: https://issues.apache.org/jira/browse/IGNITE-14120 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.8.1 Reporter: Isaac Zhu I have a partitioned table which has 1 backup, the *queryParallelism* is set to 4. The table primary key is column "ID", If I do this query: select count(*) from my_table where ID = 1000; It will return 4 rows: 1 0 0 0 If I query by other not primary-key columns of this table, the result is good, like: select count(*) from my_table where name = 'abcd' result is: 0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Fail on non-colocated join
Maxim it`s cool that it`s moved :) +1 for exception, but take into account such use case : T1 (country, city) affinity_key=country and T2 (country,city) affinity_key=country join with «city» usage — will be correct here (i hope, need to recheck of course) thus seems you must give some flag\hint what ever to run such reqs. thanks ! >Hi, Igniters! > >Last week I investigated a bug [1]. It's about an incorrect result for >non-colocated joins. For such joins it's required to set up the >"distributedJoin" flag, or try to make joined tables colocated. It is >covered in docs [2]. But it's not obvious and some users don't read that or >forget about that. In result there are wrong results for some queries that >are pretty hard to debug. > >There is a ticket [3] with a comment, where it's suggested to add a check >for such joins. I tried to implement it and found a place where it's >possible to put this check. But there is an open question what this check >should do. Currently I see 2 ways for that: >1. Forbid non-colocated joins that aren't marked with the distributedJoin >flag, and throw an exception. >2. Check every query for such joins and implicitly setup a distributedJoin >flag for them. > >Both solutions may break compatibility, but is this compatibility OK? > >Igniters, what do you think? > >[1] https://issues.apache.org/jira/browse/IGNITE-12847 >[2] >https://ignite.apache.org/docs/latest/SQL/distributed-joins#distributed-joins >[3] https://issues.apache.org/jira/browse/IGNITE-13019
[jira] [Created] (IGNITE-14119) Default JSR-107 Configuration
Jorg Janke created IGNITE-14119:
---
Summary: Default JSR-107 Configuration
Key: IGNITE-14119
URL: https://issues.apache.org/jira/browse/IGNITE-14119
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 2.9.1
Environment: AWS Linux 2
Reporter: Jorg Janke
When requesting a caching provider it is difficult to configure it.
{code:java}
for (final CachingProvider cachingProvider : Caching.getCachingProviders()) {
final javax.cache.CacheManager cacheManager =
cachingProvider.getCacheManager();
...{code}
The biggest issues are:
* org.apache.ignite.cache.CacheManager defaults to a Server configuration
* when providing a uri, Spring needs to be installed.
Suggestion:
in CacheManager or CachingProvider create the ability to statically set a
default configuration
* via uri for Spring (irrelevant for me)
* via providing a default IgniteConfiguration
{noformat}
public static void setDefaultConfiguration(IgniteConfiguration cfg) {
s_defaultConfiguration = cfg;
}
private static IgniteConfiguration s_defaultConfiguration;
// and in the constructor of CacheManager
IgniteConfiguration cfg = s_defaultConfiguration == null ? new
IgniteConfiguration() : s_defaultConfiguration;
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14118) Add converter of key-value configuration to traversable tree
Semyon Danilov created IGNITE-14118: --- Summary: Add converter of key-value configuration to traversable tree Key: IGNITE-14118 URL: https://issues.apache.org/jira/browse/IGNITE-14118 Project: Ignite Issue Type: Sub-task Reporter: Semyon Danilov We need to convert Map to TraversableTreeNode. Also, don't forget to update ConfigurationChanger to initialize tree with converted data from storage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Fail on non-colocated join
I think it should be the first option - just throw a clear exception if a query with a non-colocated join is executed without the flag set. Explicitly turning this mode on seems wrong, because in most cases this is not what a user intends to do. We also should make sure to run performance tests. As far as I know, this was not implemented initially because the assumption was that performing such a check on every single query might have a significant negative impact, especially for OLTP patterns that require low latency and high throughput. -Val On Tue, Feb 2, 2021 at 7:18 AM Max Timonin wrote: > Hi, Igniters! > > Last week I investigated a bug [1]. It's about an incorrect result for > non-colocated joins. For such joins it's required to set up the > "distributedJoin" flag, or try to make joined tables colocated. It is > covered in docs [2]. But it's not obvious and some users don't read that or > forget about that. In result there are wrong results for some queries that > are pretty hard to debug. > > There is a ticket [3] with a comment, where it's suggested to add a check > for such joins. I tried to implement it and found a place where it's > possible to put this check. But there is an open question what this check > should do. Currently I see 2 ways for that: > 1. Forbid non-colocated joins that aren't marked with the distributedJoin > flag, and throw an exception. > 2. Check every query for such joins and implicitly setup a distributedJoin > flag for them. > > Both solutions may break compatibility, but is this compatibility OK? > > Igniters, what do you think? > > [1] https://issues.apache.org/jira/browse/IGNITE-12847 > [2] > > https://ignite.apache.org/docs/latest/SQL/distributed-joins#distributed-joins > [3] https://issues.apache.org/jira/browse/IGNITE-13019 >
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Folks, I've prepared first benchmarks comparing 2.9.1 vs 2.10 [1]. Everything looks good at the first glance. https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10#ApacheIgnite2.10-Benchmarks(2.9.1vs2.10) On Fri, 29 Jan 2021 at 18:32, Никита Сафонов wrote: > > Hi Maxim, > > terrific! > > Then, I'll continue with the tasks on the list. > > Thank you, > Nikita > > чт, 28 янв. 2021 г. в 22:44, Maxim Muzafarov : > > > Hello Nikita, > > > > Thank you for sharing the state. > > > > I think we can move on to the next stages of the release. There are a > > few important steps left to do: release_notes, stress testing. This > > may take some time, so we still have time to complete the rest of the > > documentation tasks. > > > > On Thu, 28 Jan 2021 at 02:51, Никита Сафонов > > wrote: > > > > > > Hi Maxim et al, > > > > > > thank you! > > > > > > The rest of the documentation tasks for important features are also > > > completed. > > > > > > Nevertheless, there are still some items (the ones on my list that do not > > > have any doc tasks) that can be done for the 2.10 release. > > > If you want them to be included, I will try to provide patches ASAP. If > > > not, I am still ready to create the documentation for them and provide it > > > later. > > > > > > So, I will fully rely on your decision. > > > > > > Regards, > > > > > > Nikita > > > > > > вт, 26 янв. 2021 г. в 23:08, Maxim Muzafarov : > > > > > > > Nikita, Folks, > > > > > > > > All documentation tasks from the *[list #2]* [1] that you mentioned > > > > above have been processed and merged to the release branch. > > > > > > > > [1] > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Apache-Ignite-Release-2-10-time-scope-manager-tp50037p51061.html > > > > > > > > On Mon, 25 Jan 2021 at 18:59, Maxim Muzafarov > > wrote: > > > > > > > > > > Shiva, > > > > > > > > > > I've cherry-picked the issue to 2.10 branch. > > > > > https://issues.apache.org/jira/browse/IGNITE-13912 > > > > > > > > > > Ilya, > > > > > > > > > > Thank you for preparing the patch. I've cherry-picked to 2.10 it too. > > > > > https://issues.apache.org/jira/browse/IGNITE-14039 > > > > > > > > > > On Mon, 25 Jan 2021 at 17:50, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > > > > Hello! > > > > > > > > > > > > I have pushed the developer warning, javadoc warning and > > documentation > > > > > > update to https://issues.apache.org/jira/browse/IGNITE-14039 > > about the > > > > > > dangers of WAL state change. > > > > > > > > > > > > Please cherry-pick it to 2.10 branch or mention me if it's OK for > > me > > > > to do > > > > > > this. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > пн, 25 янв. 2021 г. в 14:44, Никита Сафонов < > > vlasovpavel2...@gmail.com > > > > >: > > > > > > > > > > > > > Hi Denis, > > > > > > > > > > > > > > Thanks a lot! > > > > > > > I'll update my PR's accordingly. > > > > > > > > > > > > > > Regards, > > > > > > > Nikita > > > > > > > > > > > > > > сб, 23 янв. 2021 г. в 00:59, Denis Magda : > > > > > > > > > > > > > > > Nikita, thanks. I reviewed those and shared some suggestions. > > > > Please take > > > > > > > > them into consideration. > > > > > > > > > > > > > > > > - > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jan 22, 2021 at 1:45 PM Никита Сафонов < > > > > > > > vlasovpavel2...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > > > The following documentation tasks for the important features > > now > > > > have > > > > > > > > PATCH > > > > > > > > > AVAILABLE status: > > > > > > > > > > > > > > > > > >- Caches warming up strategy - > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-13385?src=confmacro > > > > > > > > >- Update on JMX default configuration removal - > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-13606?src=confmacro > > > > > > > > >- Control.sh indexes manipulation commands - > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-13285?src=confmacro > > > > > > > > > > > > > > > > > > Please see the PR's attached to the tickets. > > > > > > > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Nikita > > > > > > > > > > > > > > > > > > пт, 22 янв. 2021 г. в 18:03, shm : > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > Can you please also include a critical ticket > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-13912 > > > > > > > > > > to 2.10 In terms of functionality it is a blocker. Still > > some > > > > > > > > debugging > > > > > > > > > is > > > > > > > > > > going on related to this issue. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Shiva > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-14117) Travis ignores JVM_EXTRA_ARGS
Maksim Timonin created IGNITE-14117: --- Summary: Travis ignores JVM_EXTRA_ARGS Key: IGNITE-14117 URL: https://issues.apache.org/jira/browse/IGNITE-14117 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin Travis failed to resolve some dependencies on jdk.11.0.2. Reason is JDK bug [1]. Workaround is setup -Djdk.tls.client.protocols=TLSv1.2. But it's incorrect to setup it within JVM_EXTRA_ARGS. Maven use MAVEN_OPTS for that [1] [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8220723] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14116) .NET: Review LongRunning tests
Pavel Tupitsyn created IGNITE-14116:
---
Summary: .NET: Review LongRunning tests
Key: IGNITE-14116
URL: https://issues.apache.org/jira/browse/IGNITE-14116
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.11
{{TestUtils.CategoryIntensive}} is supposed to be applied to long-running
tests, so that we can exclude that category and do a quick test run.
* Review current tests duration and apply the attribute to all tests that take
over 2 or 3 seconds.
* Review test fixtures that take a long time to set up.
* Update DEVNOTES with a command to run quick tests only (exclude long and
examples).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: IEP-66: Thin Client Automatic Binary Configuration
Guys, I agree with your concerns about backward compatibility, but I think this can be a good feature that will help us to add support for compact footer to thin clients that do not support it currently. Best Regards, Igor On Tue, Feb 2, 2021 at 11:49 AM Pavel Tupitsyn wrote: > Alex, > > This is a very good point, thank you for the heads up. > > The proposal does not include changing any existing behavior, > we simply add an operation to the protocol, so there is > no compatibility risk from the server-side changes alone. > > However, it looks like only .NET thin client can make use > of the compactFooter flag, since it is true by default there, > and changing from true to false is safe. > > Additionally, we can't use the nameMapper value even in .NET, > since it changes the default behavior and potentially breaks > compatibility on existing clusters. All we can do is log a warning. > > I've updated the proposal accordingly. > > > On Tue, Feb 2, 2021 at 9:50 AM Alex Plehanov > wrote: > > > Hello Pavel, > > > > Changing the "compact footer" property for an existing database can lead > to > > compatibility issues. Some clients (at least java) have "false" as the > > default value of the "compact footer" property, but the default value for > > the server-side is "true". If thin client will receive binary > configuration > > from the server it will be unable to get values using user-defined type > as > > a key inserted by previous versions of the client (see [1]). > > Also, AFAIK, some clients still don't have compact footer support. > > So we should think carefully about how to provide compatibility using > this > > feature (for example, enable this feature only for clusters with no data > > inserted into caches by previous versions of thin clients) > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-10960 > > > > пн, 1 февр. 2021 г. в 19:33, Pavel Tupitsyn : > > > > > Igniters, > > > > > > Please review the IEP [1] and let me know your thoughts. > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration > > > > > >
Re: Ignite website css not loading in local dev
Ops, i'm very sorry. Really, nothing common with docs. пн, 1 февр. 2021 г. в 16:10, Denis Magda : > Ivan, > > Saikat is updating the page below which doesn’t not belong to the docs and > doesn’t not require a Jekyll setup: > > https://ignite.apache.org/features/streaming.html > > On Sunday, January 31, 2021, Ivan Daschinsky wrote: > > > Saikat, have you tried build and run locally docs using docker? I just > > tried latest master -- everything is working as expected. > > Checked this in chrome incognito mode. I usually check docs locally using > > these steps: > > 1 cd docs > > 2. docker run -v "$PWD:/srv/jekyll" -p 4000:4000 jekyll/jekyll:latest > > jekyll s > > 3. Go to http://0.0.0.0:4000/docs/ in chrome incognito tab. > > > > пн, 1 февр. 2021 г. в 07:09, Denis Magda : > > > > > Saikat, > > > > > > Attach the screenshot with what you see. Please also check what errors > > the > > > browser is printing out while rendering the page. > > > > > > You don't need to install Jekyll unless you build the docs locally. So, > > > skip this step. Also, you don't need to uncomment the "include > virtual". > > > > > > - > > > Denis > > > > > > > > > On Sun, Jan 31, 2021 at 1:35 PM Saikat Maitra > > > > wrote: > > > > > > > Hi Denis, Ivan > > > > > > > > Thank you for your email. I have verified the below lines in > httpd.conf > > > > > > > > AddType text/html .html > > > > AddOutputFilter INCLUDES .html > > > > > > > > I have also pull latest changes from master. > > > > > > > > I still see the issue in local, let me check if I need to make any > > > > other changes. > > > > > > > > Also another change I did is I omitted the /trunk path from the > > Document > > > > root and used path till ignite-website since we are no longer using > > svn. > > > > > > > > I have a question related to Jekyll, do I need to install Jekyll to > run > > > the > > > > website in local? > > > > > > > > Also I have observed few additional lines commented in the index.html > > > like > > > > below > > > > > > > > > > > > > > > > I will check if uncommenting them addresses the issue. > > > > > > > > Regards, > > > > Saikat > > > > > > > > > > > > > > > > On Sun, Jan 31, 2021 at 12:08 PM Ivan Daschinsky < > ivanda...@gmail.com> > > > > wrote: > > > > > > > > > Hi, Saikat. Do you have > > > > https://issues.apache.org/jira/browse/IGNITE-13659 > > > > > commit in yout local branch? > > > > > In this patch, this issue was solved. Namely, > > docs/assets/css/docs.scss > > > > > and docs/assets/css/styles.scss are corrected. > > > > > Jekyll required that in custom stiles, first two lines contains > this > > > char > > > > > sequence `---` > > > > > > > > > > вс, 31 янв. 2021 г. в 03:09, Denis Magda : > > > > > > > > > > > Hi Saikat, > > > > > > > > > > > > Please double check that you configured the Apache server > strictly > > > > > > following steps 3-5. As far as I remember, I had the exact CSS > > issue > > > > > until > > > > > > did this (step 5): > > > > > > > > > > > > AddType text/html .html > > > > > > AddOutputFilter INCLUDES .html > > > > > > > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Sat, Jan 30, 2021 at 1:38 PM Saikat Maitra < > > > saikat.mai...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I was working on updating the ignite-website page[1] for Ignite > > > > > > Extensions > > > > > > > and I observed that in local when we are running the > > ignite-website > > > > > then > > > > > > it > > > > > > > is not loading the css. > > > > > > > > > > > > > > I have followed the instructions as mentioned in confluence > > > page[2] > > > > > > > > > > > > > > [1] https://ignite.apache.org/features/streaming.html > > > > > > > [2] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Website+Development > > > > > > > > > > > > > > Are there any additional steps that need to be done? > > > > > > > > > > > > > > I also noted that the source in live website pages vs the local > > is > > > > > > > different in terms of js and css files. > > > > > > > > > > > > > > Regards, > > > > > > > Saikat > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > > > > > > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > > > > -- > - > Denis > -- Sincerely yours, Ivan Daschinskiy
Re:
Closed. I've recreated a topic, as forget about the topic title there. On Tue, Feb 2, 2021 at 6:17 PM Max Timonin wrote: > Hi, Igniters! > > Last week I investigated a bug [1]. It's about an incorrect result for > non-colocated joins. For such joins it's required to set up the > "distributedJoin" flag, or try to make joined tables colocated. It is > covered in docs [2]. But it's not obvious and some users don't read that or > forget about that. In result there are wrong results for some queries that > are pretty hard to debug. > > There is a ticket [3] with a comment, where it's suggested to add a check > for such joins. I tried to implement it and found a place where it's > possible to put this check. But there is an open question what this check > should do. Currently I see 2 ways for that: > 1. Forbid non-colocated joins that aren't marked with the distributedJoin > flag, and throw an exception. > 2. Check every query for such joins and implicitly setup a distributedJoin > flag for them. > > Both solutions may break compatibility, but is this compatibility OK? > > Igniters, what do you think? > > [1] https://issues.apache.org/jira/browse/IGNITE-12847 > [2] > https://ignite.apache.org/docs/latest/SQL/distributed-joins#distributed-joins > [3] https://issues.apache.org/jira/browse/IGNITE-13019 >
[DISCUSSION] Fail on non-colocated join
Hi, Igniters! Last week I investigated a bug [1]. It's about an incorrect result for non-colocated joins. For such joins it's required to set up the "distributedJoin" flag, or try to make joined tables colocated. It is covered in docs [2]. But it's not obvious and some users don't read that or forget about that. In result there are wrong results for some queries that are pretty hard to debug. There is a ticket [3] with a comment, where it's suggested to add a check for such joins. I tried to implement it and found a place where it's possible to put this check. But there is an open question what this check should do. Currently I see 2 ways for that: 1. Forbid non-colocated joins that aren't marked with the distributedJoin flag, and throw an exception. 2. Check every query for such joins and implicitly setup a distributedJoin flag for them. Both solutions may break compatibility, but is this compatibility OK? Igniters, what do you think? [1] https://issues.apache.org/jira/browse/IGNITE-12847 [2] https://ignite.apache.org/docs/latest/SQL/distributed-joins#distributed-joins [3] https://issues.apache.org/jira/browse/IGNITE-13019
[jira] [Created] (IGNITE-14115) Introduce JAVA API for persistent store defragmentation
Anton Kurbanov created IGNITE-14115: --- Summary: Introduce JAVA API for persistent store defragmentation Key: IGNITE-14115 URL: https://issues.apache.org/jira/browse/IGNITE-14115 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Anton Kurbanov Since a lot of API is available in Java, it would be great to have a possibility to build and develop a cluster management tool. Defragmentation schedule, cancellation and status should be available with Java. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14114) Replace progress bar in NodeManager by spinner
Kirill Gusakov created IGNITE-14114: --- Summary: Replace progress bar in NodeManager by spinner Key: IGNITE-14114 URL: https://issues.apache.org/jira/browse/IGNITE-14114 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov At the moment we have no information about the duration of the node start process. So, instead of a fake progress bar, we should implement "spinner" approach for this type of process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14113) Fix licenses in cli module
Kirill Gusakov created IGNITE-14113: --- Summary: Fix licenses in cli module Key: IGNITE-14113 URL: https://issues.apache.org/jira/browse/IGNITE-14113 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14112) Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
Alexey Goncharuk created IGNITE-14112:
-
Summary: Revisit GridClosureProcessor#runLocalSafe(Runnable, byte)
usages
Key: IGNITE-14112
URL: https://issues.apache.org/jira/browse/IGNITE-14112
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
If a simple {{Runnable}} is passed to the {{runLocalSafe}} method, not only
will Ignite attempt to inject resources to the runnable, but it will also make
a call to deployment, which may have various side effects.
Need to walk through the code and replace {{Runnable}} with
{{GridPlainRunnable}} in all places where injection is not needed/expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14111) Clarify how AbstractDataPageIO works
Alexey Goncharuk created IGNITE-14111: - Summary: Clarify how AbstractDataPageIO works Key: IGNITE-14111 URL: https://issues.apache.org/jira/browse/IGNITE-14111 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk There we several questions on how direct and indirect items work in the DataPageIO, the mechanics should be added to Javadoc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14110) Create networking module
Anton Kalashnikov created IGNITE-14110: -- Summary: Create networking module Key: IGNITE-14110 URL: https://issues.apache.org/jira/browse/IGNITE-14110 Project: Ignite Issue Type: Sub-task Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov It needs to create a networking module with some API and simple implementation for further improvment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14109) Calcite integration. Sqlline tool freezes at the authorization step.
Fedor Malchikov created IGNITE-14109:
-
Summary: Calcite integration. Sqlline tool freezes at the
authorization step.
Key: IGNITE-14109
URL: https://issues.apache.org/jira/browse/IGNITE-14109
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Fedor Malchikov
Attachments: 42187, 42274, 42383, server.xml
Although authorization is not even enabled in the config:
{code:java}
Feb 01, 2021 6:44:21 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable
debug logging for more information)
Setting property: [force, true]
Setting property: [showWarnings, true]
Setting property: [showNestedErrs, true]
issuing: !connect -p driver org.apache.ignite.IgniteJdbcThinDriver
"jdbc:ignite:thin://127.0.0.1?useExperimentalQueryEngine=true"
Connecting to jdbc:ignite:thin://127.0.0.1?useExperimentalQueryEngine=true
Enter username for jdbc:ignite:thin://127.0.0.1?useExperimentalQueryEngine=true:
{code}
If you run the same test but using the 8733 build, then everything is
successful:
{code:java}
Setting property: [force, true]Setting property: [showWarnings, true]Setting
property: [showNestedErrs, true]issuing: !connect
jdbc:ignite:thin://127.0.0.1/?distributedJoins=true '' ''
org.apache.ignite.IgniteJdbcThinDriverConnecting to
jdbc:ignite:thin://127.0.0.1/?distributedJoins=trueWARNING: An illegal
reflective access operation has occurredWARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/home/prom1se/GG/calcite_work/var/suite-sql_combination/art-gg-com/libs/ignite-core-8.7.33.jar)
to field java.nio.Buffer.addressWARNING: Please consider reporting this to the
maintainers of org.apache.ignite.internal.util.GridUnsafe$2WARNING: Use
--illegal-access=warn to enable warnings of further illegal reflective access
operationsWARNING: All illegal access operations will be denied in a future
releaseConnected to: Apache Ignite (version
8.7.33#20201223-sha1:253a2146)Driver: Apache Ignite Thin JDBC Driver (version
8.7.33#20201223-sha1:253a2146)Autocommit status: trueTransaction isolation:
TRANSACTION_REPEATABLE_READ1/436!outputformat csv
{code}
I also tried to enable authorization and connect with options, but tool hangs
in the same place:
{code:java}
Feb 01, 2021 6:27:32 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable
debug logging for more information)
Setting property: [force, true]
Setting property: [showWarnings, true]
Setting property: [showNestedErrs, true]
issuing: !connect -p driver org.apache.ignite.IgniteJdbcThinDriver
"jdbc:ignite:thin://127.0.0.1;user=ignite;password=ignite?useExperimentalQueryEngine=true"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/home/prom1se/GG/calcite_work/var/suite-sql_combination/app-ign-calcite/libs/ignite-core-2.9.0.t48.jar)
to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Connecting to
jdbc:ignite:thin://127.0.0.1;user=ignite;password=ignite?useExperimentalQueryEngine=true
Enter username for
jdbc:ignite:thin://127.0.0.1;user=ignite;password=ignite?useExperimentalQueryEngine=true:
{code}
Command line:
['app-ign-calcite/bin/sqlline.sh', '-d',
'org.apache.ignite.IgniteJdbcThinDriver', '--verbose=true', '--force=true',
'--showWarnings=true', '--showNestedErrs=true', '-u',
'jdbc:ignite:thin://127.0.0.1?useExperimentalQueryEngine=true', '-f',
'test_sql_combination/ddl_create_with_memory/ddl_create_with_memory..calcite.sql.1.batch.txt']
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: IEP-66: Thin Client Automatic Binary Configuration
Alex, This is a very good point, thank you for the heads up. The proposal does not include changing any existing behavior, we simply add an operation to the protocol, so there is no compatibility risk from the server-side changes alone. However, it looks like only .NET thin client can make use of the compactFooter flag, since it is true by default there, and changing from true to false is safe. Additionally, we can't use the nameMapper value even in .NET, since it changes the default behavior and potentially breaks compatibility on existing clusters. All we can do is log a warning. I've updated the proposal accordingly. On Tue, Feb 2, 2021 at 9:50 AM Alex Plehanov wrote: > Hello Pavel, > > Changing the "compact footer" property for an existing database can lead to > compatibility issues. Some clients (at least java) have "false" as the > default value of the "compact footer" property, but the default value for > the server-side is "true". If thin client will receive binary configuration > from the server it will be unable to get values using user-defined type as > a key inserted by previous versions of the client (see [1]). > Also, AFAIK, some clients still don't have compact footer support. > So we should think carefully about how to provide compatibility using this > feature (for example, enable this feature only for clusters with no data > inserted into caches by previous versions of thin clients) > > [1]: https://issues.apache.org/jira/browse/IGNITE-10960 > > пн, 1 февр. 2021 г. в 19:33, Pavel Tupitsyn : > > > Igniters, > > > > Please review the IEP [1] and let me know your thoughts. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration > > >
