[jira] [Commented] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825164#comment-17825164 ] Igor Belyakov commented on IGNITE-20139: [~zaleslaw], could you please review the PR? > 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=17825163#comment-17825163
]
Igor Belyakov commented on IGNITE-20139:
The issue happens when one “pure“ node (with impurity{^}*{^} = 0) is presented
in the tree. We calculate an impurity only for children nodes and not for the
current node, as well as do not check whether the node is “pure“ and contains
just one label, due to that, the “bestSplit” calculation is executed for the
already “pure“ node, which decides that all items should be moved to the left
child node and no items to the right (leaf node), which gives 2 “pure“ children
nodes. Since we don’t calculate impurity for the current (parent) node the
{{parentNode.getImpurity() - split.get().getImpurity() > minImpurityDelta}}
check is always true, and we continue to split the already “pure“ node until
the max tree depth is reached.
The following changes were made to resolve the issue:
# Gain{^}**{^} calculation and check for the split were added.
# Node’s impurity check is added, once the impurity becomes 0 it means that
the node is “pure” and we don’t need to calculate a split for it.
# Gini impurity calculation was changed to {{(1 - sum(p^2))}} to get the
correct values in the range from 0 to 0.5 as required for the Gini index.
^*^ Impurity - is a value from 0 to 0.5, which shows whether the node is “pure“
(impurity = 0) having just 1 label or “impure” with impurity=0.5, which is the
worst scenario where the label ratio is 1:1.
^**^ Gain - is a difference between the parent node’s impurity and weighted
children nodes' impurity. The split which provides the maximum gain value is
considered the best. See [https://www.learndatasci.com/glossary/gini-impurity/]
> 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-21212) Increment and Decrement REST API documentation lists incorrect parameter
[ https://issues.apache.org/jira/browse/IGNITE-21212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811002#comment-17811002 ] Igor Belyakov commented on IGNITE-21212: [~igusev], the fix LGTM. > Increment and Decrement REST API documentation lists incorrect parameter > > > Key: IGNITE-21212 > URL: https://issues.apache.org/jira/browse/IGNITE-21212 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.16 >Reporter: Igor Belyakov >Assignee: Igor Gusev >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The documentation for the Increment/Decrement REST API endpoints > (https://ignite.apache.org/docs/latest/restapi#increment) contains > information regarding the "cacheName" parameter, which in fact this endpoint > doesn't have. > (see: > [https://github.com/apache/ignite/blob/ignite-2.16/modules/core/src/main/java/org/apache/ignite/internal/processors/rest/request/DataStructuresRequest.java]) > This redundant parameter could be confusing since with it the endpoint looks > like an API to increment/decrement the value stored in the cache, while in > fact it is related to the IgniteAtomicLong data structure. (see > [https://ignite.apache.org/docs/latest/data-structures/atomic-types]). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21212) Increment and Decrement REST API documentation lists incorrect parameter
[ https://issues.apache.org/jira/browse/IGNITE-21212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807838#comment-17807838 ] Igor Belyakov commented on IGNITE-21212: [~igusev], please see my comments in the PR, it's also required to remove the "cacheName" parameter from the URL examples for these endpoints. > Increment and Decrement REST API documentation lists incorrect parameter > > > Key: IGNITE-21212 > URL: https://issues.apache.org/jira/browse/IGNITE-21212 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.16 >Reporter: Igor Belyakov >Assignee: Igor Gusev >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The documentation for the Increment/Decrement REST API endpoints > (https://ignite.apache.org/docs/latest/restapi#increment) contains > information regarding the "cacheName" parameter, which in fact this endpoint > doesn't have. > (see: > [https://github.com/apache/ignite/blob/ignite-2.16/modules/core/src/main/java/org/apache/ignite/internal/processors/rest/request/DataStructuresRequest.java]) > This redundant parameter could be confusing since with it the endpoint looks > like an API to increment/decrement the value stored in the cache, while in > fact it is related to the IgniteAtomicLong data structure. (see > [https://ignite.apache.org/docs/latest/data-structures/atomic-types]). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21212) Increment and Decrement REST API documentation lists incorrect parameter
Igor Belyakov created IGNITE-21212: -- Summary: Increment and Decrement REST API documentation lists incorrect parameter Key: IGNITE-21212 URL: https://issues.apache.org/jira/browse/IGNITE-21212 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 2.16 Reporter: Igor Belyakov The documentation for the Increment/Decrement REST API endpoints (https://ignite.apache.org/docs/latest/restapi#increment) contains information regarding the "cacheName" parameter, which in fact this endpoint doesn't have. (see: [https://github.com/apache/ignite/blob/ignite-2.16/modules/core/src/main/java/org/apache/ignite/internal/processors/rest/request/DataStructuresRequest.java]) This redundant parameter could be confusing since with it the endpoint looks like an API to increment/decrement the value stored in the cache, while in fact it is related to the IgniteAtomicLong data structure. (see [https://ignite.apache.org/docs/latest/data-structures/atomic-types]). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11970: -- Assignee: Mikhail Petrov (was: Igor Belyakov) It seems like the buffer clean-up mechanism already was improved as a part of [IGNITE-13126] Refactor of Continuous Query buffers to reduce heap usage - ASF JIRA (apache.org) > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Time Spent: 3h 10m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-20139: -- Assignee: Igor Belyakov > 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 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] [Commented] (IGNITE-17640) Update Ignite Spring Data Dependency Snippet
[
https://issues.apache.org/jira/browse/IGNITE-17640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638416#comment-17638416
]
Igor Belyakov commented on IGNITE-17640:
[~shishkovilja], yes, it's required, you can find the issue discussion here:
https://stackoverflow.com/questions/73616274/apache-ignite-spring-data-extension-dependency-error/
> Update Ignite Spring Data Dependency Snippet
>
>
> Key: IGNITE-17640
> URL: https://issues.apache.org/jira/browse/IGNITE-17640
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Igor Belyakov
>Assignee: Igor Gusev
>Priority: Major
>
> Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
>
> [https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
> a dependency snippet on the Spring Data page should be updated:
>
> [https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
> as well as the "Apache Ignite Spring Data extension version" in the
> compatibility table.
> Also, the "org.springframework:spring-tx" dependency should be added to the
> dependency snippet:
> {code:java}
>
> org.springframework
> spring-tx
> ${spring.version}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18146) UriDeploymentSpi is unable to deploy Postgres JDBC driver
Igor Belyakov created IGNITE-18146:
--
Summary: UriDeploymentSpi is unable to deploy Postgres JDBC driver
Key: IGNITE-18146
URL: https://issues.apache.org/jira/browse/IGNITE-18146
Project: Ignite
Issue Type: Bug
Affects Versions: 2.14
Reporter: Igor Belyakov
Attachments: UriDeploymentTest.java
In the case of UriDeploymentSpi usage to deploy the Postgres JDBC driver
([https://jdbc.postgresql.org/download/postgresql-42.5.0.jar)] the
{{java.lang.NoClassDefFoundError}} error occurred:
{code:java}
SEVERE: Runtime error caught during grid runnable execution: IgniteSpiThread
[name=grid-uri-scanner-#2%srv1%-#37%srv1%]
java.lang.NoClassDefFoundError: org/osgi/framework/BundleActivator
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:550)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:458)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentClassLoader.loadClass(GridUriDeploymentClassLoader.java:56)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentFileResourceLoader.createResource(GridUriDeploymentFileResourceLoader.java:72)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentDiscovery.findResourcesInDirectory(GridUriDeploymentDiscovery.java:109)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentDiscovery.findResourcesInDirectory(GridUriDeploymentDiscovery.java:103)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentDiscovery.findResourcesInDirectory(GridUriDeploymentDiscovery.java:103)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentDiscovery.findResourcesInDirectory(GridUriDeploymentDiscovery.java:103)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentDiscovery.getClasses(GridUriDeploymentDiscovery.java:71)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentFileProcessor.processNoDescriptorFile(GridUriDeploymentFileProcessor.java:388)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentFileProcessor.processFile(GridUriDeploymentFileProcessor.java:108)
at
org.apache.ignite.spi.deployment.uri.UriDeploymentSpi$2.onNewOrUpdatedFile(UriDeploymentSpi.java:587)
at
org.apache.ignite.spi.deployment.uri.scanners.file.UriDeploymentFileScanner$URIContext.handleFile(UriDeploymentFileScanner.java:268)
at
org.apache.ignite.spi.deployment.uri.scanners.file.UriDeploymentFileScanner$URIContext.access$200(UriDeploymentFileScanner.java:135)
at
org.apache.ignite.spi.deployment.uri.scanners.file.UriDeploymentFileScanner$URIContext$1.handle(UriDeploymentFileScanner.java:178)
at
org.apache.ignite.spi.deployment.uri.scanners.GridDeploymentFolderScannerHelper.scanFolder(GridDeploymentFolderScannerHelper.java:49)
at
org.apache.ignite.spi.deployment.uri.scanners.GridDeploymentFolderScannerHelper.scanFolder(GridDeploymentFolderScannerHelper.java:52)
at
org.apache.ignite.spi.deployment.uri.scanners.file.UriDeploymentFileScanner$URIContext.scan(UriDeploymentFileScanner.java:183)
at
org.apache.ignite.spi.deployment.uri.scanners.file.UriDeploymentFileScanner$URIContext.access$000(UriDeploymentFileScanner.java:135)
at
org.apache.ignite.spi.deployment.uri.scanners.file.UriDeploymentFileScanner.scan(UriDeploymentFileScanner.java:73)
at
org.apache.ignite.spi.deployment.uri.scanners.UriDeploymentScannerManager$1.body(UriDeploymentScannerManager.java:115)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
Caused by: java.lang.ClassNotFoundException: org.osgi.framework.BundleActivator
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
at
org.apache.ignite.spi.deployment.uri.GridUriDeploymentClassLoader.loadClass(GridUriDeploymentClassLoader.java:61)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 29 more{code}
While in the case of adding jar into the classpath manually it's loaded
correctly.
Reproducer attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18094) Read-Through doesn't work for GET operations via REST API
[ https://issues.apache.org/jira/browse/IGNITE-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-18094: -- Assignee: Igor Belyakov > Read-Through doesn't work for GET operations via REST API > - > > Key: IGNITE-18094 > URL: https://issues.apache.org/jira/browse/IGNITE-18094 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.14 >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Major > Attachments: RestCacheReadThroughTest.java > > > GET operations using REST API skip reading from the CacheStore with enabled > Read-Through. > Reproducer attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18094) Read-Through doesn't work for GET operations via REST API
Igor Belyakov created IGNITE-18094: -- Summary: Read-Through doesn't work for GET operations via REST API Key: IGNITE-18094 URL: https://issues.apache.org/jira/browse/IGNITE-18094 Project: Ignite Issue Type: Bug Components: rest Affects Versions: 2.14 Reporter: Igor Belyakov Attachments: RestCacheReadThroughTest.java GET operations using REST API skip reading from the CacheStore with enabled Read-Through. Reproducer attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17640) Update Ignite Spring Data Dependency Snippet
[
https://issues.apache.org/jira/browse/IGNITE-17640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-17640:
---
Description:
Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
[https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
a dependency snippet on the Spring Data page should be updated:
[https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
as well as the "Apache Ignite Spring Data extension version" in the
compatibility table.
Also, the "org.springframework:spring-tx" dependency should be added to the
dependency snippet:
{code:java}
org.springframework
spring-tx
${spring.version}
{code}
was:
Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
[https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
a dependency snippet on the Spring Data page should be updated:
[https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
as well as "Apache Ignite Spring Data extension version" in the compatibility
table.
Also, the "org.springframework:spring-tx" dependency should be added to the
dependency snippet:
{code:java}
org.springframework
spring-tx
${spring.version}
{code}
> Update Ignite Spring Data Dependency Snippet
>
>
> Key: IGNITE-17640
> URL: https://issues.apache.org/jira/browse/IGNITE-17640
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Igor Belyakov
>Priority: Major
>
> Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
>
> [https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
> a dependency snippet on the Spring Data page should be updated:
>
> [https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
> as well as the "Apache Ignite Spring Data extension version" in the
> compatibility table.
> Also, the "org.springframework:spring-tx" dependency should be added to the
> dependency snippet:
> {code:java}
>
> org.springframework
> spring-tx
> ${spring.version}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17640) Update Ignite Spring Data Dependency Snippet
[
https://issues.apache.org/jira/browse/IGNITE-17640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-17640:
---
Description:
Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
[https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
a dependency snippet on the Spring Data page should be updated:
[https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
as well as "Apache Ignite Spring Data extension version" in the compatibility
table.
Also, the "org.springframework:spring-tx" dependency should be added to the
dependency snippet:
{code:java}
org.springframework
spring-tx
${spring.version}
{code}
was:
Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
[https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
a dependency snippet on the Spring Data page should be updated:
[https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
as well as "Apache Ignite Spring Data extension version" in the compatibility
table.
Also, the "org.springframework:spring-tx" dependency should be added to the
dependency snippet:
org.springframework
spring-tx
${spring.version}
> Update Ignite Spring Data Dependency Snippet
>
>
> Key: IGNITE-17640
> URL: https://issues.apache.org/jira/browse/IGNITE-17640
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Igor Belyakov
>Priority: Major
>
> Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
> [https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
> a dependency snippet on the Spring Data page should be updated:
> [https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
> as well as "Apache Ignite Spring Data extension version" in the compatibility
> table.
> Also, the "org.springframework:spring-tx" dependency should be added to the
> dependency snippet:
> {code:java}
>
> org.springframework
> spring-tx
> ${spring.version}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17640) Update Ignite Spring Data Dependency Snippet
Igor Belyakov created IGNITE-17640:
--
Summary: Update Ignite Spring Data Dependency Snippet
Key: IGNITE-17640
URL: https://issues.apache.org/jira/browse/IGNITE-17640
Project: Ignite
Issue Type: Bug
Components: documentation
Reporter: Igor Belyakov
Since "org.apache.ignite:ignite-spring-data-ext:2.0.0" was released:
[https://search.maven.org/artifact/org.apache.ignite/ignite-spring-data-ext/2.0.0/jar]
a dependency snippet on the Spring Data page should be updated:
[https://ignite.apache.org/docs/extensions/spring/spring-data#maven-configuration]
as well as "Apache Ignite Spring Data extension version" in the compatibility
table.
Also, the "org.springframework:spring-tx" dependency should be added to the
dependency snippet:
org.springframework
spring-tx
${spring.version}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16978) SQL update fails with "modified concurrently" error for REPLICATED cache with TRANSACTIONAL atomicity mode
[
https://issues.apache.org/jira/browse/IGNITE-16978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-16978:
---
Affects Version/s: 2.10
(was: 2.12)
> SQL update fails with "modified concurrently" error for REPLICATED cache with
> TRANSACTIONAL atomicity mode
> --
>
> Key: IGNITE-16978
> URL: https://issues.apache.org/jira/browse/IGNITE-16978
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Igor Belyakov
>Priority: Major
> Attachments: JdbcThinConcurrentModificationErrorTest.java
>
>
> In case SQL update query executed for the same key multiple times using JDBC
> or Java thin client, sometimes it leads to:
> {code:java}
> Failed to update some keys because they had been modified concurrently
> [keys=[1]]{code}
> There is no concurrent updates execution, all updates are executed one by one
> in the same thread.
> The issue is reproducible only in the case of {{REPLICATED}} cache with
> {{TRANSACTIONAL}} atomicity mode and the client should be connected to the
> server node where backup entry is stored. The issue can be easily reproduced
> if any client node joins/leaves the cluster during the query execution, but
> also the issue happens without any additional actions
> In case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with
> {{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not
> reproducible anymore. The same happens after changing atomicity mode from
> {{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
> Reproducer attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16978) SQL update fails with "modified concurrently" error for REPLICATED cache with TRANSACTIONAL atomicity mode
[
https://issues.apache.org/jira/browse/IGNITE-16978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-16978:
---
Attachment: JdbcThinConcurrentModificationErrorTest.java
> SQL update fails with "modified concurrently" error for REPLICATED cache with
> TRANSACTIONAL atomicity mode
> --
>
> Key: IGNITE-16978
> URL: https://issues.apache.org/jira/browse/IGNITE-16978
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Igor Belyakov
>Priority: Major
> Attachments: JdbcThinConcurrentModificationErrorTest.java
>
>
> In case SQL update query executed for the same key multiple times using JDBC
> or Java thin client, sometimes it leads to:
> {code:java}
> Failed to update some keys because they had been modified concurrently
> [keys=[1]]{code}
> There is no concurrent updates execution, all updates are executed one by one
> in the same thread.
> The issue is reproducible only in the case of {{REPLICATED}} cache with
> {{TRANSACTIONAL}} atomicity mode and the client should be connected to the
> server node where backup entry is stored. The issue can be easily reproduced
> if any client node joins/leaves the cluster during the query execution, but
> also the issue happens without any additional actions
> In case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with
> {{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not
> reproducible anymore. The same happens after changing atomicity mode from
> {{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
> Reproducer attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16978) SQL update fails with "modified concurrently" error for REPLICATED cache with TRANSACTIONAL atomicity mode
[
https://issues.apache.org/jira/browse/IGNITE-16978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-16978:
---
Description:
In case SQL update query executed for the same key multiple times using JDBC or
Java thin client, sometimes it leads to:
{code:java}
Failed to update some keys because they had been modified concurrently
[keys=[1]]{code}
There is no concurrent updates execution, all updates are executed one by one
in the same thread.
The issue is reproducible only in the case of {{REPLICATED}} cache with
{{TRANSACTIONAL}} atomicity mode and the client should be connected to the
server node where backup entry is stored. The issue can be easily reproduced if
any client node joins/leaves the cluster during the query execution, but also
the issue happens without any additional actions
In case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with
{{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not
reproducible anymore. The same happens after changing atomicity mode from
{{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
Reproducer attached.
was:
In case SQL update query executed for the same key multiple times using JDBC or
Java thin client, sometimes it leads to:
Failed to update some keys because they had been modified concurrently
[keys=[1]]
There is no concurrent updates execution, all updates are executed one by one
in the same thread.
The issue is reproducible only in the case of {{REPLICATED}} cache with
{{TRANSACTIONAL}} atomicity mode and the client should be connected to the
server node where backup entry is stored.
The issue can be easily reproduced if any client node joins/leaves the cluster
during the query execution, but also the issue happens without any additional
actions.
Also, in case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with
{{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not
reproducible anymore. The same happens after changing atomicity mode from
{{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
Reproducer attached.
> SQL update fails with "modified concurrently" error for REPLICATED cache with
> TRANSACTIONAL atomicity mode
> --
>
> Key: IGNITE-16978
> URL: https://issues.apache.org/jira/browse/IGNITE-16978
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Igor Belyakov
>Priority: Major
>
> In case SQL update query executed for the same key multiple times using JDBC
> or Java thin client, sometimes it leads to:
> {code:java}
> Failed to update some keys because they had been modified concurrently
> [keys=[1]]{code}
> There is no concurrent updates execution, all updates are executed one by one
> in the same thread.
> The issue is reproducible only in the case of {{REPLICATED}} cache with
> {{TRANSACTIONAL}} atomicity mode and the client should be connected to the
> server node where backup entry is stored. The issue can be easily reproduced
> if any client node joins/leaves the cluster during the query execution, but
> also the issue happens without any additional actions
> In case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with
> {{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not
> reproducible anymore. The same happens after changing atomicity mode from
> {{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
> Reproducer attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-16978) SQL update fails with "modified concurrently" error for REPLICATED cache with TRANSACTIONAL atomicity mode
Igor Belyakov created IGNITE-16978:
--
Summary: SQL update fails with "modified concurrently" error for
REPLICATED cache with TRANSACTIONAL atomicity mode
Key: IGNITE-16978
URL: https://issues.apache.org/jira/browse/IGNITE-16978
Project: Ignite
Issue Type: Bug
Affects Versions: 2.12
Reporter: Igor Belyakov
In case SQL update query executed for the same key multiple times using JDBC or
Java thin client, sometimes it leads to:
Failed to update some keys because they had been modified concurrently
[keys=[1]]
There is no concurrent updates execution, all updates are executed one by one
in the same thread.
The issue is reproducible only in the case of {{REPLICATED}} cache with
{{TRANSACTIONAL}} atomicity mode and the client should be connected to the
server node where backup entry is stored.
The issue can be easily reproduced if any client node joins/leaves the cluster
during the query execution, but also the issue happens without any additional
actions.
Also, in case {{REPLICATED}} cache is replaced by {{PARTITIONED}} with
{{{}BACKUPS=1{}}}, using a cluster with 2 server nodes, the issue is not
reproducible anymore. The same happens after changing atomicity mode from
{{TRANSACTIONAL}} to {{{}ATOMIC{}}}.
Reproducer attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-16854) The result of encryption keys check is printed even in the case of NoopEncryptionSpi usage
Igor Belyakov created IGNITE-16854:
--
Summary: The result of encryption keys check is printed even in
the case of NoopEncryptionSpi usage
Key: IGNITE-16854
URL: https://issues.apache.org/jira/browse/IGNITE-16854
Project: Ignite
Issue Type: Bug
Affects Versions: 2.12
Reporter: Igor Belyakov
On each node joining, the list of known encryption keys for cache groups is
checked in GridEncryptionManager#validateNode(), even in the case of
NoopEncryptionSpi usage.
As result, the next message is printed unexpectedly:
{code:java}
Joining node doesn't have stored group keys
[node=d1080d4d-da9d-43cd-8a89-276212ef48f3]{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17350892#comment-17350892 ] Igor Belyakov commented on IGNITE-11970: [~mmuzaf], could you please review the changes? > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Time Spent: 2h > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14583) Server node fails on remote filter deployment after client reconnect with new node id
[
https://issues.apache.org/jira/browse/IGNITE-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343948#comment-17343948
]
Igor Belyakov commented on IGNITE-14583:
[~ascherbakov], I've fixed the tests, can you please take a look?
> Server node fails on remote filter deployment after client reconnect with new
> node id
> -
>
> Key: IGNITE-14583
> URL: https://issues.apache.org/jira/browse/IGNITE-14583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Igor Belyakov
>Assignee: Igor Belyakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cluster contains 1 server and 1 client node. PeerClassLoading turned on.
> *1.* Client node deploys CQ with remote filter, server node doesn't have
> classes required for remote filter in classpath.
> *2.* Remote filter successfully deployed to server node.
> *3.* Client node disconnects and reconnects by using new node id:
> [15:44:43] Client node was reconnected after it was already considered failed
> by the server topology (this could happen after all servers restarted or due
> to a long network outage between the client and servers). All continuous
> queries and remote event listeners created by this client will be
> unsubscribed, consider listening to EVT_CLIENT_NODE_RECONNECTED event to
> restore them.
> *4.* On connect, client node tries to deploy remote filter to server node,
> but server node fails due to wrong ClassLoaderId, which is sent in
> GridDeploymentInfo (used ClassLoaderId for old client node):
> {code:java}
> [15:44:42] (err) Failed to notify listener:
> o.a.i.i.util.future.GridFutureChainListener@778d0fc6class
> org.apache.ignite.IgniteException: Failed to initialize a remote filter.
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.lambda$register$2bf956f5$1(CacheContinuousQueryHandler.java:353)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:77)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:69)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:29)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:477)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1311)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to obtain
> deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
> ... 8 more
> авг. 07, 2020 3:44:42 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to unmarshal continuous routine handler
> [routineId=8f0137dc-cb32-40ff-83f4-867f272d338e,
> srcNodeId=ebcf4d5b-a476-43d5-b057-00b5694104e6]
> class org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to
> obtain deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
>
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343923#comment-17343923 ] Igor Belyakov commented on IGNITE-11970: [~mmuzaf], I've made changes in the code according to your suggestions and added comments in the PR, can you please take a look? Failed tests are not related to the changes. > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Time Spent: 2h > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11544) Unclear behavior for cache operations using classes different from specified as indexed types
[ https://issues.apache.org/jira/browse/IGNITE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11544: -- Assignee: Igor Belyakov > Unclear behavior for cache operations using classes different from specified > as indexed types > - > > Key: IGNITE-11544 > URL: https://issues.apache.org/jira/browse/IGNITE-11544 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Assignee: Igor Belyakov >Priority: Major > Attachments: IndexedTypesReproducer.java > > > There are a few cases presented in the attached reproducer where caches are > populated by objects of classes different from specified in > CacheConfiguration#setIndexedTypes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11544) Unclear behavior for cache operations using classes different from specified as indexed types
[ https://issues.apache.org/jira/browse/IGNITE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11544: -- Assignee: (was: Igor Belyakov) > Unclear behavior for cache operations using classes different from specified > as indexed types > - > > Key: IGNITE-11544 > URL: https://issues.apache.org/jira/browse/IGNITE-11544 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Priority: Major > Attachments: IndexedTypesReproducer.java > > > There are a few cases presented in the attached reproducer where caches are > populated by objects of classes different from specified in > CacheConfiguration#setIndexedTypes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11544) Unclear behavior for cache operations using classes different from specified as indexed types
[ https://issues.apache.org/jira/browse/IGNITE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11544: -- Assignee: (was: Igor Belyakov) > Unclear behavior for cache operations using classes different from specified > as indexed types > - > > Key: IGNITE-11544 > URL: https://issues.apache.org/jira/browse/IGNITE-11544 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Priority: Major > Attachments: IndexedTypesReproducer.java > > > There are a few cases presented in the attached reproducer where caches are > populated by objects of classes different from specified in > CacheConfiguration#setIndexedTypes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14583) Server node fails on remote filter deployment after client reconnect with new node id
[
https://issues.apache.org/jira/browse/IGNITE-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-14583:
---
Reviewer: Alexey Scherbakov
> Server node fails on remote filter deployment after client reconnect with new
> node id
> -
>
> Key: IGNITE-14583
> URL: https://issues.apache.org/jira/browse/IGNITE-14583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Igor Belyakov
>Assignee: Igor Belyakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cluster contains 1 server and 1 client node. PeerClassLoading turned on.
> *1.* Client node deploys CQ with remote filter, server node doesn't have
> classes required for remote filter in classpath.
> *2.* Remote filter successfully deployed to server node.
> *3.* Client node disconnects and reconnects by using new node id:
> [15:44:43] Client node was reconnected after it was already considered failed
> by the server topology (this could happen after all servers restarted or due
> to a long network outage between the client and servers). All continuous
> queries and remote event listeners created by this client will be
> unsubscribed, consider listening to EVT_CLIENT_NODE_RECONNECTED event to
> restore them.
> *4.* On connect, client node tries to deploy remote filter to server node,
> but server node fails due to wrong ClassLoaderId, which is sent in
> GridDeploymentInfo (used ClassLoaderId for old client node):
> {code:java}
> [15:44:42] (err) Failed to notify listener:
> o.a.i.i.util.future.GridFutureChainListener@778d0fc6class
> org.apache.ignite.IgniteException: Failed to initialize a remote filter.
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.lambda$register$2bf956f5$1(CacheContinuousQueryHandler.java:353)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:77)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:69)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:29)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:477)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1311)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to obtain
> deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
> ... 8 more
> авг. 07, 2020 3:44:42 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to unmarshal continuous routine handler
> [routineId=8f0137dc-cb32-40ff-83f4-867f272d338e,
> srcNodeId=ebcf4d5b-a476-43d5-b057-00b5694104e6]
> class org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to
> obtain deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
>
[jira] [Updated] (IGNITE-14582) Continuous Query deploys remote filter even on client nodes
[ https://issues.apache.org/jira/browse/IGNITE-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov updated IGNITE-14582: --- Reviewer: Slava Koptilin > Continuous Query deploys remote filter even on client nodes > --- > > Key: IGNITE-14582 > URL: https://issues.apache.org/jira/browse/IGNITE-14582 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Major > Attachments: CacheContinuousQueryDeploymentToClientTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > When the client node joins cluster CQ routine is deployed on it, but there's > no sense to have CQ on the client node which doesn't store any data at all. > Test attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14584) Server node fails on remote filter with static initializer deployment if client disconnects
[
https://issues.apache.org/jira/browse/IGNITE-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-14584:
---
Description:
Cluster contains 1 server and 1 client node. PeerClassLoading is turned on.
1. Client node deploys CQ with remote filter, server node doesn't have classes
required for remote filter in classpath. Remote filter should has a class with
static initializer, which has a type that should be deployed:
{code:java}
public class TestClass {
static {
TestSubClass testSubClass = new TestSubClass();
}
}
public class TestSubClass {
}
{code}
2. When TestSubClass deployment is in progress on the server node, the client
node is stopped
3. The server node is unable to deploy TestSubClass and static initializer
can't be finished, as result java.lang.ExceptionInInitializerError happens in
discovery thread and server node fails:
{code:java}
[16:56:23,829][WARNING][disco-notifier-worker-#49%srv1%][GridDeploymentPerVersionStore]
Failed to send class-loading request to node (is node alive?)
[node=72513f9a-8053-410c-bc4f-aa4935e06661, clsName=TestSubClass,
clsPath=TestSubClass.class,
clsLdrId=1ca6c09f471-72513f9a-8053-410c-bc4f-aa4935e06661,
parentClsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2][16:56:23,829][WARNING][disco-notifier-worker-#49%srv1%][GridDeploymentPerVersionStore]
Failed to send class-loading request to node (is node alive?)
[node=72513f9a-8053-410c-bc4f-aa4935e06661, clsName=TestSubClass,
clsPath=TestSubClass.class,
clsLdrId=1ca6c09f471-72513f9a-8053-410c-bc4f-aa4935e06661,
parentClsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2]
[16:56:23,829][SEVERE][disco-notifier-worker-#49%srv1%][GridDiscoveryManager]
Exception in discovery notifier worker
thread.java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native
Method) at java.lang.Class.forName(Class.java:348) at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9066) at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:325)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:640)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1976)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:315)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:300)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10573)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10602)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:96)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1408)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:113)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:205)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:196)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:655)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:526)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2741)
at
[jira] [Created] (IGNITE-14584) Server node fails on remote filter with static initializer deployment if client disconnects
Igor Belyakov created IGNITE-14584:
--
Summary: Server node fails on remote filter with static
initializer deployment if client disconnects
Key: IGNITE-14584
URL: https://issues.apache.org/jira/browse/IGNITE-14584
Project: Ignite
Issue Type: Bug
Affects Versions: 2.10
Reporter: Igor Belyakov
Assignee: Igor Belyakov
Cluster contains 1 server and 1 client node. PeerClassLoading is turned on.
1. Client node deploys CQ with remote filter, server node doesn't have classes
required for remote filter in classpath. Remote filter should has a class with
static initializer, which has a type that should be deployed:
{code:java}
public class TestClass {
static {
TestSubClass testSubClass = new TestSubClass();
}
}
public class TestSubClass {
}
{code}
2. When TestSubClass deployment is in progress on the server node, the client
node is stopped
3. The server node is unable to deploy TestSubClass and static initializer
can't be finished, as result java.lang.ExceptionInInitializerError happens in
discovery thread and server node fails:
{code:java}
[16:56:23,829][WARNING][disco-notifier-worker-#49%srv1%][GridDeploymentPerVersionStore]
Failed to send class-loading request to node (is node alive?)
[node=72513f9a-8053-410c-bc4f-aa4935e06661, clsName=TestSubClass,
clsPath=TestSubClass.class,
clsLdrId=1ca6c09f471-72513f9a-8053-410c-bc4f-aa4935e06661,
parentClsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2][16:56:23,829][WARNING][disco-notifier-worker-#49%srv1%][GridDeploymentPerVersionStore]
Failed to send class-loading request to node (is node alive?)
[node=72513f9a-8053-410c-bc4f-aa4935e06661, clsName=TestSubClass,
clsPath=TestSubClass.class,
clsLdrId=1ca6c09f471-72513f9a-8053-410c-bc4f-aa4935e06661,
parentClsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2][16:56:23,829][SEVERE][disco-notifier-worker-#49%srv1%][GridDiscoveryManager]
Exception in discovery notifier worker
thread.java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native
Method) at java.lang.Class.forName(Class.java:348) at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9066) at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:325)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:640)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1976)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:315)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:300)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10573)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10602)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:96)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1408)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:113)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:205)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:196)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:655)
at
[jira] [Updated] (IGNITE-14583) Server node fails on remote filter deployment after client reconnect with new node id
[
https://issues.apache.org/jira/browse/IGNITE-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov updated IGNITE-14583:
---
Description:
Cluster contains 1 server and 1 client node. PeerClassLoading turned on.
*1.* Client node deploys CQ with remote filter, server node doesn't have
classes required for remote filter in classpath.
*2.* Remote filter successfully deployed to server node.
*3.* Client node disconnects and reconnects by using new node id:
[15:44:43] Client node was reconnected after it was already considered failed
by the server topology (this could happen after all servers restarted or due to
a long network outage between the client and servers). All continuous queries
and remote event listeners created by this client will be unsubscribed,
consider listening to EVT_CLIENT_NODE_RECONNECTED event to restore them.
*4.* On connect, client node tries to deploy remote filter to server node, but
server node fails due to wrong ClassLoaderId, which is sent in
GridDeploymentInfo (used ClassLoaderId for old client node):
{code:java}
[15:44:42] (err) Failed to notify listener:
o.a.i.i.util.future.GridFutureChainListener@778d0fc6class
org.apache.ignite.IgniteException: Failed to initialize a remote filter.
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.lambda$register$2bf956f5$1(CacheContinuousQueryHandler.java:353)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:77)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:69)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:29)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:477)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1311)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: class org.apache.ignite.internal.IgniteDeploymentCheckedException:
Failed to obtain deployment for class: Client1$$Lambda$513/0x0008003b8840
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
... 8 more
авг. 07, 2020 3:44:42 PM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to unmarshal continuous routine handler
[routineId=8f0137dc-cb32-40ff-83f4-867f272d338e,
srcNodeId=ebcf4d5b-a476-43d5-b057-00b5694104e6]
class org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to
obtain deployment for class: Client1$$Lambda$513/0x0008003b8840
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
at
[jira] [Created] (IGNITE-14583) Server node fails on remote filter deployment after client reconnect with new node id
Igor Belyakov created IGNITE-14583: -- Summary: Server node fails on remote filter deployment after client reconnect with new node id Key: IGNITE-14583 URL: https://issues.apache.org/jira/browse/IGNITE-14583 Project: Ignite Issue Type: Bug Affects Versions: 2.10 Reporter: Igor Belyakov Assignee: Igor Belyakov Cluster contains 1 server and 1 client node. PeerClassLoading turned on. *1.* Client node deploys CQ with remote filter, server node doesn't have classes required for remote filter in classpath. *2.* Remote filter successfully deployed to server node. *3.* Client node disconnects and reconnects by using new node id: [15:44:43] Client node was reconnected after it was already considered failed by the server topology (this could happen after all servers restarted or due to a long network outage between the client and servers). All continuous queries and remote event listeners created by this client will be unsubscribed, consider listening to EVT_CLIENT_NODE_RECONNECTED event to restore them. *4.* On connect, client node tries to deploy remote filter to server node, but server node fails due to wrong ClassLoaderId, which is sent in GridDeploymentInfo (used ClassLoaderId for old client node): [15:44:42] (err) Failed to notify listener: o.a.i.i.util.future.GridFutureChainListener@778d0fc6class org.apache.ignite.IgniteException: Failed to initialize a remote filter. at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.lambda$register$2bf956f5$1(CacheContinuousQueryHandler.java:353) at org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:77) at org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:69) at org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:29) at org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398) at org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346) at org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334) at org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510) at org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489) at org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:477) at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1311) at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693) at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162) at org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: class org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to obtain deployment for class: Client1$$Lambda$513/0x0008003b8840 at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94) at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308) ... 8 more авг. 07, 2020 3:44:42 PM org.apache.ignite.logger.java.JavaLogger error SEVERE: Failed to unmarshal continuous routine handler [routineId=8f0137dc-cb32-40ff-83f4-867f272d338e, srcNodeId=ebcf4d5b-a476-43d5-b057-00b5694104e6] class org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to obtain deployment for class: Client1$$Lambda$513/0x0008003b8840 at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94) at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308) at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693) at
[jira] [Created] (IGNITE-14582) Continuous Query deploys remote filter even on client nodes
Igor Belyakov created IGNITE-14582: -- Summary: Continuous Query deploys remote filter even on client nodes Key: IGNITE-14582 URL: https://issues.apache.org/jira/browse/IGNITE-14582 Project: Ignite Issue Type: Bug Affects Versions: 2.10 Reporter: Igor Belyakov Assignee: Igor Belyakov Attachments: CacheContinuousQueryDeploymentToClientTest.java When the client node joins cluster CQ routine is deployed on it, but there's no sense to have CQ on the client node which doesn't store any data at all. Test attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14153) TcpCommunicationSpi#closeStaleConnections() doesn't work for outgoing connections
[ https://issues.apache.org/jira/browse/IGNITE-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov updated IGNITE-14153: --- Reviewer: Sergey Chugunov > TcpCommunicationSpi#closeStaleConnections() doesn't work for outgoing > connections > - > > Key: IGNITE-14153 > URL: https://issues.apache.org/jira/browse/IGNITE-14153 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.9.1 >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Major > Attachments: TcpCommunicationSpiHalfOpenedConnectionTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > Scenario: > 1. Node1 established communication connection to Node2. > 2. Due to network issue the connection was closed on Node2 side, but was > still alive on Node1 side. (half-open connection) > 3. At some point of time Node2 tries to send a message to Node1, and since > there are no existing connections it creates a new one. > 4. Node1 detects that it already has connection to Node2 and prints next > message: > [TcpCommunicationSpi] Received incoming connection when already connected to > this node, rejecting [locNode=2cc905e6--48c1-b316-7652d661, > rmtNode=44c537a7-6070-4272-a545-cff054b0] > 5. Node1 tries to close existing connection by using closeStaleConnection() > method, but since the connection was outcoming it skipped due to "if > (ses0.accepted())" check. > 6. Node2 makes an infinite amount of tries to connect without success. > Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14153) TcpCommunicationSpi#closeStaleConnections() doesn't work for outcoming connections
[ https://issues.apache.org/jira/browse/IGNITE-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov updated IGNITE-14153: --- Attachment: TcpCommunicationSpiHalfOpenedConnectionTest.java > TcpCommunicationSpi#closeStaleConnections() doesn't work for outcoming > connections > -- > > Key: IGNITE-14153 > URL: https://issues.apache.org/jira/browse/IGNITE-14153 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.9.1 >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Major > Attachments: TcpCommunicationSpiHalfOpenedConnectionTest.java > > > Scenario: > 1. Node1 established communication connection to Node2. > 2. Due to network issue the connection was closed on Node2 side, but was > still alive on Node1 side. (half-open connection) > 3. At some point of time Node2 tries to send a message to Node1, and since > there are no existing connections it creates a new one. > 4. Node1 detects that it already has connection to Node2 and prints next > message: > [TcpCommunicationSpi] Received incoming connection when already connected to > this node, rejecting [locNode=2cc905e6--48c1-b316-7652d661, > rmtNode=44c537a7-6070-4272-a545-cff054b0] > 5. Node1 tries to close existing connection by using closeStaleConnection() > method, but since the connection was outcoming it skipped due to "if > (ses0.accepted())" check. > 6. Node2 makes an infinite amount of tries to connect without success. > Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14153) TcpCommunicationSpi#closeStaleConnections() doesn't work for outcoming connections
Igor Belyakov created IGNITE-14153: -- Summary: TcpCommunicationSpi#closeStaleConnections() doesn't work for outcoming connections Key: IGNITE-14153 URL: https://issues.apache.org/jira/browse/IGNITE-14153 Project: Ignite Issue Type: Improvement Components: networking Affects Versions: 2.9.1 Reporter: Igor Belyakov Assignee: Igor Belyakov Scenario: 1. Node1 established communication connection to Node2. 2. Due to network issue the connection was closed on Node2 side, but was still alive on Node1 side. (half-open connection) 3. At some point of time Node2 tries to send a message to Node1, and since there are no existing connections it creates a new one. 4. Node1 detects that it already has connection to Node2 and prints next message: [TcpCommunicationSpi] Received incoming connection when already connected to this node, rejecting [locNode=2cc905e6--48c1-b316-7652d661, rmtNode=44c537a7-6070-4272-a545-cff054b0] 5. Node1 tries to close existing connection by using closeStaleConnection() method, but since the connection was outcoming it skipped due to "if (ses0.accepted())" check. 6. Node2 makes an infinite amount of tries to connect without success. Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13431) NPE during Cassandra Store initialization with PRIMITIVE strategy
[
https://issues.apache.org/jira/browse/IGNITE-13431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17210080#comment-17210080
]
Igor Belyakov commented on IGNITE-13431:
[~ilyak], the fix LGTM.
> NPE during Cassandra Store initialization with PRIMITIVE strategy
> -
>
> Key: IGNITE-13431
> URL: https://issues.apache.org/jira/browse/IGNITE-13431
> Project: Ignite
> Issue Type: Bug
> Components: integrations
>Affects Versions: 2.8.1
>Reporter: Igor Belyakov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: IgnitePersistentStoreTest.java
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When trying to create a simple cache with Cassandra store and have value
> persistence strategy PRIMITIVE, the following exception occurs:
> {code:java}
> 17:29:20,059 ERROR [main] - Exception during start processors, node will be
> stopped and close connections17:29:20,059 ERROR [main] - Exception during
> start processors, node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter [] at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1981)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2045)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> org.apache.ignite.tests.IgnitePersistentStoreTest.directPersistenceConfigTest(IgnitePersistentStoreTest.java:807)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:160) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to validate cache
> configuration. Cache store factory is not serializable. Cache name: cache1 at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4906)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:4937)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.addCacheFromConfiguration(GridLocalConfigManager.java:269)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:167)
> at
>
[jira] [Closed] (IGNITE-13424) Ignite Sink Task issue in Kafka integration
[ https://issues.apache.org/jira/browse/IGNITE-13424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov closed IGNITE-13424. -- Ignite Flags: (was: Docs Required,Release Notes Required) > Ignite Sink Task issue in Kafka integration > --- > > Key: IGNITE-13424 > URL: https://issues.apache.org/jira/browse/IGNITE-13424 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 2.8.1 >Reporter: Aditya >Priority: Major > > We are trying to implement the replication of data between two Ignite data > clusters. > For this purpose, we are using Kafka Connect. > We have followed the things mentioned in this document -> > [https://dzone.com/articles/linking-apache-ignite-and-apache-kafka-for-highly] > Everything is working fine till we use one cache and PUT operation. > But when I use the same for REMOVED operation, in the consumer thread of the > connector, I can see the CacheEvent record, but the data is not being removed > from the Sink Cluster nodes. > When checked, the remove functionality is missing in IgniteSinkTask class. > Is IgniteSink connector only for injecting data? The data record type at the > receiving end is of type CacheEvent. Based on the operation it should put or > remove right? As of now only, PUT is working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13424) Ignite Sink Task issue in Kafka integration
[ https://issues.apache.org/jira/browse/IGNITE-13424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov resolved IGNITE-13424. Resolution: Duplicate Ticket for the improvement was created. > Ignite Sink Task issue in Kafka integration > --- > > Key: IGNITE-13424 > URL: https://issues.apache.org/jira/browse/IGNITE-13424 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 2.8.1 >Reporter: Aditya >Priority: Major > > We are trying to implement the replication of data between two Ignite data > clusters. > For this purpose, we are using Kafka Connect. > We have followed the things mentioned in this document -> > [https://dzone.com/articles/linking-apache-ignite-and-apache-kafka-for-highly] > Everything is working fine till we use one cache and PUT operation. > But when I use the same for REMOVED operation, in the consumer thread of the > connector, I can see the CacheEvent record, but the data is not being removed > from the Sink Cluster nodes. > When checked, the remove functionality is missing in IgniteSinkTask class. > Is IgniteSink connector only for injecting data? The data record type at the > receiving end is of type CacheEvent. Based on the operation it should put or > remove right? As of now only, PUT is working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13442) Implement removals support in Ignite Kafka sink connector
[ https://issues.apache.org/jira/browse/IGNITE-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov updated IGNITE-13442: --- Description: Ignite Kafka sink connector doesn't support removals processing. More details regarding the use case can be found here: http://apache-ignite-users.70518.x6.nabble.com/DC-replication-via-Kafka-Connect-for-Apache-Ignite-td33957.html was:Ignite Kafka sink connector doesn't support removals processing. > Implement removals support in Ignite Kafka sink connector > - > > Key: IGNITE-13442 > URL: https://issues.apache.org/jira/browse/IGNITE-13442 > Project: Ignite > Issue Type: Improvement > Components: integrations >Affects Versions: 2.8.1 >Reporter: Igor Belyakov >Priority: Major > > Ignite Kafka sink connector doesn't support removals processing. > More details regarding the use case can be found here: > http://apache-ignite-users.70518.x6.nabble.com/DC-replication-via-Kafka-Connect-for-Apache-Ignite-td33957.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13442) Implement removals support in Ignite Kafka sink connector
Igor Belyakov created IGNITE-13442: -- Summary: Implement removals support in Ignite Kafka sink connector Key: IGNITE-13442 URL: https://issues.apache.org/jira/browse/IGNITE-13442 Project: Ignite Issue Type: Improvement Components: integrations Affects Versions: 2.8.1 Reporter: Igor Belyakov Ignite Kafka sink connector doesn't support removals processing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13431) NPE during Cassandra Store initialization with PRIMITIVE strategy
Igor Belyakov created IGNITE-13431:
--
Summary: NPE during Cassandra Store initialization with PRIMITIVE
strategy
Key: IGNITE-13431
URL: https://issues.apache.org/jira/browse/IGNITE-13431
Project: Ignite
Issue Type: Bug
Components: integrations
Affects Versions: 2.8.1
Reporter: Igor Belyakov
Attachments: IgnitePersistentStoreTest.java
When trying to create a simple cache with Cassandra store and have value
persistence strategy PRIMITIVE, the following exception occurs:
{code:java}
17:29:20,059 ERROR [main] - Exception during start processors, node will be
stopped and close connections17:29:20,059 ERROR [main] - Exception during start
processors, node will be stopped and close connectionsclass
org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter [] at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1981)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211) at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2045)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
org.apache.ignite.Ignition.start(Ignition.java:321) at
org.apache.ignite.tests.IgnitePersistentStoreTest.directPersistenceConfigTest(IgnitePersistentStoreTest.java:807)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
org.junit.runner.JUnitCore.run(JUnitCore.java:160) at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)Caused
by: class org.apache.ignite.IgniteCheckedException: Failed to validate cache
configuration. Cache store factory is not serializable. Cache name: cache1 at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4906)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4892)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:4937)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:4892)
at
org.apache.ignite.internal.processors.cache.GridLocalConfigManager.addCacheFromConfiguration(GridLocalConfigManager.java:269)
at
org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:167)
at
org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:591)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1978)
... 32 moreCaused by: class org.apache.ignite.IgniteCheckedException: Failed to
deserialize object with given class loader:
sun.misc.Launcher$AppClassLoader@18b4aac2 at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:132)
at
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144784#comment-17144784 ] Igor Belyakov commented on IGNITE-11970: [~mmuzaf], I've fixed an issue with local listeners, can you please take a look? > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11970: -- Assignee: Igor Belyakov > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Fix For: 2.9 > > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12018) Web Agent docker image: 'functions.sh' not found
Igor Belyakov created IGNITE-12018:
--
Summary: Web Agent docker image: 'functions.sh' not found
Key: IGNITE-12018
URL: https://issues.apache.org/jira/browse/IGNITE-12018
Project: Ignite
Issue Type: Bug
Components: UI
Affects Versions: 2.7.5, 2.7
Reporter: Igor Belyakov
Steps to reproduce:
1. Build docker image by using "docker/web-agent/Dockerfile" according to
README file.
2. Start docker container by using generated image.
3. Next error happens on container start:
{code:java}
./ignite-web-agent.sh: line 39:
/opt/ignite/ignite-web-agent/include/functions.sh: No such file or directory
./ignite-web-agent.sh: line 44: checkJava: command not found
./ignite-web-agent.sh: line 64: javaMajorVersion: command not found
./ignite-web-agent.sh: line 66: [: -eq: unary operator expected
./ignite-web-agent.sh: line 71: [: -gt: unary operator expected
./ignite-web-agent.sh: line 84: [: -eq: unary operator expected
./ignite-web-agent.sh: line 95: : command not found{code}
Image contains next files in "/opt/ignite/ignite-web-agent" directory without
any sub directories:
{code:java}
-rw-r--r-- 1 root root 89 Dec 4 2018 README.txt
-rw-r--r-- 1 root root 8080 Dec 4 2018 db-init.sql
-rw-rw-r-- 1 root root 203 Jul 25 12:30 default.properties
-rwxr-xr-x 1 root root 2721 Dec 4 2018 functions.sh
-rw-r--r-- 1 root root 29118502 Dec 6 2018 ignite-web-agent-2.7.0.jar
-rw-r--r-- 1 root root 4590 Dec 4 2018 ignite-web-agent.bat
-rw-rw-r-- 1 root root 561 Jul 25 16:31 ignite-web-agent.log
-rwxr-xr-x 1 root root 3229 Jul 25 16:33 ignite-web-agent.sh
{code}
The issue happens during executing files copy command in Dockerfile, it doesn't
keep directories structure. To solve this problem "COPY ignite-web-agent*/* ./"
command should be changed to "COPY ignite-web-agent* ./"
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
Igor Belyakov created IGNITE-12007:
--
Summary: Latest "apacheignite/web-console-backend" docker image is
broken
Key: IGNITE-12007
URL: https://issues.apache.org/jira/browse/IGNITE-12007
Project: Ignite
Issue Type: Bug
Components: UI
Affects Versions: 2.7
Reporter: Igor Belyakov
It's not possible to run docker container by using the latest version of
"apacheignite/web-console-backend" image.
Next error happens on the start:
{code:java}
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
npm ERR! path /opt/web-console/package.json
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open
'/opt/web-console/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent{code}
How to reproduce:
Run container by using docker-compose as described here:
[https://hub.docker.com/r/apacheignite/web-console-backend]
Seems like it was broken by the next commit:
[https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-11970) Excessive use of memory in continuous queries
Igor Belyakov created IGNITE-11970: -- Summary: Excessive use of memory in continuous queries Key: IGNITE-11970 URL: https://issues.apache.org/jira/browse/IGNITE-11970 Project: Ignite Issue Type: Bug Reporter: Igor Belyakov When we prepare to send an entry into the continuous query's filter and listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. The batch is an array of entries of size IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the currently received entries (we need it for the case of concurrent updates to make sure that we preserve the order of update counters). The issue is that when we process a part of the array we keep the links to the processed entries until we exhaust the array (after when we finally clear it). Because of that we may store up to 999 garbage objects which can be a lot if the entries are big. Need to clear the entries right after we've processed them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11727) Backup entries remains in cache after rebalance
Igor Belyakov created IGNITE-11727: -- Summary: Backup entries remains in cache after rebalance Key: IGNITE-11727 URL: https://issues.apache.org/jira/browse/IGNITE-11727 Project: Ignite Issue Type: Bug Affects Versions: 2.4 Reporter: Igor Belyakov Assignee: Igor Belyakov Attachments: backup-entries-after-rebalance.zip Steps to reproduce: # start 1 Ignite node (cache backups = 0) # load data to cache # start 3 additional Ignite nodes and add them to baseline # wait till rebalance finish # check cache.size(CachePeekMode.BACKUP) Expected: cache.size(CachePeekMode.BACKUP) returns 0 Actual: cache.size(CachePeekMode.BACKUP) returns value > 0 Reproducible in 2.4-master branch. Works correct in 2.4.13/2.4.15. Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11695) AverageGetTime metric doesn't work properly with ScanQuery predicate
[
https://issues.apache.org/jira/browse/IGNITE-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov reassigned IGNITE-11695:
--
Assignee: Igor Belyakov
> AverageGetTime metric doesn't work properly with ScanQuery predicate
>
>
> Key: IGNITE-11695
> URL: https://issues.apache.org/jira/browse/IGNITE-11695
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
>
> In *GridCacheQueryManager.advance* method *start* variable is set only once,
> at the start of executing the method, while metrics.onRead inside this method
> could be executed multiple times in case if Predicate returns false. In the
> case of using FILTER_COUNT= 10, there will be CacheGets=10 and very
> big value for AverageGetTime. If it will be changed to 1, CacheGets still
> will be equal to 10, while AverageGetTime will be really small.
> Reproducer:
> {code:java}
> public class ExampleNodeStartup {
> private static int FILTER_COUNT = 10;
> /**
> * Start up an empty node with example compute configuration.
> *
> * @param args Command line arguments, none required.
> * @throws IgniteException If failed.
> */
> public static void main(String[] args) throws IgniteException {
> Ignite ignite = Ignition.start();
> IgniteCache cache = ignite.getOrCreateCache(new
> CacheConfiguration<>("test").setStatisticsEnabled(true));
> for (int i = 0; i < 10; i++)
> cache.put(i, i);
> long start = System.currentTimeMillis();
> Iterator it = cache.query(new ScanQuery().setFilter(new
> IgniteBiPredicate() {
> @Override public boolean apply(Object o, Object o2) {
> if ((int)o2 % FILTER_COUNT == 0)
> return true;
> return false;
> }
> })).iterator();
> while (it.hasNext())
> System.out.println("iterator value: " + it.next());
> System.out.println("Execution time: " + (System.currentTimeMillis() -
> start));
> System.out.println("GETS: " + cache.metrics().getCacheGets());
> System.out.println("GET times: " +
> cache.metrics().getAverageGetTime());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11544) Unclear behavior for cache operations using classes different from specified as indexed types
[ https://issues.apache.org/jira/browse/IGNITE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11544: -- Assignee: Igor Belyakov > Unclear behavior for cache operations using classes different from specified > as indexed types > - > > Key: IGNITE-11544 > URL: https://issues.apache.org/jira/browse/IGNITE-11544 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Assignee: Igor Belyakov >Priority: Major > Attachments: IndexedTypesReproducer.java > > > There are a few cases presented in the attached reproducer where caches are > populated by objects of classes different from specified in > CacheConfiguration#setIndexedTypes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11652) Remove usage of cache configuration templates from createCache
Igor Belyakov created IGNITE-11652: -- Summary: Remove usage of cache configuration templates from createCache Key: IGNITE-11652 URL: https://issues.apache.org/jira/browse/IGNITE-11652 Project: Ignite Issue Type: Task Reporter: Igor Belyakov Remove usage of cache configuration templates from createCache/getOrCreateCache/getOrCreateCacheAsync in IgniteKernel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11651) Add cluster (de)activation events documentation
Igor Belyakov created IGNITE-11651:
--
Summary: Add cluster (de)activation events documentation
Key: IGNITE-11651
URL: https://issues.apache.org/jira/browse/IGNITE-11651
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Igor Belyakov
Assignee: Artem Budnikov
Fix For: 2.8
{{Add information regarding cluster activation events to
[https://apacheignite.readme.io/docs/baseline-topology#section-activating-the-cluster]}}
After cluster activation/deactivation local event will be raised.
(EVT_CLUSTER_ACTIVATED/EVT_CLUSTER_DEACTIVATED)
Subscribing for local events described here:
[https://apacheignite.readme.io/docs/events#section-local-events]
Example:
ignite.events().localListen((evt) -> {
// Do something.
return true;
}, EventType.EVT_CLUSTER_ACTIVATED);
Cluster event types:
{{EVT_CLUSTER_ACTIVATED - Invoked after Ignite cluster activation.}}
{{EVT_CLUSTER_DEACTIVATED - Invoked after Ignite cluster deactivation.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8376) Add cluster (de)activation events
[
https://issues.apache.org/jira/browse/IGNITE-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796918#comment-16796918
]
Igor Belyakov edited comment on IGNITE-8376 at 3/21/19 8:50 AM:
[~ilyak] [~agoncharuk]
Recording cluster activation event moved to ExchangeFuture listener. Tests
implemented.
was (Author: ibelyakov):
[~ilyak] Recording cluster activation event moved to ExchangeFuture listener.
Tests implemented.
> Add cluster (de)activation events
> -
>
> Key: IGNITE-8376
> URL: https://issues.apache.org/jira/browse/IGNITE-8376
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, we do not have any way to detect that a cluster got activated,
> which results in busy-loops polling {{cluster().active()}}.
> I suggest to add new events, {{EVT_CLUSTER_ACTIVATED}},
> {{EVT_CLUSTER_DEACTIVATED}}, {{EVT_CLUSTER_ACTIVATION_FAILED}} which will be
> fired when corresponding steps are completed. The event should contain, if
> possible, information about the activation source (public API or
> auto-activation), topology version on which activation was performed. The
> fail event should contain information about the cause of the failure. If
> needed, a new class for this event should be introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect
[ https://issues.apache.org/jira/browse/IGNITE-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797292#comment-16797292 ] Igor Belyakov commented on IGNITE-11471: [~vozerov], In current case RND changing has an effect, because @Before method in the test replaces IgniteUtils.RND instance before the first access to JdbcThinTcpIo. Therefore, JdbcThinTcpIo.IDX_GEN will be initialized by using updated IgniteUtils.RND. Anyway, I agree that it's too tricky solution and exposing IgniteUtils.RND wasn't right. I've reverted last commit. > JDBC: Thin driver should start with a random server to connect > -- > > Key: IGNITE-11471 > URL: https://issues.apache.org/jira/browse/IGNITE-11471 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Igor Belyakov >Priority: Major > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > Thin JDBC driver uses a list of server addresses to connect to. Connections > created in a single JVM will use round-robin to choose the server to connect, > yielding a uniform distribution. However, the round-robin always starts from > the first server in the list. It means that multiple JVMs with the same JDBC > connection URL and one connection each will all connect to the same server. > Need to choose the first server randomly to have a better distribution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8376) Add cluster (de)activation events
[
https://issues.apache.org/jira/browse/IGNITE-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796918#comment-16796918
]
Igor Belyakov commented on IGNITE-8376:
---
[~ilyak] Recording cluster activation event moved to ExchangeFuture listener.
Tests implemented.
> Add cluster (de)activation events
> -
>
> Key: IGNITE-8376
> URL: https://issues.apache.org/jira/browse/IGNITE-8376
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, we do not have any way to detect that a cluster got activated,
> which results in busy-loops polling {{cluster().active()}}.
> I suggest to add new events, {{EVT_CLUSTER_ACTIVATED}},
> {{EVT_CLUSTER_DEACTIVATED}}, {{EVT_CLUSTER_ACTIVATION_FAILED}} which will be
> fired when corresponding steps are completed. The event should contain, if
> possible, information about the activation source (public API or
> auto-activation), topology version on which activation was performed. The
> fail event should contain information about the cause of the failure. If
> needed, a new class for this event should be introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect
[ https://issues.apache.org/jira/browse/IGNITE-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796905#comment-16796905 ] Igor Belyakov commented on IGNITE-11471: [~vozerov], random instance for IDX_GEN initialization has been changed to IgniteUtils.RND. Unit test added. > JDBC: Thin driver should start with a random server to connect > -- > > Key: IGNITE-11471 > URL: https://issues.apache.org/jira/browse/IGNITE-11471 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Igor Belyakov >Priority: Major > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > Thin JDBC driver uses a list of server addresses to connect to. Connections > created in a single JVM will use round-robin to choose the server to connect, > yielding a uniform distribution. However, the round-robin always starts from > the first server in the list. It means that multiple JVMs with the same JDBC > connection URL and one connection each will all connect to the same server. > Need to choose the first server randomly to have a better distribution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11492) Add cluster activation failed event
[ https://issues.apache.org/jira/browse/IGNITE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785609#comment-16785609 ] Igor Belyakov commented on IGNITE-11492: Implementation details should be discussed with [~agoncharuk] and [~ilyak]. > Add cluster activation failed event > --- > > Key: IGNITE-11492 > URL: https://issues.apache.org/jira/browse/IGNITE-11492 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Belyakov >Priority: Major > Fix For: 2.8 > > > New event EVT_CLUSTER_ACTIVATION_FAILED should be added. > The fail event should contain information about the cause of the failure. If > needed, a new class for this event should be introduced. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11492) Add cluster activation failed event
Igor Belyakov created IGNITE-11492: -- Summary: Add cluster activation failed event Key: IGNITE-11492 URL: https://issues.apache.org/jira/browse/IGNITE-11492 Project: Ignite Issue Type: Improvement Reporter: Igor Belyakov Fix For: 2.8 New event EVT_CLUSTER_ACTIVATION_FAILED should be added. The fail event should contain information about the cause of the failure. If needed, a new class for this event should be introduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect
[ https://issues.apache.org/jira/browse/IGNITE-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Belyakov reassigned IGNITE-11471: -- Assignee: Igor Belyakov > JDBC: Thin driver should start with a random server to connect > -- > > Key: IGNITE-11471 > URL: https://issues.apache.org/jira/browse/IGNITE-11471 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Igor Belyakov >Priority: Major > Labels: newbie > > Thin JDBC driver uses a list of server addresses to connect to. Connections > created in a single JVM will use round-robin to choose the server to connect, > yielding a uniform distribution. However, the round-robin always starts from > the first server in the list. It means that multiple JVMs with the same JDBC > connection URL and one connection each will all connect to the same server. > Need to choose the first server randomly to have a better distribution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8376) Add cluster (de)activation events
[
https://issues.apache.org/jira/browse/IGNITE-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Belyakov reassigned IGNITE-8376:
-
Assignee: Igor Belyakov
> Add cluster (de)activation events
> -
>
> Key: IGNITE-8376
> URL: https://issues.apache.org/jira/browse/IGNITE-8376
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> Currently, we do not have any way to detect that a cluster got activated,
> which results in busy-loops polling {{cluster().active()}}.
> I suggest to add new events, {{EVT_CLUSTER_ACTIVATED}},
> {{EVT_CLUSTER_DEACTIVATED}}, {{EVT_CLUSTER_ACTIVATION_FAILED}} which will be
> fired when corresponding steps are completed. The event should contain, if
> possible, information about the activation source (public API or
> auto-activation), topology version on which activation was performed. The
> fail event should contain information about the cause of the failure. If
> needed, a new class for this event should be introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
