[jira] [Created] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from serve
Alexandr Shapkin created IGNITE-16038: - Summary: Java Thin Client: Retrieve binary configuration from serve Key: IGNITE-16038 URL: https://issues.apache.org/jira/browse/IGNITE-16038 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.11 Reporter: Alexandr Shapkin Thin clients require manual binary configuration currently. Settings like compact footer and simple/full name mapper should be set to match the cluster settings. Extend the protocol to retrieve those settings automatically on start. I.e. it's impossible to read a value inserted by a thick client with java thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16038: -- Summary: Java Thin Client: Retrieve binary configuration from server (was: Java Thin Client: Retrieve binary configuration from serve) > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452403#comment-17452403 ] Alexandr Shapkin commented on IGNITE-16038: --- [~alex_pl] Yes, that's correct, it is a potential compatibility break. I also find the case when a client can't read a value inserted by a thick client or vice versa counterintuitive. We just don't have any warnings or reasons that explain the problem with having different compact footers. Consider this: * a user starts a vanilla server node and performs cache#put(myKey, myVal) * then it starts a default thin client and is trying to get a value with thinCache.get(myKey) * ??? why there is no value found, seems like Ignite is broken... In a very safe implementation, we might yield a WARN in a client's (java version don't have it yet if I remember correctly) or server's logs with respect to the binary configuration mismatch and provide a user with the right direction on how to fix that. But I'd say we need to implement the change just like it's written in IEP and set compactFooter=serverValue. Well, we might add just another Ignite property to disable this feature and some announcements in release docs are welcome. Anyway, my biggest concern is that - it's very confusing for the end-users. WDYT? > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452403#comment-17452403 ] Alexandr Shapkin edited comment on IGNITE-16038 at 12/2/21, 1:16 PM: - [~alex_pl] Yes, that's correct, it is a potential compatibility break. I also find the case when a client can't read a value inserted by a thick client or vice versa counterintuitive. We just don't have any warnings or reasons that explain the problem with having different compact footers. Consider this: * a user starts a vanilla server node and performs cache#put(myKey, myVal) [compactFooter=true] * then it starts a default thin client and is trying to get a value with thinCache.get(myKey) [compactFooter=false] * ??? why there is no value found, seems like Ignite is broken... In a very safe implementation, we might yield a WARN in a client's (java version don't have it yet if I remember correctly) or server's logs with respect to the binary configuration mismatch and provide a user with the right direction on how to fix that. But I'd say we need to implement the change just like it's written in IEP and set compactFooter=serverValue. Well, we might add just another Ignite property to disable this feature and some announcements in release docs are welcome. Anyway, my biggest concern is that - it's very confusing for the end-users. WDYT? was (Author: ashapkin): [~alex_pl] Yes, that's correct, it is a potential compatibility break. I also find the case when a client can't read a value inserted by a thick client or vice versa counterintuitive. We just don't have any warnings or reasons that explain the problem with having different compact footers. Consider this: * a user starts a vanilla server node and performs cache#put(myKey, myVal) * then it starts a default thin client and is trying to get a value with thinCache.get(myKey) * ??? why there is no value found, seems like Ignite is broken... In a very safe implementation, we might yield a WARN in a client's (java version don't have it yet if I remember correctly) or server's logs with respect to the binary configuration mismatch and provide a user with the right direction on how to fix that. But I'd say we need to implement the change just like it's written in IEP and set compactFooter=serverValue. Well, we might add just another Ignite property to disable this feature and some announcements in release docs are welcome. Anyway, my biggest concern is that - it's very confusing for the end-users. WDYT? > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452408#comment-17452408 ] Alexandr Shapkin commented on IGNITE-16038: --- Wow, that sounds good. Could you please share a ticket number with the planned compactFooter change? If it has not been created yet, we might use this ticket for that change. > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452420#comment-17452420 ] Alexandr Shapkin commented on IGNITE-16038: --- Aleksey, thanks a lot for sorting this out! > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15197) Incorrect code snippet for Azure Kubernetes Deployment
Alexandr Shapkin created IGNITE-15197:
-
Summary: Incorrect code snippet for Azure Kubernetes Deployment
Key: IGNITE-15197
URL: https://issues.apache.org/jira/browse/IGNITE-15197
Project: Ignite
Issue Type: Bug
Components: documentation
Reporter: Alexandr Shapkin
Assignee: Nikita Safonov
See the docs: [
https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment|https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment]
h3. Creating ConfigMap for Node Configuration File
Two tabs: Configuration without persistence and Configuration with persistence
Need to fix "node-configuration.xml" to be a valid XML file, like this one for
"Configuration without persistence"
{code:java}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
I.e. all code samples have to include
{code:java}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
...
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
Alexandr Shapkin created IGNITE-15204: - Summary: SQL exception to be handled by thin clients [CPP] Key: IGNITE-15204 URL: https://issues.apache.org/jira/browse/IGNITE-15204 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Alexandr Shapkin It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
[ https://issues.apache.org/jira/browse/IGNITE-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-15204: -- Description: It would be nice to have meaningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND Looks like the easiest way would be to wait for Ignite 3.0 release with the new thin client protocol, but I think we can make some extension to the 2.x protocol as well. was: It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND Looks like the easiest way would be to wait for Ignite 3.0 release with the new thin clint protocol, but I think we can make some extension to the 2.x protocol as well. > SQL exception to be handled by thin clients [CPP] > - > > Key: IGNITE-15204 > URL: https://issues.apache.org/jira/browse/IGNITE-15204 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Alexandr Shapkin >Priority: Major > > It would be nice to have meaningful error descriptions (like using ODBC) > instead of general ones. > For sample, working with SQL from a thin client it's impossible to get these > errors: > Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, > Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > > Looks like the easiest way would be to wait for Ignite 3.0 release with the > new thin client protocol, but I think we can make some extension to the 2.x > protocol as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
[ https://issues.apache.org/jira/browse/IGNITE-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-15204: -- Description: It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND Looks like the easiest way would be to wait for Ignite 3.0 release with the new thin clint protocol, but I think we can make some extension to the 2.x protocol as well. was: It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > SQL exception to be handled by thin clients [CPP] > - > > Key: IGNITE-15204 > URL: https://issues.apache.org/jira/browse/IGNITE-15204 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Alexandr Shapkin >Priority: Major > > It would be nice to have meningful error descriptions (like using ODBC) > instead of general ones. > For sample, working with SQL from a thin client it's impossible to get these > errors: > Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, > Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > > Looks like the easiest way would be to wait for Ignite 3.0 release with the > new thin clint protocol, but I think we can make some extension to the 2.x > protocol as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-16568) Kubernetes cluster might split apart on initialization
Alexandr Shapkin created IGNITE-16568: - Summary: Kubernetes cluster might split apart on initialization Key: IGNITE-16568 URL: https://issues.apache.org/jira/browse/IGNITE-16568 Project: Ignite Issue Type: Bug Components: networking Reporter: Alexandr Shapkin The issue is mostly about Kubernetes/Openshift deployment but could also be true for other scenarios relying on external services (AWS?). Consider the following case: multiple nodes (PODs) were started simultaneously and all of them are trying to locate if there are other nodes available using *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered IPs. Since there is no delay or retry attempt, all nodes could be returned with an empty IPs list and decide to be a coordinator, i.e. to start multiple independent grids. Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a configurable delay or repetitions counter to check if there is a non-empty list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16568) Kubernetes cluster might split apart on initialization
[ https://issues.apache.org/jira/browse/IGNITE-16568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16568: -- Description: The issue is mostly about Kubernetes/Openshift deployment but could also affect other scenarios relying on external services (AWS?). Consider the following case: multiple nodes (PODs) were started simultaneously and all of them are trying to locate if there are other nodes available using *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered IPs. Since there is no delay or retry attempt, all nodes could be returned with an empty IPs list and decide to be a coordinator, i.e. to start multiple independent grids. Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a configurable delay or repetitions counter to check if there is a non-empty list of available IPs. was: The issue is mostly about Kubernetes/Openshift deployment but could also be true for other scenarios relying on external services (AWS?). Consider the following case: multiple nodes (PODs) were started simultaneously and all of them are trying to locate if there are other nodes available using *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered IPs. Since there is no delay or retry attempt, all nodes could be returned with an empty IPs list and decide to be a coordinator, i.e. to start multiple independent grids. Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a configurable delay or repetitions counter to check if there is a non-empty list of available IPs. > Kubernetes cluster might split apart on initialization > -- > > Key: IGNITE-16568 > URL: https://issues.apache.org/jira/browse/IGNITE-16568 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.11.1 >Reporter: Alexandr Shapkin >Priority: Major > Labels: Kubernetes > > The issue is mostly about Kubernetes/Openshift deployment but could also > affect other scenarios relying on external services (AWS?). > Consider the following case: multiple nodes (PODs) were started > simultaneously and all of them are trying to locate if there are other nodes > available using > *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered > IPs. Since there is no delay or retry attempt, all nodes could be returned > with an empty IPs list and decide to be a coordinator, i.e. to start multiple > independent grids. > > Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a > configurable delay or repetitions counter to check if there is a non-empty > list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16568) Kubernetes cluster might split apart on initialization
[ https://issues.apache.org/jira/browse/IGNITE-16568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16568: -- Affects Version/s: 2.11.1 > Kubernetes cluster might split apart on initialization > -- > > Key: IGNITE-16568 > URL: https://issues.apache.org/jira/browse/IGNITE-16568 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.11.1 >Reporter: Alexandr Shapkin >Priority: Major > Labels: Kubernetes > > The issue is mostly about Kubernetes/Openshift deployment but could also be > true for other scenarios relying on external services (AWS?). > Consider the following case: multiple nodes (PODs) were started > simultaneously and all of them are trying to locate if there are other nodes > available using > *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered > IPs. Since there is no delay or retry attempt, all nodes could be returned > with an empty IPs list and decide to be a coordinator, i.e. to start multiple > independent grids. > > Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a > configurable delay or repetitions counter to check if there is a non-empty > list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16568) Kubernetes cluster might split apart on initialization
[ https://issues.apache.org/jira/browse/IGNITE-16568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16568: -- External issue URL: https://stackoverflow.com/questions/71118869/openshift-k8s-issue-with-project-pods-not-joining-same-grid-but-rather-create-m Labels: Kubernetes (was: ) > Kubernetes cluster might split apart on initialization > -- > > Key: IGNITE-16568 > URL: https://issues.apache.org/jira/browse/IGNITE-16568 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Alexandr Shapkin >Priority: Major > Labels: Kubernetes > > The issue is mostly about Kubernetes/Openshift deployment but could also be > true for other scenarios relying on external services (AWS?). > Consider the following case: multiple nodes (PODs) were started > simultaneously and all of them are trying to locate if there are other nodes > available using > *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered > IPs. Since there is no delay or retry attempt, all nodes could be returned > with an empty IPs list and decide to be a coordinator, i.e. to start multiple > independent grids. > > Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a > configurable delay or repetitions counter to check if there is a non-empty > list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16435) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-16435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin resolved IGNITE-16435. --- Resolution: Fixed [~hoter] Thanks for the contribution! > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-16435 > URL: https://issues.apache.org/jira/browse/IGNITE-16435 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Trivial > > Please add an event to [https://ignite.apache.org/events.html] > Event Date: February, 16 > h1. Apache Ignite Community Gathering: Ignite 3 Alpha 4 > During this community gathering, we will discuss the latest Ignite releases: > - Apache Ignite 2.12 overview > - Apache Ignite 3 Alpha 4: The Next Milestone > - Transactions API in Apache Ignite 3 > ___ > Maxim Timonin, Apache Ignite Committer and Software Engineer at SberTech will > present a brief overview of the Apache Ignite 2.12 release. > Apache Ignite 3 Alpha 4: The Next Milestone > Apache Ignite 3 is the next generation of the Apache Ignite platform. Ignite > 3 modernizes and improves Ignite’s usability while retaining its power and > flexibility. The Alpha 4 build is the latest release of the Ignite 3 project. > Val Kulichenko, Apache Ignite PMC member and the Ignite 3.0 Release manager, > will present the Ignite 3 Alpha 4 overview, including new features Object > Mappings for Table Views and DDL. > Transactions API in Ignite 3 > Alexey Scherbakov, Apache Ignite Committer, and architect at GridGain will > show Ignite 3 just released in Alpha 4 build transactional API. We will take > a glance over: > - a transaction lifecycle > - how to manage transactions > - examples of synchronous and asynchronous transactions > Learn more: > [https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/283606359] > Сhange the text on the banner [Apache Ignite Documentation | Ignite > Documentation|https://ignite.apache.org/docs/latest/] > from: > [Ignite Summit: Сloud Edition | Using Ignite In The Cloud - Watch On Demand > →|https://ignite-summit.org/] > to: > Apache Ignite Community Gathering: Ignite 3 Alpha 4. Join us! (link to > [Apache Ignite Community Gathering: Ignite 3 Alpha 4 | > Meetup|https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/283606359]) > h1. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin reassigned IGNITE-18302:
-
Assignee: Andrey Novikov (was: Alexandr Shapkin)
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Alexandr Shapkin
>Assignee: Andrey Novikov
>Priority: Major
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache,
> but it’s an internal non-static class, having a reference to the parent
> [\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
> Hence, during the serialization Ignite also writes {{{}name=this$0,
> type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
> {{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
> * we are serializing and saving internal utility data, like}} Ignite
> ignite{}}}, {{private IndexResolver indexResolver}} etc
> * one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
> {{IgniteCache sessions}} that basically keeps every
> session so far leading to a StackOverflow error after some time.
>
> {code:java}
> [2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
> Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
> msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
> topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
> ~[ignite-core-8.8.22.jar:8.8.22] 4 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
> ~[ignite-core-8.8.22.jar:8.8.22] 5 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
> ~[ignite-core-8.8.22.jar:8.8.22] 6 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 7 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
> ~[ignite-core-8.8.22.jar:8.8.22] 10 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
> ~[ignite-core-8.8.22.jar:8.8.22] 11 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
> ~[ignite-core-8.8.22.jar:8.8.22] 12 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
> ~[ignite-core-8.8.22.jar:8.8.22] 13 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 14 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
> 17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
> system error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.StackOverflowError]]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762738#comment-17762738
]
Alexandr Shapkin commented on IGNITE-18302:
---
[~anovikov] LGTM in general, please fix a couple of minor things in PR before
merging.
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Affects Versions: 2.15
>Reporter: Alexandr Shapkin
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.16
>
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache,
> but it’s an internal non-static class, having a reference to the parent
> [\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
> Hence, during the serialization Ignite also writes {{{}name=this$0,
> type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
> {{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
> * we are serializing and saving internal utility data, like}} Ignite
> ignite{}}}, {{private IndexResolver indexResolver}} etc
> * one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
> {{IgniteCache sessions}} that basically keeps every
> session so far leading to a StackOverflow error after some time.
>
> {code:java}
> [2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
> Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
> msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
> topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
> ~[ignite-core-8.8.22.jar:8.8.22] 4 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
> ~[ignite-core-8.8.22.jar:8.8.22] 5 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
> ~[ignite-core-8.8.22.jar:8.8.22] 6 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 7 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
> ~[ignite-core-8.8.22.jar:8.8.22] 10 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
> ~[ignite-core-8.8.22.jar:8.8.22] 11 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
> ~[ignite-core-8.8.22.jar:8.8.22] 12 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
> ~[ignite-core-8.8.22.jar:8.8.22] 13 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 14 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
> 17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
> system error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.StackOverflowError]]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528337#comment-17528337
]
Alexandr Shapkin commented on IGNITE-16124:
---
[~NSAmelchev] [~Mmuzaf] guys, do you know if there are any plans on release?
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Michael Reiche
>Assignee: Andrey Belyaev
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
>
> If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
> deleteAll is flagged
> java: name clash: deleteAll(java.lang.Iterable com.example.ignite.EmployeeDTO>) in
> org.springframework.data.repository.CrudRepository and
> deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository have the same
> erasure, yet neither overrides the other
> And 2.2-ext gives the following:
> org.apache.ignite
> ignite-spring-data-2.2-ext
> 1.0.0
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata22.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
> package com.example.ignite;
> import org.apache.ignite.springdata.repository.IgniteRepository;
> import org.apache.ignite.springdata.repository.config.RepositoryConfig;
> @RepositoryConfig(cacheName = "myCache")
> public interface EmployeeRepository extends
> IgniteRepository
> { EmployeeDTO getEmployeeDTOById(ID id); }
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528345#comment-17528345
]
Alexandr Shapkin commented on IGNITE-16124:
---
[~NSAmelchev] Thanks for the clarification!
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Michael Reiche
>Assignee: Andrey Belyaev
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
>
> If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
> deleteAll is flagged
> java: name clash: deleteAll(java.lang.Iterable com.example.ignite.EmployeeDTO>) in
> org.springframework.data.repository.CrudRepository and
> deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository have the same
> erasure, yet neither overrides the other
> And 2.2-ext gives the following:
> org.apache.ignite
> ignite-spring-data-2.2-ext
> 1.0.0
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata22.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
> package com.example.ignite;
> import org.apache.ignite.springdata.repository.IgniteRepository;
> import org.apache.ignite.springdata.repository.config.RepositoryConfig;
> @RepositoryConfig(cacheName = "myCache")
> public interface EmployeeRepository extends
> IgniteRepository
> { EmployeeDTO getEmployeeDTOById(ID id); }
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17147) Ignite should not talk to kubernetes default service to get its own IP
[ https://issues.apache.org/jira/browse/IGNITE-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557442#comment-17557442 ] Alexandr Shapkin commented on IGNITE-17147: --- [~laptimus] Could you please elaborate on this task? What's you improvement suggestion? Am I right that you are referring to this configuration: [https://www.gridgain.com/sdk/latest/javadoc/org/apache/ignite/kubernetes/configuration/KubernetesConnectionConfiguration.html#setMasterUrl-java.lang.String-] and its default value - 'https://kubernetes.default.svc.cluster.local:443'? > Ignite should not talk to kubernetes default service to get its own IP > -- > > Key: IGNITE-17147 > URL: https://issues.apache.org/jira/browse/IGNITE-17147 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.11.1 > Environment: Kubernetes >Reporter: laptimus >Priority: Major > > Ignite should not talk to kubernetes default service to get its own IP > We have kubernetes cluster with calico network policies and seems like ignite > is the only application in our cluster that needs access to kubernetes > default service > I see this as a security risk > Please implement an alternative way in IP Finder as that the class that talks > to kubernetes default service to know pod IP address > > thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-18247) .NET: Thin 3.0: LINQ: Operators and functions
[ https://issues.apache.org/jira/browse/IGNITE-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652485#comment-17652485 ] Alexandr Shapkin commented on IGNITE-18247: --- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: LINQ: Operators and functions > - > > Key: IGNITE-18247 > URL: https://issues.apache.org/jira/browse/IGNITE-18247 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement support for operators and functions in LINQ: > * Logic and arithmetic: ! + - * / = != % > * String functions: ToLower, ToUpper, Trim, Contains, etc (see > *MethodVisitor*) > * Date functions (see *MethodVisitor*) > * Math (Abs, Exp, Log, Pow, etc - see *MethodVisitor*) > * Regex -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18427) .NET: Platform cache is not updated when ReadFromBackup is true
[ https://issues.apache.org/jira/browse/IGNITE-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652820#comment-17652820 ] Alexandr Shapkin commented on IGNITE-18427: --- [~ptupitsyn], looks good to me, thanks! > .NET: Platform cache is not updated when ReadFromBackup is true > --- > > Key: IGNITE-18427 > URL: https://issues.apache.org/jira/browse/IGNITE-18427 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.14 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ise > Fix For: 2.15 > > Attachments: IgniteReproducer.csproj, Test.cs > > > See attached reproducer. Client 2 has stale value when *ReadFromBackup = > true*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17724) .NET: TestPrimaryNodeLeaveClearsPlatformCache is flaky
[ https://issues.apache.org/jira/browse/IGNITE-17724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652294#comment-17652294 ] Alexandr Shapkin commented on IGNITE-17724: --- LGTM > .NET: TestPrimaryNodeLeaveClearsPlatformCache is flaky > -- > > Key: IGNITE-17724 > URL: https://issues.apache.org/jira/browse/IGNITE-17724 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Apache.Ignite.Core.Tests.Cache.Platform.PlatformCacheTopologyChangeTest.TestPrimaryNodeLeaveClearsPlatformCache > is flaky. > https://ci.ignite.apache.org/test/-4466167631530075752?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18189) Merge ignite-spark 3.2 and 2.4 extensions into a single module
Alexandr Shapkin created IGNITE-18189: - Summary: Merge ignite-spark 3.2 and 2.4 extensions into a single module Key: IGNITE-18189 URL: https://issues.apache.org/jira/browse/IGNITE-18189 Project: Ignite Issue Type: Task Components: extensions Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin We need to do the following a) release ignite-spark 1.0.0 extension b) merge ignite-spark and ignite-spark-3.2 modules c) release ignite-spark 2.0.0 extension (with spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
Alexandr Shapkin created IGNITE-18302:
-
Summary: ignite-spring-sessions: IgniteSession serialization drags
its parent class
Key: IGNITE-18302
URL: https://issues.apache.org/jira/browse/IGNITE-18302
Project: Ignite
Issue Type: Bug
Components: extensions
Reporter: Alexandr Shapkin
In short, there is a bug in ignite-spring-session-ext implementation.
We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache, but
it’s an internal non-static class, having a reference to the parent
[{{{}IgniteIndexedSessionRepository{}}}] indirectly.
Hence, during the serialization Ignite also writes {{{}name=this$0,
type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
{{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
* we are serializing and saving internal utility data, like{{{} Ignite
ignite{}}}, {{private IndexResolver indexResolver}} etc
* one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
{{IgniteCache sessions}} that basically keeps every
session so far leading to a StackOverflow error after some time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-18302:
--
Description:
In short, there is a bug in ignite-spring-session-ext implementation.
We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache, but
it’s an internal non-static class, having a reference to the parent
[\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
Hence, during the serialization Ignite also writes {{{}name=this$0,
type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
{{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
* we are serializing and saving internal utility data, like}} Ignite
ignite{}}}, {{private IndexResolver indexResolver}} etc
* one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
{{IgniteCache sessions}} that basically keeps every
session so far leading to a StackOverflow error after some time.
{code:java}
[2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
~[ignite-core-8.8.22.jar:8.8.22] 4 at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
~[ignite-core-8.8.22.jar:8.8.22] 5 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
~[ignite-core-8.8.22.jar:8.8.22] 6 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
~[ignite-core-8.8.22.jar:8.8.22] 7 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
~[ignite-core-8.8.22.jar:8.8.22] 10 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
~[ignite-core-8.8.22.jar:8.8.22] 11 at
org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
~[ignite-core-8.8.22.jar:8.8.22] 12 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
~[ignite-core-8.8.22.jar:8.8.22] 13 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
~[ignite-core-8.8.22.jar:8.8.22] 14 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR,
err=java.lang.StackOverflowError]]{code}
was:
In short, there is a bug in ignite-spring-session-ext implementation.
We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache, but
it’s an internal non-static class, having a reference to the parent
[{{{}IgniteIndexedSessionRepository{}}}] indirectly.
Hence, during the serialization Ignite also writes {{{}name=this$0,
type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
{{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
* we are serializing and saving internal utility data, like{{{} Ignite
ignite{}}}, {{private IndexResolver indexResolver}} etc
* one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
{{IgniteCache sessions}} that basically keeps every
session so far leading to a StackOverflow error after some time.
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Alexandr Shapkin
>Priority: Major
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}}
[jira] [Assigned] (IGNITE-18315) [Extensions] Release Ignite Spring Extensions
[ https://issues.apache.org/jira/browse/IGNITE-18315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin reassigned IGNITE-18315: - Component/s: extensions Assignee: Alexandr Shapkin Description: We need to release Ithe following Ignite Spring extensions: - 2.0.0 (Spark 2.4) - 3.0.0 (Spark 3.2) > [Extensions] Release Ignite Spring Extensions > -- > > Key: IGNITE-18315 > URL: https://issues.apache.org/jira/browse/IGNITE-18315 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > > We need to release Ithe following Ignite Spring extensions: > - 2.0.0 (Spark 2.4) > - 3.0.0 (Spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18315) [Extensions] Release Ignite Spring Extensions
Alexandr Shapkin created IGNITE-18315: - Summary: [Extensions] Release Ignite Spring Extensions Key: IGNITE-18315 URL: https://issues.apache.org/jira/browse/IGNITE-18315 Project: Ignite Issue Type: Task Reporter: Alexandr Shapkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18189) Merge ignite-spark 3.2 and 2.4 extensions into a single module
[ https://issues.apache.org/jira/browse/IGNITE-18189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-18189: -- Fix Version/s: 2.14 > Merge ignite-spark 3.2 and 2.4 extensions into a single module > -- > > Key: IGNITE-18189 > URL: https://issues.apache.org/jira/browse/IGNITE-18189 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.14 > > > We need to do the following > a) release ignite-spark 1.0.0 extension > b) merge ignite-spark and ignite-spark-3.2 modules > c) release ignite-spark 2.0.0 extension (with spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19203) NPE on inserting data concurrently with table deletion
Alexandr Shapkin created IGNITE-19203:
-
Summary: NPE on inserting data concurrently with table deletion
Key: IGNITE-19203
URL: https://issues.apache.org/jira/browse/IGNITE-19203
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Alexandr Shapkin
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{{}}
{code:java}
{code}
{{四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748) }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19203) NPE on inserting data concurrently with table deletion
[
https://issues.apache.org/jira/browse/IGNITE-19203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-19203:
--
Description:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{code:java}
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748){code}
test code：
{{}}
{code:java}
public class StartServer {
public static void main(String[] args)
{ Ignite ignite = Ignition.start(); } }{code}
{{}}
was:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{{}}
{code:java}
{code}
{{四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
[jira] [Updated] (IGNITE-19203) NPE on inserting data concurrently with table deletion
[
https://issues.apache.org/jira/browse/IGNITE-19203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-19203:
--
Description:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{code:java}
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748){code}
test code：
{code:java}
public class StartServer {
public static void main(String[] args)
{ Ignite ignite = Ignition.start(); } }{code}
{code:java}
public class StartClient01 {
public static void main(String[] args) {
Ignition.setClientMode(true);
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache("dummy");
cache.query(new SqlFieldsQuery("CREATE TABLE PRODUCT (" +
" ID INT(11)," +
" NAME CHAR(35)," +
" PRODUCTCODE CHAR(10)," +
" DISTRICT CHAR(100)," +
" NUMBER INT(11)," +
" PRIMARY KEY (ID)" +
") WITH \"TEMPLATE=REPLICATED, CACHE_NAME=PRODUCT\";"));
for (int i = 1; i <= 100; ++i) {
cache.query(new SqlFieldsQuery("INSERT INTO PRODUCT (ID, NAME,
PRODUCTCODE, DISTRICT, NUMBER) VALUES (?, ?, ?, ?, ?);")
.setArgs(i, "product" + i, "p" + i, "a product",
100)).getAll();
System.out.println(i);
}
}
} {code}
{code:java}
public class StartClient02 {
public static void main(String[] args) {
Ignition.setClientMode(true);
[jira] [Updated] (IGNITE-19203) NPE on inserting data concurrently with table deletion
[
https://issues.apache.org/jira/browse/IGNITE-19203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-19203:
--
Description:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{code:java}
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748){code}
test code：
{code:java}
public class StartServer {
public static void main(String[] args)
{ Ignite ignite = Ignition.start(); } }{code}
{code:java}
public class StartClient01 {
public static void main(String[] args) {
Ignition.setClientMode(true);
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache("dummy");
cache.query(new SqlFieldsQuery("CREATE TABLE PRODUCT (" +
" ID INT(11)," +
" NAME CHAR(35)," +
" PRODUCTCODE CHAR(10)," +
" DISTRICT CHAR(100)," +
" NUMBER INT(11)," +
" PRIMARY KEY (ID)" +
") WITH \"TEMPLATE=REPLICATED, CACHE_NAME=PRODUCT\";"));
for (int i = 1; i <= 100; ++i) {
cache.query(new SqlFieldsQuery("INSERT INTO PRODUCT (ID, NAME,
PRODUCTCODE, DISTRICT, NUMBER) VALUES (?, ?, ?, ?, ?);")
.setArgs(i, "product" + i, "p" + i, "a product",
100)).getAll();
System.out.println(i);
}
}
} {code}
{{}}
{code:java}
public class StartClient02 {
public static void main(String[] args) {
[jira] [Assigned] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin reassigned IGNITE-18302:
-
Assignee: Alexandr Shapkin
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Major
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache,
> but it’s an internal non-static class, having a reference to the parent
> [\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
> Hence, during the serialization Ignite also writes {{{}name=this$0,
> type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
> {{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
> * we are serializing and saving internal utility data, like}} Ignite
> ignite{}}}, {{private IndexResolver indexResolver}} etc
> * one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
> {{IgniteCache sessions}} that basically keeps every
> session so far leading to a StackOverflow error after some time.
>
> {code:java}
> [2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
> Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
> msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
> topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
> ~[ignite-core-8.8.22.jar:8.8.22] 4 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
> ~[ignite-core-8.8.22.jar:8.8.22] 5 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
> ~[ignite-core-8.8.22.jar:8.8.22] 6 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 7 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
> ~[ignite-core-8.8.22.jar:8.8.22] 10 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
> ~[ignite-core-8.8.22.jar:8.8.22] 11 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
> ~[ignite-core-8.8.22.jar:8.8.22] 12 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
> ~[ignite-core-8.8.22.jar:8.8.22] 13 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 14 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
> 17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
> system error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.StackOverflowError]]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-20139: -- Description: We tried to use machine learning capabilities, and discovered a bug in implementation of Random Forest. When comparing Ignite's output with python prototype (scikit-learn lib), we noticed that Ignite's predictions have much lower accuracy despite using the same data set and model parameters. Further investigation showed that Ignite generates decision trees that kinda "loop". The tree starts checking the same condition over and over until it reaches the maximum tree depth. I've attached a standalone reproducer which uses a small excerpt of our data set. It loads data from the csv file, then performs the training of the model for just 1 tree. Then the reproducer finds one of the looping branches and prints it. You will see that every single node in the branch uses the same feature, value and has then same calculated impurity. On my machine the code reproduces this issue 100% of time. I've also attached an example of the tree generated by python's scikit-learn on the same data set with the same parameters. In python the tree usually doesn't get deeper than 20 nodes. was: We tried to use GridGain's machine learning capabilities, and discovered a bug in GG's implementation of Random Forest. When comparing GG's output with python prototype (scikit-learn lib), we noticed that GG's predictions have much lower accuracy despite using the same data set and model parameters. Further investigation showed that GridGain generates decision trees that kinda "loop". The tree starts checking the same condition over and over until it reaches the maximum tree depth. I've attached a standalone reproducer which uses a small excerpt of our data set. It loads data from the csv file, then performs the training of the model for just 1 tree. Then the reproducer finds one of the looping branches and prints it. You will see that every single node in the branch uses the same feature, value and has then same calculated impurity. On my machine the code reproduces this issue 100% of time. I've also attached an example of the tree generated by python's scikit-learn on the same data set with the same parameters. In python the tree usually doesn't get deeper than 20 nodes. > RandomForestClassifierTrainer accuracy issue > > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Assignee: Igor Belyakov >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use machine learning capabilities, and discovered a bug in > implementation of Random Forest. When comparing Ignite's output with python > prototype (scikit-learn lib), we noticed that Ignite's predictions have much > lower accuracy despite using the same data set and model parameters. > Further investigation showed that Ignite generates decision trees that kinda > "loop". The tree starts checking the same condition over and over until it > reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750303#comment-17750303 ] Alexandr Shapkin commented on IGNITE-20139: --- [~zaleslaw] could you please take a look? Seems to be a valid issue alongside the attached reproducer. > RandomForestClassifierTrainer accuracy issue > > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use GridGain's machine learning capabilities, and discovered a > bug in GG's implementation of Random Forest. When comparing GG's output with > python prototype (scikit-learn lib), we noticed that GG's predictions have > much lower accuracy despite using the same data set and model parameters. > Further investigation showed that GridGain generates decision trees that > kinda "loop". The tree starts checking the same condition over and over until > it reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-20139: -- Summary: RandomForestClassifierTrainer accuracy issue (was: RandomForestClassifierTrainer is checking the same conditions) > RandomForestClassifierTrainer accuracy issue > > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use GridGain's machine learning capabilities, and discovered a > bug in GG's implementation of Random Forest. When comparing GG's output with > python prototype (scikit-learn lib), we noticed that GG's predictions have > much lower accuracy despite using the same data set and model parameters. > Further investigation showed that GridGain generates decision trees that > kinda "loop". The tree starts checking the same condition over and over until > it reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20139) RandomForestClassifierTrainer is checking the same conditions
Alexandr Shapkin created IGNITE-20139: - Summary: RandomForestClassifierTrainer is checking the same conditions Key: IGNITE-20139 URL: https://issues.apache.org/jira/browse/IGNITE-20139 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.15 Reporter: Alexandr Shapkin Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip We tried to use GridGain's machine learning capabilities, and discovered a bug in GG's implementation of Random Forest. When comparing GG's output with python prototype (scikit-learn lib), we noticed that GG's predictions have much lower accuracy despite using the same data set and model parameters. Further investigation showed that GridGain generates decision trees that kinda "loop". The tree starts checking the same condition over and over until it reaches the maximum tree depth. I've attached a standalone reproducer which uses a small excerpt of our data set. It loads data from the csv file, then performs the training of the model for just 1 tree. Then the reproducer finds one of the looping branches and prints it. You will see that every single node in the branch uses the same feature, value and has then same calculated impurity. On my machine the code reproduces this issue 100% of time. I've also attached an example of the tree generated by python's scikit-learn on the same data set with the same parameters. In python the tree usually doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer is checking the same conditions
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-20139: -- Attachment: random-forest.zip TreeSample2_Portfolio_Change.png > RandomForestClassifierTrainer is checking the same conditions > - > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use GridGain's machine learning capabilities, and discovered a > bug in GG's implementation of Random Forest. When comparing GG's output with > python prototype (scikit-learn lib), we noticed that GG's predictions have > much lower accuracy despite using the same data set and model parameters. > Further investigation showed that GridGain generates decision trees that > kinda "loop". The tree starts checking the same condition over and over until > it reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
