[jira] [Created] (IGNITE-13827) Deadlock when receiving ComputeTask result by IgniteClient.
Sergei Ryzhov created IGNITE-13827:
--
Summary: Deadlock when receiving ComputeTask result by
IgniteClient.
Key: IGNITE-13827
URL: https://issues.apache.org/jira/browse/IGNITE-13827
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Sergei Ryzhov
Assignee: Sergei Ryzhov
Deadlock when receiving ComputeTask result by IgniteClient.
when ComputeTask return a user object for example:
{code:java}
class TestVal(){
String val;
}
{code}
WA client.binary().toBinary(new TestVal());
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Migrating NodeJS client to TypeScript
Cool, I like the idea. You've got a +1 from me Best Regards, Igor On Tue, Dec 1, 2020 at 12:20 PM Данилов Семён wrote: > Yes, TS compiler produces JS files and TS-typings. Users that are already > using JS version will have a seamless migration. Note: we'll have to > publish compiled JS files along with typings. > > - > Semyon. > > 01.12.2020, 09:59, "Ivan Daschinsky" : > >> Is there any value in keeping both versions - the plain JavaScript one > > > > and the TypeScript specific > > Hi! No, there is no value. TS sources should be transpiled to JS before > > execution. > > > > вт, 1 дек. 2020 г. в 01:31, Denis Magda : > > > >> Hi Semyon, > >> > >> Is there any value in keeping both versions - the plain JavaScript one > and > >> the TypeScript specific? > >> > >> - > >> Denis > >> > >> On Mon, Nov 30, 2020 at 12:16 PM Данилов Семён > wrote: > >> > >> > Hello Igniters! > >> > > >> > I'd like to propose a big change for the nodejs thin client: a full > >> > rewrite from JavaScript to TypeScript. > >> > > >> > Strong typing will not only help us in future while developing new > >> > features, but will also indicate existing type inconsistencies (I > know > >> > there is a couple). > >> > Also, we will have out of the box types for API documentation, which > is > >> > very handy for users. > >> > > >> > So what do you think? > >> > > >> > Kind regards, > >> > Semyon. > >> > > > > > -- > > Sincerely yours, Ivan Daschinskiy >
Re: swapping the blocks on the website https://ignite.apache.org/download.cgi: SOURCE RELEASES and BINARY RELEASES
Folks, Some time ago I've moved the source code section upper since it was the recommendation of the announce list owner prior to publishing the announcement message of the Apache Ignite 2.8 release. The mandatory information is release files verification. I think we could move the binary section upper, not a big deal. On Mon, 7 Dec 2020 at 17:55, Pavel Tupitsyn wrote: > > Ilya, > > I had the same thought, but Apache guidelines do not mention anywhere that > source releases should come first. > Binary releases are a much more popular option, so it makes sense to show > them first. > > On Mon, Dec 7, 2020 at 5:53 PM Ilya Kasnacheev > wrote: > > > Hello! > > > > As far as my understanding goes, the principal product of an Apache project > > is source releases. Binary releases are merely provided for convenience of > > the user. So it's logical that we offer source releases first. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 3 дек. 2020 г. в 23:13, Denis Magda : > > > > > +1 > > > > > > - > > > Denis > > > > > > > > > On Thu, Dec 3, 2020 at 10:58 AM kpushenko wrote: > > > > > > > Hello, igniters! > > > > > > > > I suggest swapping the blocks on the website > > > > https://ignite.apache.org/download.cgi: SOURCE RELEASES > > > > and BINARY RELEASES. > > > > It is more predictable for the user. > > > > https://ignite.apache.org/download.cgi > > > > > > > > > > > > > > > > > > > > -- > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > >
Re: Contribution to the community
Hi Victor, Welcome to the Apache Ignite community! I've added your Jira account to the Cotributors group. Good luck! Pavel On Mon, Dec 7, 2020 at 8:13 PM Chemodanov Viktor wrote: > Hi All! > > > > My name is Victor Chemodanov. > > > > As a technical writer, I would be glad to contribute to the Community. > > > > Please, provide me with access to Ignite Jira. > > > > My Ignite Jira ID: > > vikchemodanov > > > > > > Regards, > > > > Viktor Chemodanov > > > > От: vchemoda...@outlook.com от имени vchemoda...@outlook.com < > vchemoda...@outlook.com> > Отправлено: 7 декабря 2020 г. 19:21 > Кому: dev@ignite.apache.org > Тема: Contribution to the community > > > Hi All! > > > > My name is Victor Chemodanov. > > > > As a technical writer, I would be glad to contribute to the Community. > > > > Please, provide me with access to Ignite Jira. > > > > My Ignite Jira ID: > > vikchemodanov > > > > > > Regards, > > > > Viktor Chemodanov >
RE: Contribution to the community
Hi All! My name is Victor Chemodanov. As a technical writer, I would be glad to contribute to the Community. Please, provide me with access to Ignite Jira. My Ignite Jira ID: vikchemodanov Regards, Viktor Chemodanov От: vchemoda...@outlook.com от имени vchemoda...@outlook.com Отправлено: 7 декабря 2020 г. 19:21 Кому: dev@ignite.apache.org Тема: Contribution to the community Hi All! My name is Victor Chemodanov. As a technical writer, I would be glad to contribute to the Community. Please, provide me with access to Ignite Jira. My Ignite Jira ID: vikchemodanov Regards, Viktor Chemodanov
[Meetup] I have a cool Ignite user story for you on December 8 (and need more of them!)
Hi Igniters! At tomorrows' Meetup, we welcome Mikhail Antonov from Raiffeisen bank. He will share his experience of using Ignite in the core banking system for scaling and reducing backend load. I like this story as it's elegant and simple. Join us at 8 AM PST / 5 PM CET: https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/274647932/ It's time to plan our 2021 meetups and I ask you to share your experience of going into production with Ignite. It hasn't to be anything exotic or over-complicated or even super-smooth. If you think your story needs polishing before presenting it in public - please contact me, and I'll do my best to help. More various user stories would help developers new to the product to adopt it and stay with the community. Cheers, Kseniya Meetup CFP https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform
[jira] [Created] (IGNITE-13826) .NET: RendezvousAffinityFunction.BackupFilter
Pavel Tupitsyn created IGNITE-13826:
---
Summary: .NET: RendezvousAffinityFunction.BackupFilter
Key: IGNITE-13826
URL: https://issues.apache.org/jira/browse/IGNITE-13826
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.10
* Add {{RendezvousAffinityFunction.BackupFilter}} property
* Allow single predefined implementation:
{{ClusterNodeAttributeAffinityBackupFilter}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: swapping the blocks on the website https://ignite.apache.org/download.cgi: SOURCE RELEASES and BINARY RELEASES
Ilya, I had the same thought, but Apache guidelines do not mention anywhere that source releases should come first. Binary releases are a much more popular option, so it makes sense to show them first. On Mon, Dec 7, 2020 at 5:53 PM Ilya Kasnacheev wrote: > Hello! > > As far as my understanding goes, the principal product of an Apache project > is source releases. Binary releases are merely provided for convenience of > the user. So it's logical that we offer source releases first. > > Regards, > -- > Ilya Kasnacheev > > > чт, 3 дек. 2020 г. в 23:13, Denis Magda : > > > +1 > > > > - > > Denis > > > > > > On Thu, Dec 3, 2020 at 10:58 AM kpushenko wrote: > > > > > Hello, igniters! > > > > > > I suggest swapping the blocks on the website > > > https://ignite.apache.org/download.cgi: SOURCE RELEASES > > > and BINARY RELEASES. > > > It is more predictable for the user. > > > https://ignite.apache.org/download.cgi > > > > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >
Re: swapping the blocks on the website https://ignite.apache.org/download.cgi: SOURCE RELEASES and BINARY RELEASES
Hello! As far as my understanding goes, the principal product of an Apache project is source releases. Binary releases are merely provided for convenience of the user. So it's logical that we offer source releases first. Regards, -- Ilya Kasnacheev чт, 3 дек. 2020 г. в 23:13, Denis Magda : > +1 > > - > Denis > > > On Thu, Dec 3, 2020 at 10:58 AM kpushenko wrote: > > > Hello, igniters! > > > > I suggest swapping the blocks on the website > > https://ignite.apache.org/download.cgi: SOURCE RELEASES > > and BINARY RELEASES. > > It is more predictable for the user. > > https://ignite.apache.org/download.cgi > > > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > >
Re: Issue with custom security plugin and thin clients
Hi Denis, Thanks for the suggestion. I was trying to implement the approach of using the cache to store the thin clients security context. Below is the approach, I wanted to follow: 1) Add the thin client secCtx to cache during authentication time. 2) Retrieve the thin client secCtx using subjId in the new method to be overridden: GridSecurityProcessor.securityContext(UUID subjId) method, 3) Remove the entry from the cache during the onSessionExpired method call. 4) Remove the entry from the cache during the onDisconnected() method call. ** I am not sure if I have to handle anything extra for onReconnected(), as I see again the authenticate method gets called. Can you please let me know if the above steps are OK or do I need to handle any other case ? *Thanks & Regards,* *Vishwas * On Mon, Nov 30, 2020 at 2:11 PM Denis Garus wrote: > Hi! > > Node attributes can't be used to spread a thin client's security context. > For this purpose, you can use a cache of Ignite, a third-party database, > or other tools appropriate to your case. > > сб, 28 нояб. 2020 г. в 06:16, Vishwas Bm : > > > Hi Denis, > > > > > > Thanks for the reply. > > Yes I was looking for a way to spread the security context to all cluster > > nodes when a thin client(sqlline) gets authenticated. > > I tried to see if I can use node attributes or user attributes to pass > the > > information to other nodes. When a cluster of ignite server is already > > formed, this will not help as attributes will not be available on remote > > nodes. > > > > The node attributes cannot be changed at run time and the attributes will > > be available to remote nodes only when they join the cluster. > > > > So I wanted to know, if there is any other way to do this ? > > I checked your poc PR for reference, > > https://github.com/apache/ignite/pull/7375 > > > > In thin client case authenticate node will not be called but authenticate > > method is getting called. > > > > > > Regards, > > Vishwas > > > > > > On Fri, 27 Nov, 2020, 14:29 Denis Garus, wrote: > > > > > Hello! > > > > > > > > > If I understood your problem correctly, you need to make a thin > client's > > > security context allowed on a remote node. > > > > > > When a security plugin does authenticate a thin client, it should > spread > > > the thin client's security context on the cluster. > > > > > > How a security context will be transmitted to a remote node is up to > the > > > plugin's developers. > > > > > > Also, you have to implement the > > GridSecurityProcessor.securityContext(UUID > > > subjId) method, > > > > > > the way this method is used in Ignite can see in the task description > > [1]. > > > > > > > > > > > > > > >1. https://issues.apache.org/jira/browse/IGNITE-12759 > > > > > > > > > чт, 26 нояб. 2020 г. в 10:01, Vishwas Bm : > > > > > > > Hi, > > > > > > > > I was facing an issue with a custom security plugin and thin remote > > > client. > > > > I am using Ignite 2.9.0 version and I am hitting below issue > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-41%3A+Security+Context+of+thin+client+on+remote+nodes > > > > > > > > > > > > I had asked the question in the user listing but unfortunately I did > > not > > > > get any reply. > > > > So I am posting this question here: > > > > > > > > > > > > > > > > > > http://apache-ignite-users.70518.x6.nabble.com/Query-on-implementing-GridSecurityProcessor-td34672.html > > > > > > > > > > > > *Thanks & Regards,* > > > > > > > > *Vishwas * > > > > > > > > > >
Re: Tool for performance statistics reports
Hello, Nikita. Makes sense. I will take a look. > 7 дек. 2020 г., в 15:29, Nikita Amelchev написал(а): > > Hello, Igniters. > > I have implemented the profiling tool [1, 2]. It writes duration and > other parameters of user operations (scan, SQL query, transactions, > tasks, jobs, CQ, etc) to a local file. This info can be used in > various cases. The main goal is to build the performance report to > analyze the count and duration of user queries [3]. > > We already have the tracing with similar functionality but I think > Ignite should have both tools - tracing and profiling. > > Because the tracing causes performance drop 52% [4] and can not be > used for collecting statistics about all queries in production > deployments. The performance drop of the profiling tool is less than > 2% and it can be used in production. I have benchmarked the tracing > and got the results: > > -2% when configured OpenCensusTracingSpi and all scopes disabled > -52% for TX scope (IgnitePutTxBenchmark) > -58% for SQL scope (IgniteSqlQueryBenchmark) > > Such a performance drop is significant to not use the tracing in production. > > I have considered the possibility to reuse the tracing API. If > statistics collecting will be implemented with the TracingSpi then we > get a performance drop due to: > - Transferring tracing context over the network. > - Using ThreadLocal for spans > - Converting primitives and objects to string and vice versa. (API > supports only String-based tags and values) > - Generating span objects > > I have benchmarked implementations on the yardstick’s > IgniteGetBenchmark. The tracing context transferring over the network > was disabled. The results: > - Tracing API implementation - 8% performance drop. > - Proposed implementation - 2% performance drop. > > I think this is a significant drop and implementation with reuse > tracing API should not be used. The cluster profiling should have as > little performance drop as possible to be used in production. The > tracing will be used for the detailed investigation. > > WDYT? > > The tool is ready to be reviewed [3, 5]. > > [1] https://issues.apache.org/jira/browse/IGNITE-12666 > [2] > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool > [3] https://github.com/apache/ignite-extensions/pull/16 > [4] > https://issues.apache.org/jira/secure/attachment/13016636/Tracing%20benchmarks.docx > [5] https://github.com/apache/ignite/pull/7693 > > ср, 24 июн. 2020 г. в 23:31, Saikat Maitra : >> >> Hi Nikita, >> >> The changes in this PR looks good. >> >> https://github.com/apache/ignite-extensions/pull/16 >> >> Regards, >> Saikat >> >> On Mon, Jun 22, 2020 at 12:03 PM Nikolay Izhikov >> wrote: >> >>> Hello, Igniters. >>> >>> I think that inside Ignite core we should name this feature as >>> «performance statistics» >>> We already have «cache statistics». >>> Data that is collected by performance statistics can be used not only for >>> profiling but to solve other tasks. >>> >>> 22 июня 2020 г., в 14:00, Nikita Amelchev >>> написал(а): Hi, guys. I have mentioned components under the MIT license in the LICENSE file. Saikat, I have fixed PR according to your suggestions. Thanks for taking >>> a look. >>> >>> > > > > -- > Best wishes, > Amelchev Nikita
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Support it пн, 7 дек. 2020 г. в 14:03, Maxim Muzafarov : > Folks, > > > I propose to shift a bit the release date since 2.9.1 has not released yet. > > > Scope Freeze: December 28, 2020 > Code Freeze: December 28, 2020 > Voting Date: January 25, 2021 > Release Date: February 1, 2021 > > WDYT? > > On Tue, 17 Nov 2020 at 12:59, Maxim Muzafarov wrote: > > > > Folks, > > > > I've marked all the valuable features of 2.10 release with an > > appropriate label. Please, let me know if I've missed anything. > > > > Here is the link to the JIRA: > > https://s.apache.org/1hyfu > > > > > > On Thu, 12 Nov 2020 at 12:28, Anton Vinogradov wrote: > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > Vinogradov, Ivan Daschinskiy) > > > > Will all related issues be included in the 2.10? > > > We're at the final preparations phase. Going to start the merge > discussion > > > soon. > > > > > > On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev < > zaleslaw@gmail.com> > > > wrote: > > > > > > > Yes, Model Export/Import for ML will be finished, now it's ready, > but under > > > > testing on my side. > > > > > > > > ср, 11 нояб. 2020 г. в 16:08, Nikolay Izhikov : > > > > > > > > > I suggest to include CDC feature to the 2.10 scope. > > > > > > > > > > > 11 нояб. 2020 г., в 16:06, Maxim Muzafarov > > > > > написал(а): > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > Can you clarify the issue statuses according to the Apache Ignite > > > > > > Roadmap [1] and the 2.10 Apache Ignite Release? Here are some > major > > > > > > issues which are expected to be included in 2.10 with the unknown > > > > > > status: > > > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > > Vinogradov, Ivan Daschinskiy) > > > > > > Will all related issues be included in the 2.10? > > > > > > > > > > > > - Native persistence defragmentation [6][7] (Anton Kalashnikov, > Sergey > > > > > Chugunov) > > > > > > Are we on the last mile with this for 2.10? > > > > > > > > > > > > - Consistency-related improvements for atomic caches [3] (Alexey > > > > > Scherbakov) > > > > > > Do we have the JIRA issue? Will the issue be included in 2.10? > > > > > > > > > > > > - Tombstone objects during rebalancing [4] (Alexey Scherbakov) > > > > > > The issue [4] is in progress state. Will it be finished prior to > code > > > > > freeze? > > > > > > > > > > > > - SQL runtime statistics (Konstantin Orlov) > > > > > > Do we have an IEP for this or JIRA issue? > > > > > > > > > > > > - ML Model export/import [5] (Alexey Zinoviev) > > > > > > - Will the issue be finished? > > > > > > > > > > > > > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap > > > > > > [2] > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests > > > > > > [3] > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-12+Make+ATOMIC+Caches+Consistent+Again > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-11704 > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-6642 > > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-13143 > > > > > > [7] > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation > > > > > > > > > > > > On Tue, 10 Nov 2020 at 15:58, Maxim Muzafarov > > > > > wrote: > > > > > >> > > > > > >> Folks, > > > > > >> > > > > > >> I've created the release page on the Confluence. Feel free to > mail in > > > > > >> case of any errors. > > > > > >> > > > > > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10 > > > > > >> > > > > > >> On Fri, 6 Nov 2020 at 17:56, Maxim Muzafarov > > > > > wrote: > > > > > >>> > > > > > >>> Igniters, > > > > > >>> > > > > > >>> > > > > > >>> Let's finalize the discussion [1] about the next upcoming major > > > > Apache > > > > > >>> Ignite 2.10 release. The major improvements related to the > proposed > > > > > >>> release: > > > > > >>> - Improvements for partition clearing related parts > > > > > >>> - Add tracing of SQL queries. > > > > > >>> - CPP: Implement Cluster API > > > > > >>> - .NET: Thin client: Transactions > > > > > >>> - .NET: Thin Client: Continuous Query > > > > > >>> - Java Thin client Kubernetes discovery > > > > > >>> > > > > > >>> etc. > > > > > >>> Total: 166 RESOLVED issues [2]. > > > > > >>> > > > > > >>> > > > > > >>> Let's start the discussion about Time and Scope, and also I > propose > > > > > >>> myself as the release manager of the Apache Ignite 2.10. If > you'd > > > > like > > > > > >>> to lead this release, please, let us know, I see no problems > to chose > > > > > >>> a better candidate. > > > > > >>> > > > > > >>> > > > > > >>> Proposed release timeline: > > > > > >>> > > > > > >>> Scope Freeze: December 10, 2020 > > > > > >>> Code Freeze: December 24, 2020 > > > > > >>> Voting Date: January 18, 2021 > > > > >
Re: Tool for performance statistics reports
Hello, Igniters. I have implemented the profiling tool [1, 2]. It writes duration and other parameters of user operations (scan, SQL query, transactions, tasks, jobs, CQ, etc) to a local file. This info can be used in various cases. The main goal is to build the performance report to analyze the count and duration of user queries [3]. We already have the tracing with similar functionality but I think Ignite should have both tools - tracing and profiling. Because the tracing causes performance drop 52% [4] and can not be used for collecting statistics about all queries in production deployments. The performance drop of the profiling tool is less than 2% and it can be used in production. I have benchmarked the tracing and got the results: -2% when configured OpenCensusTracingSpi and all scopes disabled -52% for TX scope (IgnitePutTxBenchmark) -58% for SQL scope (IgniteSqlQueryBenchmark) Such a performance drop is significant to not use the tracing in production. I have considered the possibility to reuse the tracing API. If statistics collecting will be implemented with the TracingSpi then we get a performance drop due to: - Transferring tracing context over the network. - Using ThreadLocal for spans - Converting primitives and objects to string and vice versa. (API supports only String-based tags and values) - Generating span objects I have benchmarked implementations on the yardstick’s IgniteGetBenchmark. The tracing context transferring over the network was disabled. The results: - Tracing API implementation - 8% performance drop. - Proposed implementation - 2% performance drop. I think this is a significant drop and implementation with reuse tracing API should not be used. The cluster profiling should have as little performance drop as possible to be used in production. The tracing will be used for the detailed investigation. WDYT? The tool is ready to be reviewed [3, 5]. [1] https://issues.apache.org/jira/browse/IGNITE-12666 [2] https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool [3] https://github.com/apache/ignite-extensions/pull/16 [4] https://issues.apache.org/jira/secure/attachment/13016636/Tracing%20benchmarks.docx [5] https://github.com/apache/ignite/pull/7693 ср, 24 июн. 2020 г. в 23:31, Saikat Maitra : > > Hi Nikita, > > The changes in this PR looks good. > > https://github.com/apache/ignite-extensions/pull/16 > > Regards, > Saikat > > On Mon, Jun 22, 2020 at 12:03 PM Nikolay Izhikov > wrote: > > > Hello, Igniters. > > > > I think that inside Ignite core we should name this feature as > > «performance statistics» > > We already have «cache statistics». > > Data that is collected by performance statistics can be used not only for > > profiling but to solve other tasks. > > > > > > > 22 июня 2020 г., в 14:00, Nikita Amelchev > > написал(а): > > > > > > Hi, guys. > > > > > > I have mentioned components under the MIT license in the LICENSE file. > > > > > > Saikat, I have fixed PR according to your suggestions. Thanks for taking > > a look. > > > > -- Best wishes, Amelchev Nikita
[jira] [Created] (IGNITE-13825) Decimal columns in SQL result set have invalid precision and scale
Igor Sapego created IGNITE-13825:
Summary: Decimal columns in SQL result set have invalid precision
and scale
Key: IGNITE-13825
URL: https://issues.apache.org/jira/browse/IGNITE-13825
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.9
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.10
If the SQL result set of contains Decimal column it now returns MAX_SHORT as
precision and MAX_USHORT as scale, no matter what is the precision and scale of
the original table column.
SQL:
{code:sql}
create table person(id int, name character(10), age decimal(3,0), primary key
(id));
{code}
Java (from internal component)
{code:java}
GridQueryFieldMetadata meta = kernal.query().getIndexing().resultMetaData(
"PUBLIC", "select age from person;"
).iterator().next();
assert meta.precision() == 3;
assert meta.scale() == 0;
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13824) Suspected: "Connection reset by peer" of Communication socket triggers FH
Ilya Kasnacheev created IGNITE-13824:
Summary: Suspected: "Connection reset by peer" of Communication
socket triggers FH
Key: IGNITE-13824
URL: https://issues.apache.org/jira/browse/IGNITE-13824
Project: Ignite
Issue Type: Bug
Components: networking
Affects Versions: 2.9
Reporter: Ilya Kasnacheev
I would expect a network error in tcp-comm-worker to never trigger a Failure
Hander, yet it happens:
{code}
[12/3/20 16:08:26:410 GMT] 00bd IgniteKernal W Possible too long JVM
pause: 2418 milliseconds.
[12/3/20 16:08:27:465 GMT] 00c5 TcpCommunicat W Client disconnected
abruptly due to network connection loss or because the connection was left open
on application shutdown. [cls=class o.a.i.i.util.nio.GridNioException,
msg=Connection reset by peer]
[12/3/20 16:08:27:411 GMT] 00c5 TcpCommunicat E Failed to process
selector key [ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=0, bytesRcvd=48849402273,
bytesSent=15994664546, bytesRcvd0=54446, bytesSent0=102, select=true,
super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null,
finished=false, heartbeatTs=1607011706410, hashCode=433635054,
interrupted=false, runner=grid-nio-worker-tcp-comm-0-#51]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=9025120, resendCnt=0,
rcvCnt=9025150, sentCnt=9025152, reserved=true, lastAck=9025120,
nodeLeft=false, node=TcpDiscoveryNode [id=b3ca311e-077f-42a5-884a-807b539730b6,
consistentId=10.60.46.12:48500, addrs=ArrayList [10.60.46.12],
sockAddrs=HashSet [hex-wgc-p-web02/10.60.46.12:48500], discPort=48500, order=1,
intOrder=1, lastExchangeTime=1607006097079, loc=false,
ver=2.9.0#20201015-sha1:70742da8, isClient=false], connected=false,
connectCnt=1, queueLimit=4096, reserveCnt=1, pairedConnections=false],
outRecovery=GridNioRecoveryDescriptor [acked=9025120, resendCnt=0,
rcvCnt=9025150, sentCnt=9025152, reserved=true, lastAck=9025120,
nodeLeft=false, node=TcpDiscoveryNode [id=b3ca311e-077f-42a5-884a-807b539730b6,
consistentId=10.60.46.12:48500, addrs=ArrayList [10.60.46.12],
sockAddrs=HashSet [hex-wgc-p-web02/10.60.46.12:48500], discPort=48500, order=1,
intOrder=1, lastExchangeTime=1607006097079, loc=false,
ver=2.9.0#20201015-sha1:70742da8, isClient=false], connected=false,
connectCnt=1, queueLimit=4096, reserveCnt=1, pairedConnections=false],
closeSocket=true,
outboundMessagesQueueSizeMetric=o.a.i.i.processors.metric.impl.LongAdderMetric@69a257d1,
super=GridNioSessionImpl [locAddr=/10.223.132.3:52550,
rmtAddr=/10.60.46.12:48100, createTime=1607006097572, closeTime=0,
bytesSent=15994657850, bytesRcvd=48849402273, bytesSent0=102, bytesRcvd0=54446,
sndSchedTime=1607006097572, lastSndTime=1607011706410,
lastRcvTime=1607011706410, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=o.a.i.i.util.nio.GridDirectParser@93200255, directMode=true],
GridConnectionBytesVerifyFilter], accepted=false, markedForClose=false]]]
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:51)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:235)
at sun.nio.ch.IOUtil.read(IOUtil.java:204)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:394)
at
org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1330)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2472)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2239)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1880)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:822)
[12/3/20 16:08:44:437 GMT] 00c4 SystemOut O [16:08:44] Possible failure
suppressed accordingly to a configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=tcp-comm-worker,
igniteInstanceName=null, finished=false, heartbeatTs=1607011706420]]]
[12/3/20 16:08:44:436 GMT] 00c4 W
java.util.logging.LogManager$RootLogger log Possible failure suppressed
accordingly to a configured handler [hnd=StopNodeOrHaltFailureHandler
[tryStop=false, timeout=0,
[jira] [Created] (IGNITE-13823) WAL iterators require WRITE permissions
Ivan Bessonov created IGNITE-13823: -- Summary: WAL iterators require WRITE permissions Key: IGNITE-13823 URL: https://issues.apache.org/jira/browse/IGNITE-13823 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov org.apache.ignite.internal.processors.cache.persistence.wal.FileDescriptor#toIO uses default permissions, i.e. "CREATE, READ, WRITE" -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Folks, I propose to shift a bit the release date since 2.9.1 has not released yet. Scope Freeze: December 28, 2020 Code Freeze: December 28, 2020 Voting Date: January 25, 2021 Release Date: February 1, 2021 WDYT? On Tue, 17 Nov 2020 at 12:59, Maxim Muzafarov wrote: > > Folks, > > I've marked all the valuable features of 2.10 release with an > appropriate label. Please, let me know if I've missed anything. > > Here is the link to the JIRA: > https://s.apache.org/1hyfu > > > On Thu, 12 Nov 2020 at 12:28, Anton Vinogradov wrote: > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > Vinogradov, Ivan Daschinskiy) > > > Will all related issues be included in the 2.10? > > We're at the final preparations phase. Going to start the merge discussion > > soon. > > > > On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev > > wrote: > > > > > Yes, Model Export/Import for ML will be finished, now it's ready, but > > > under > > > testing on my side. > > > > > > ср, 11 нояб. 2020 г. в 16:08, Nikolay Izhikov : > > > > > > > I suggest to include CDC feature to the 2.10 scope. > > > > > > > > > 11 нояб. 2020 г., в 16:06, Maxim Muzafarov > > > > написал(а): > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > Can you clarify the issue statuses according to the Apache Ignite > > > > > Roadmap [1] and the 2.10 Apache Ignite Release? Here are some major > > > > > issues which are expected to be included in 2.10 with the unknown > > > > > status: > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > Vinogradov, Ivan Daschinskiy) > > > > > Will all related issues be included in the 2.10? > > > > > > > > > > - Native persistence defragmentation [6][7] (Anton Kalashnikov, Sergey > > > > Chugunov) > > > > > Are we on the last mile with this for 2.10? > > > > > > > > > > - Consistency-related improvements for atomic caches [3] (Alexey > > > > Scherbakov) > > > > > Do we have the JIRA issue? Will the issue be included in 2.10? > > > > > > > > > > - Tombstone objects during rebalancing [4] (Alexey Scherbakov) > > > > > The issue [4] is in progress state. Will it be finished prior to code > > > > freeze? > > > > > > > > > > - SQL runtime statistics (Konstantin Orlov) > > > > > Do we have an IEP for this or JIRA issue? > > > > > > > > > > - ML Model export/import [5] (Alexey Zinoviev) > > > > > - Will the issue be finished? > > > > > > > > > > > > > > > [1] > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap > > > > > [2] > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests > > > > > [3] > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-12+Make+ATOMIC+Caches+Consistent+Again > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-11704 > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-6642 > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-13143 > > > > > [7] > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation > > > > > > > > > > On Tue, 10 Nov 2020 at 15:58, Maxim Muzafarov > > > wrote: > > > > >> > > > > >> Folks, > > > > >> > > > > >> I've created the release page on the Confluence. Feel free to mail in > > > > >> case of any errors. > > > > >> > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10 > > > > >> > > > > >> On Fri, 6 Nov 2020 at 17:56, Maxim Muzafarov > > > wrote: > > > > >>> > > > > >>> Igniters, > > > > >>> > > > > >>> > > > > >>> Let's finalize the discussion [1] about the next upcoming major > > > Apache > > > > >>> Ignite 2.10 release. The major improvements related to the proposed > > > > >>> release: > > > > >>> - Improvements for partition clearing related parts > > > > >>> - Add tracing of SQL queries. > > > > >>> - CPP: Implement Cluster API > > > > >>> - .NET: Thin client: Transactions > > > > >>> - .NET: Thin Client: Continuous Query > > > > >>> - Java Thin client Kubernetes discovery > > > > >>> > > > > >>> etc. > > > > >>> Total: 166 RESOLVED issues [2]. > > > > >>> > > > > >>> > > > > >>> Let's start the discussion about Time and Scope, and also I propose > > > > >>> myself as the release manager of the Apache Ignite 2.10. If you'd > > > like > > > > >>> to lead this release, please, let us know, I see no problems to > > > > >>> chose > > > > >>> a better candidate. > > > > >>> > > > > >>> > > > > >>> Proposed release timeline: > > > > >>> > > > > >>> Scope Freeze: December 10, 2020 > > > > >>> Code Freeze: December 24, 2020 > > > > >>> Voting Date: January 18, 2021 > > > > >>> Release Date: January 25, 2021 > > > > >>> > > > > >>> > > > > >>> Proposed release scope: > > > > >>> [2] > > > > >>> > > > > >>> > > > > >>> WDYT? > > > > >>> > > > > >>> > > > > >>> [1] > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/2-9-1-release-proposal-tp49769p49867.html > > > > >>> [2] > > > > > > >
[jira] [Created] (IGNITE-13822) NPE in SQL query [with xxx as (select xxx)]
Alexandr Shapkin created IGNITE-13822:
-
Summary: NPE in SQL query [with xxx as (select xxx)]
Key: IGNITE-13822
URL: https://issues.apache.org/jira/browse/IGNITE-13822
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.9
Reporter: Alexandr Shapkin
We use '*with xxx as (select xxx)* ', which works very fine in 2.8.1 and other
past release versions. After we upgrade to 2.9.0, such SQL starts to throw an
exception.
Note, the SQL works fine while Ignite just started. The error happens after
Ignite runs a while. And after that, the error seems to happen every time.
{code:java}
args=Object[] [], stmtType=SELECT_STATEMENT_TYPE, autoCommit=true,
partResReq=false, super=JdbcRequest [type=2, reqId=790418]]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
to parse query. General error: "java.lang.NullPointerException" [5-197]
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:194)
at
org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:355)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:222)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1071)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2779)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2775)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3338)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$2(GridQueryProcessor.java:2795)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2833)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2769)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2727)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:647)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:320)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:202)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:56)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException" [5-197]
at
org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at
org.h2.message.DbException.toSQLException(DbException.java:280)
at org.h2.message.TraceObject.logAndConvert(TraceObject.java:357)
at
org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:697)
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
... 26 more
Caused by: java.lang.NullPointerException
at
