[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520894#comment-16520894
]
Valentin Kulichenko commented on IGNITE-8740:
-
OK, I merged this to master and 2.6. Thanks for the contribution!
I still think it makes sense to add {{setIgnite}} method so that users have
cleaner way to inject (using Ignite instance name for this doesn't seem to be
the best way). Can you please create a ticket?
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[ https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520892#comment-16520892 ] ASF GitHub Bot commented on IGNITE-8740: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4208 > Support reuse of already initialized Ignite in IgniteSpringBean > --- > > Key: IGNITE-8740 > URL: https://issues.apache.org/jira/browse/IGNITE-8740 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.4 >Reporter: Ilya Kasnacheev >Assignee: Amir Akhmedov >Priority: Blocker > Fix For: 2.6 > > > See > http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724 > (there's patch available) > The idea is to introduce a workaround for users hit by IGNITE-6555, which > unfortunately broke some scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520887#comment-16520887
]
Amir Akhmedov commented on IGNITE-8740:
---
[~vkulichenko], yes, if SCM/STM initialized after {{IgniteSpringBean}} (which
was the case before -IGNITE-6555- implementation) then everything will work as
expected. {{ContextRefreshedEvent}} is a guarantee which says every bean is
setup and ready and after that I'm setting Ignite references in SCM/STM
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence
[ https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6241: --- Assignee: Denis Magda (was: Peter Ivanov) > Integrate with Kubernetes StatefulSet to support Ignite Persistence > --- > > Key: IGNITE-6241 > URL: https://issues.apache.org/jira/browse/IGNITE-6241 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.7 > > Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, > rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt > > > Ignite Kubernetes integration has to support StatefulSet which enables Ignite > Persistence usage in Kubernetes deployments. More details are here: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html > See how it's done for Cassandra and MongoDB: > * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/ > * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/ > We can reach out K8 folks and ask to add a prepared Ignite tutorial to the > list. > Good reading on the stateful set: > https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence
[ https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6241: Fix Version/s: (was: 2.6) 2.7 > Integrate with Kubernetes StatefulSet to support Ignite Persistence > --- > > Key: IGNITE-6241 > URL: https://issues.apache.org/jira/browse/IGNITE-6241 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.7 > > Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, > rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt > > > Ignite Kubernetes integration has to support StatefulSet which enables Ignite > Persistence usage in Kubernetes deployments. More details are here: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html > See how it's done for Cassandra and MongoDB: > * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/ > * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/ > We can reach out K8 folks and ask to add a prepared Ignite tutorial to the > list. > Good reading on the stateful set: > https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520876#comment-16520876
]
Valentin Kulichenko commented on IGNITE-8740:
-
[~aakhmedov], the current issue will be fixed if SCM/STM is initialized AFTER
the {{IgniteSpringBean}}. Is this the case with your fix? If yes, how is this
guaranteed?
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled
[
https://issues.apache.org/jira/browse/IGNITE-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520868#comment-16520868
]
Valentin Kulichenko commented on IGNITE-7993:
-
[~guseinov], looks like when striped pool is disabled, we simply reuse the
system pool for all tasks that are supposed to belong to striped pool. To my
knowledge this can lead to thread starvation in some cases. Is it possible to
have a separate pool in any case, but just switch form striped to a regular one
if striped is disabled?
> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid
> stripedPool thread pool size (must be greater than 0), actual value: 0
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520861#comment-16520861
]
Amir Akhmedov commented on IGNITE-8740:
---
[~vkulichenko],
In general, we can add {{setIgnite(Ignite ignite)}} to make dependency
injection explicit but today you can pass instance of {{IgniteConfiguration}}
or set a path to {{IgniteConfiguration}} in
{{SpringCacheManager/}}{{SpringTransactionManager}} (SCM/STM) and it brings up
an Ignite instance (it's done in {{afterPropertiesSet()}})
But the issue occurs only if you want to use {{IgniteSpringBean}}. What's
happening today, since {{IgniteSpringBean}} implements
{{SmartInitializingSingleton}} it will start it's initialization right after
all singleton scope beans are initialized (which SCM and STM are) and since in
SCM/STM referring to Ignite instance in afterPropertiesSet() it can't find and
failing (ignite will be instantiated later in {{IgniteSpringBean}}).
So, what ApplicationListener does, it's listening to
{{ContextRefreshedEvent}} which is published when all Spring beans are
initialized (including {{IgniteSpringBean}}). And what I'm doing is waiting to
this event to happen and finalizing SCM/STM initialization in
onApplicationEvent(ContextRefreshedEvent event) method.
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly
[
https://issues.apache.org/jira/browse/IGNITE-8436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520858#comment-16520858
]
ASF GitHub Bot commented on IGNITE-8436:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3945
> Executor service for services does not shutdown properly
>
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802]
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls
> Grid life cycle and allows listening for grid events.
> As cotributor, you should ensure that execution pool shutdowns properly and
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8436) Executor service for services does not shutdown properly
[
https://issues.apache.org/jira/browse/IGNITE-8436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-8436:
Fix Version/s: (was: 2.6)
2.7
> Executor service for services does not shutdown properly
>
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802]
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls
> Grid life cycle and allows listening for grid events.
> As cotributor, you should ensure that execution pool shutdowns properly and
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly
[
https://issues.apache.org/jira/browse/IGNITE-8436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520855#comment-16520855
]
Valentin Kulichenko commented on IGNITE-8436:
-
Merged to master. [~prabhat], thanks for the contribution!
> Executor service for services does not shutdown properly
>
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
> Labels: newbie
> Fix For: 2.6
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802]
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls
> Grid life cycle and allows listening for grid events.
> As cotributor, you should ensure that execution pool shutdowns properly and
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520809#comment-16520809
]
Valentin Kulichenko edited comment on IGNITE-8740 at 6/22/18 9:57 PM:
--
Also, I think we should add {{setIgnite(Ignite ignite)}} method to
{{SpringCacheManager}} and {{SpringTransactionManager}}. That would be a
cleaner way to do the injection in case both {{IgniteSpringBean}} and one of
{{SpringCacheManager}}/{{SpringTransactionManager}} are configured in the same
context (from my understanding, that's the only problematic scenario).
Agree?
was (Author: vkulichenko):
Also, I think we should add {{setIgnite(Ignite ignite)}} method to
{{SpringCacheManager}} and {{SpringTransactionManager}}. That would be a
cleaner way to do the injection in case both {{IgniteSpringBean}} and one of
{{SpringCacheManager}}/{{SpringTransactionManager}} are configured in the same
context.
Agree?
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520809#comment-16520809
]
Valentin Kulichenko commented on IGNITE-8740:
-
Also, I think we should add {{setIgnite(Ignite ignite)}} method to
{{SpringCacheManager}} and {{SpringTransactionManager}}. That would be a
cleaner way to do the injection in case both {{IgniteSpringBean}} and one of
{{SpringCacheManager}}/{{SpringTransactionManager}} are configured in the same
context.
Agree?
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[
https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520800#comment-16520800
]
Valentin Kulichenko commented on IGNITE-8740:
-
[~aakhmedov], can you please clarify how switching to {{ApplicationListener}}
fixes the issue? Is it guaranteed to be invoked later than
{{SmartInitializingSingleton#afterSingletonsInstantiated}}? I see the following
in the Javadoc which makes me doubt this:
{noformat}
* This callback variant is somewhat similar to
* {@link org.springframework.context.event.ContextRefreshedEvent} but doesn't
* require an implementation of {@link
org.springframework.context.ApplicationListener},
* with no need to filter context references across a context hierarchy etc.
* It also implies a more minimal dependency on just the {@code beans} package
* and is being honored by standalone {@link ListableBeanFactory}
implementations,
* not just in an {@link org.springframework.context.ApplicationContext}
environment.
{noformat}
> Support reuse of already initialized Ignite in IgniteSpringBean
> ---
>
> Key: IGNITE-8740
> URL: https://issues.apache.org/jira/browse/IGNITE-8740
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Amir Akhmedov
>Priority: Blocker
> Fix For: 2.6
>
>
> See
> http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
> (there's patch available)
> The idea is to introduce a workaround for users hit by IGNITE-6555, which
> unfortunately broke some scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8081) Document Kubernetes RBAC configuration to avoid 403 exception
[ https://issues.apache.org/jira/browse/IGNITE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-8081: Priority: Critical (was: Major) > Document Kubernetes RBAC configuration to avoid 403 exception > - > > Key: IGNITE-8081 > URL: https://issues.apache.org/jira/browse/IGNITE-8081 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.7 > > > It's reported by the users that sometimes Ignite Kubernetes IP finder fails > to join the cluster due to security issues. To prevent the exception > happening we need to document how to set up a Service Account for Ignite pods: > https://stackoverflow.com/questions/49395481/how-to-setmasterurl-in-ignite-xml-config-for-kubernetes-ipfinder/49405879#49405879 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8081) Document Kubernetes RBAC configuration to avoid 403 exception
[ https://issues.apache.org/jira/browse/IGNITE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8081: --- Assignee: Denis Magda > Document Kubernetes RBAC configuration to avoid 403 exception > - > > Key: IGNITE-8081 > URL: https://issues.apache.org/jira/browse/IGNITE-8081 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > It's reported by the users that sometimes Ignite Kubernetes IP finder fails > to join the cluster due to security issues. To prevent the exception > happening we need to document how to set up a Service Account for Ignite pods: > https://stackoverflow.com/questions/49395481/how-to-setmasterurl-in-ignite-xml-config-for-kubernetes-ipfinder/49405879#49405879 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8081) Document Kubernetes RBAC configuration to avoid 403 exception
[ https://issues.apache.org/jira/browse/IGNITE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-8081: Fix Version/s: (was: 2.6) 2.7 > Document Kubernetes RBAC configuration to avoid 403 exception > - > > Key: IGNITE-8081 > URL: https://issues.apache.org/jira/browse/IGNITE-8081 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Priority: Major > Fix For: 2.7 > > > It's reported by the users that sometimes Ignite Kubernetes IP finder fails > to join the cluster due to security issues. To prevent the exception > happening we need to document how to set up a Service Account for Ignite pods: > https://stackoverflow.com/questions/49395481/how-to-setmasterurl-in-ignite-xml-config-for-kubernetes-ipfinder/49405879#49405879 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8864) sql-query-put x 5 performance drop
Ilya Suntsov created IGNITE-8864: Summary: sql-query-put x 5 performance drop Key: IGNITE-8864 URL: https://issues.apache.org/jira/browse/IGNITE-8864 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Ilya Suntsov Between commits, 631b659 and 303bd356 is a cause of x 5 performance drop on sql query put. Configuration: * wal mode BACKGROUND * sync mode PRIMARY SYNC * 4 serv 8 clients -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.
[ https://issues.apache.org/jira/browse/IGNITE-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520675#comment-16520675 ] ASF GitHub Bot commented on IGNITE-8238: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3993 > Operation can fails with unexpected RuntimeException when node is stopping. > --- > > Key: IGNITE-8238 > URL: https://issues.apache.org/jira/browse/IGNITE-8238 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov >Priority: Minor > Fix For: 2.7 > > > Operation can fails with RuntimeException when node is stoped in other > thread. > It is not clear from javadoc that operation can throws RuntimeException. > We should add it to javadoc or e.g. throws IllegalStateException which > already present in java cache api javadoc. > Failure in thread: Thread [id=3484, name=updater-2] > java.lang.RuntimeException: Failed to perform cache update: node is stopping. > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796) > at > org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834) > at > org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240) > at > org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945) > at > org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261) > at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.
[ https://issues.apache.org/jira/browse/IGNITE-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8238: --- Fix Version/s: (was: 2.6) 2.7 > Operation can fails with unexpected RuntimeException when node is stopping. > --- > > Key: IGNITE-8238 > URL: https://issues.apache.org/jira/browse/IGNITE-8238 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov >Priority: Minor > Fix For: 2.7 > > > Operation can fails with RuntimeException when node is stoped in other > thread. > It is not clear from javadoc that operation can throws RuntimeException. > We should add it to javadoc or e.g. throws IllegalStateException which > already present in java cache api javadoc. > Failure in thread: Thread [id=3484, name=updater-2] > java.lang.RuntimeException: Failed to perform cache update: node is stopping. > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796) > at > org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834) > at > org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240) > at > org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945) > at > org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261) > at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4939) Receive event before cache initialized
[
https://issues.apache.org/jira/browse/IGNITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520620#comment-16520620
]
ASF GitHub Bot commented on IGNITE-4939:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4226
> Receive event before cache initialized
> --
>
> Key: IGNITE-4939
> URL: https://issues.apache.org/jira/browse/IGNITE-4939
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Receive event before cache initialized that leads to the following:
> {noformat}
> Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException:
> Cache is not configured: ignite-sys-cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8809) Add ability to control.sh to force rebalance for specific partitions on given nodes.
[ https://issues.apache.org/jira/browse/IGNITE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520590#comment-16520590 ] Ivan Daschinskiy commented on IGNITE-8809: -- First steps are ready. Added and tested special RebalanceRequestMessage and corresponding logic to ExchangeManager and ExchangeFuture. Trigger rebalancing by resetting updateCounters to 0 and change state of partition from owning to moving. Process special case when in message user request rebalancing for all owners. > Add ability to control.sh to force rebalance for specific partitions on given > nodes. > > > Key: IGNITE-8809 > URL: https://issues.apache.org/jira/browse/IGNITE-8809 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Sometimes it's desirable to force rebalance for specific partitions on given > nodes, for example, for test reasons or fixing synchronizations issues > without nodes downtime. > control.sh should contain new command: rebalance, which will execute the > exchange request carried by new message type, containing partitions for > rebalancing and mode: full (evict + move) or delta (historical, using > counters). > Example: > control.sh --rebalance [full|delta] nodeId:p1,p2,p3 node2:p4,p5 ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8863) Race on rollback and prepare on near tx can cause remote tx hang
[
https://issues.apache.org/jira/browse/IGNITE-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-8863:
--
Fix Version/s: 2.6
> Race on rollback and prepare on near tx can cause remote tx hang
>
>
> Key: IGNITE-8863
> URL: https://issues.apache.org/jira/browse/IGNITE-8863
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.6
>
>
> {noformat}
> [16:33:56]W: [org.apache.ignite:ignite-core] [2018-06-08
> 13:33:56,931][WARN ][sys-#66696%client%][GridNearTxLocal] The transaction was
> forcibly rolled back because a timeout is reached:
> GridNearTxLocal[xid=e198a9fd361--0857-6387--0004,
> xidVersion=GridCacheVersion [topVer=139944839, order=1528464836894,
> nodeOrder=4], concurrency=PESSIMISTIC, isolation=REPEATABLE_READ,
> state=MARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a, timeout=1, duration=11]
> [16:35:55]W: [org.apache.ignite:ignite-core] [2018-06-08
> 13:35:55,056][WARN
> ][grid-timeout-worker-#66394%transactions.TxRollbackOnTimeoutTest0%][diagnostic]
> Found long running transaction [startTime=13:33:56.931,
> curTime=13:35:55.054, tx=GridDhtTxRemote
> [nearNodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a,
> rmtFutId=af940d0e361-79c59341-3292-46e4-92ce-5c4ef4eddef8,
> nearXidVer=GridCacheVersion [topVer=139944839, order=1528464836894,
> nodeOrder=4], storeWriteThrough=false, super=GridDistributedTxRemoteAdapter
> [explicitVers=null, started=true, commitAllowed=0,
> txState=IgniteTxRemoteSingleStateImpl [entry=IgniteTxEntry
> [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true], cacheId=3556498,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> cacheId=3556498], val=[op=CREATE, val=CacheObjectImpl [val=null,
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false,
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=1,
> super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> val=CacheObjectImpl [val=null, hasValBytes=true], startVer=1528464836879,
> ver=GridCacheVersion [topVer=139944839, order=1528464836863, nodeOrder=2],
> hash=1, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null,
> rmts=[GridCacheMvccCandidate [nodeId=97ee44cd-73c9-4e79-95df-e1a03481,
> ver=GridCacheVersion [topVer=139944839, order=1528464836897, nodeOrder=2],
> threadId=75880, id=2310313, topVer=AffinityTopologyVersion [topVer=-1,
> minorTopVer=0], reentry=null,
> otherNodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a, otherVer=null,
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null,
> key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> masks=local=0|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null], GridCacheMvccCandidate
> [nodeId=97ee44cd-73c9-4e79-95df-e1a03481, ver=GridCacheVersion
> [topVer=139944839, order=1528464836900, nodeOrder=2], threadId=75875,
> id=2310317, topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> reentry=null, otherNodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a,
> otherVer=null, mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null, key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> masks=local=0|owner=1|ready=0|reentry=0|used=1|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null, flags=2]]], prepared=1, locked=false,
> nodeId=null, locMapped=false, expiryPlc=null, transferExpiryPlc=false,
> flags=0, partUpdateCntr=0, serReadVer=null, xidVer=null]],
> skipCompletedVers=false, super=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=139944839, order=1528464836897, nodeOrder=2],
> writeVer=GridCacheVersion [topVer=139944839, order=1528464836898,
> nodeOrder=2], implicit=false, loc=false, threadId=75880,
> startTime=1528464836931, nodeId=97ee44cd-73c9-4e79-95df-e1a03481,
> startVer=GridCacheVersion [topVer=139944839, order=1528464836864,
> nodeOrder=1], endVer=null, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=1, sysInvalidate=false, sys=false, plc=2,
> commitVer=null, finalizing=NONE, invalidParts=null, state=PREPARED,
> timedOut=false, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> duration=118123ms, onePhaseCommit=false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8863) Race on rollback and prepare on near tx can cause remote tx hang
Alexei Scherbakov created IGNITE-8863:
-
Summary: Race on rollback and prepare on near tx can cause remote
tx hang
Key: IGNITE-8863
URL: https://issues.apache.org/jira/browse/IGNITE-8863
Project: Ignite
Issue Type: Bug
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
{noformat}
[16:33:56]W: [org.apache.ignite:ignite-core] [2018-06-08
13:33:56,931][WARN ][sys-#66696%client%][GridNearTxLocal] The transaction was
forcibly rolled back because a timeout is reached:
GridNearTxLocal[xid=e198a9fd361--0857-6387--0004,
xidVersion=GridCacheVersion [topVer=139944839, order=1528464836894,
nodeOrder=4], concurrency=PESSIMISTIC, isolation=REPEATABLE_READ,
state=MARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
nodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a, timeout=1, duration=11]
[16:35:55]W: [org.apache.ignite:ignite-core] [2018-06-08
13:35:55,056][WARN
][grid-timeout-worker-#66394%transactions.TxRollbackOnTimeoutTest0%][diagnostic]
Found long running transaction [startTime=13:33:56.931, curTime=13:35:55.054,
tx=GridDhtTxRemote [nearNodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a,
rmtFutId=af940d0e361-79c59341-3292-46e4-92ce-5c4ef4eddef8,
nearXidVer=GridCacheVersion [topVer=139944839, order=1528464836894,
nodeOrder=4], storeWriteThrough=false, super=GridDistributedTxRemoteAdapter
[explicitVers=null, started=true, commitAllowed=0,
txState=IgniteTxRemoteSingleStateImpl [entry=IgniteTxEntry
[key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true], cacheId=3556498,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
cacheId=3556498], val=[op=CREATE, val=CacheObjectImpl [val=null,
hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
explicitVer=null, dhtVer=null, filters=[], filtersPassed=false,
filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=1,
super=GridDistributedCacheEntry [super=GridCacheMapEntry
[key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true], val=CacheObjectImpl
[val=null, hasValBytes=true], startVer=1528464836879, ver=GridCacheVersion
[topVer=139944839, order=1528464836863, nodeOrder=2], hash=1,
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null,
rmts=[GridCacheMvccCandidate [nodeId=97ee44cd-73c9-4e79-95df-e1a03481,
ver=GridCacheVersion [topVer=139944839, order=1528464836897, nodeOrder=2],
threadId=75880, id=2310313, topVer=AffinityTopologyVersion [topVer=-1,
minorTopVer=0], reentry=null, otherNodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a,
otherVer=null, mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
serOrder=null, key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
masks=local=0|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
prevVer=null, nextVer=null], GridCacheMvccCandidate
[nodeId=97ee44cd-73c9-4e79-95df-e1a03481, ver=GridCacheVersion
[topVer=139944839, order=1528464836900, nodeOrder=2], threadId=75875,
id=2310317, topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
reentry=null, otherNodeId=3c8d85b2-4eb9-46b2-8bd1-6f18f542fc7a, otherVer=null,
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null,
key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
masks=local=0|owner=1|ready=0|reentry=0|used=1|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
prevVer=null, nextVer=null, flags=2]]], prepared=1, locked=false,
nodeId=null, locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
partUpdateCntr=0, serReadVer=null, xidVer=null]], skipCompletedVers=false,
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=139944839,
order=1528464836897, nodeOrder=2], writeVer=GridCacheVersion [topVer=139944839,
order=1528464836898, nodeOrder=2], implicit=false, loc=false, threadId=75880,
startTime=1528464836931, nodeId=97ee44cd-73c9-4e79-95df-e1a03481,
startVer=GridCacheVersion [topVer=139944839, order=1528464836864, nodeOrder=1],
endVer=null, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=1,
sysInvalidate=false, sys=false, plc=2, commitVer=null, finalizing=NONE,
invalidParts=null, state=PREPARED, timedOut=false,
topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0], duration=118123ms,
onePhaseCommit=false
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8503) Fix wrong GridCacheMapEntry startVersion initialization.
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8503:
---
Fix Version/s: (was: 2.6)
2.7
> Fix wrong GridCacheMapEntry startVersion initialization.
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: cache, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test, tck
> Fix For: 2.7
>
>
> GridCacheMapEntry initialize startVersion in wrong way.
> This leads to IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart failure and
> reason is "Entry which should be expired by TTL policy is available after
> grid restart."
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5798755758125626876&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7163) Validate connection from a pre-previous node
[ https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520544#comment-16520544 ] Dmitry Karachentsev commented on IGNITE-7163: - [~dpavlov] thanks! I will check them. > Validate connection from a pre-previous node > > > Key: IGNITE-7163 > URL: https://issues.apache.org/jira/browse/IGNITE-7163 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.6 > > > If some pre-previous node connects to the local node with the previous node > in the message's failed nodes collection additional steps should be done: > # Connection with the previous node should be validated. > # If a message from the previous node was not received a long time ago, the > previous node should be considered as failed and the pre-previous node > connection accepted. > # If the previous node connection is alive then different scenarios possible > ## Answer with a new result code causing the pre-previous node to try to > reconnect to the previous node > ## Break connection with the pre-previous node causing to continue the > possible cluster split. > ## Check connections with nodes after pre-previous node and delay decision by > answering RES_WAIT to get more predictable split and stable topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7163) Validate connection from a pre-previous node
[
https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520542#comment-16520542
]
Dmitriy Pavlov commented on IGNITE-7163:
[~dkarachentsev],
Retrigger did not help:
{noformat}
Cache 4 [ tests 2 ]
IgniteCacheTestSuite4: CacheStopAndDestroySelfTest.testNearClose (fail
rate 0,0%)
IgniteCacheTestSuite4: CacheStopAndDestroySelfTest.testNearCloseWithTry
(fail rate 0,0%)
{noformat}
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache4&branch_IgniteTests24Java8=pull%2F4088%2Fhead&tab=buildTypeStatusDiv
{noformat}
Client Nodes [ tests 4 ]
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectAtomicCache (fail rate 0,0%)
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectComputeApi (fail rate 0,0%)
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectStreamerApi (fail rate 0,0%)
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectTxCache (fail rate 0,0%)
{noformat}
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ClientNodes&branch_IgniteTests24Java8=pull%2F4088%2Fhead&tab=buildTypeStatusDiv
could you please double check these tests?
> Validate connection from a pre-previous node
>
>
> Key: IGNITE-7163
> URL: https://issues.apache.org/jira/browse/IGNITE-7163
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.6
>
>
> If some pre-previous node connects to the local node with the previous node
> in the message's failed nodes collection additional steps should be done:
> # Connection with the previous node should be validated.
> # If a message from the previous node was not received a long time ago, the
> previous node should be considered as failed and the pre-previous node
> connection accepted.
> # If the previous node connection is alive then different scenarios possible
> ## Answer with a new result code causing the pre-previous node to try to
> reconnect to the previous node
> ## Break connection with the pre-previous node causing to continue the
> possible cluster split.
> ## Check connections with nodes after pre-previous node and delay decision by
> answering RES_WAIT to get more predictable split and stable topology.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8862) IgniteChangeGlobalStateTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-8862: - Labels: MakeTeamcityGreenAgain (was: ) > IgniteChangeGlobalStateTest hangs on TeamCity > - > > Key: IGNITE-8862 > URL: https://issues.apache.org/jira/browse/IGNITE-8862 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8862) IgniteChangeGlobalStateTest hangs on TeamCity
Andrey Kuznetsov created IGNITE-8862: Summary: IgniteChangeGlobalStateTest hangs on TeamCity Key: IGNITE-8862 URL: https://issues.apache.org/jira/browse/IGNITE-8862 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520534#comment-16520534
]
Alexey Goncharuk commented on IGNITE-7618:
--
[~SomeFire], in your example I do not see how this is invalid. Any cache
operation happens on some topology version, and since cluster
activation/deactivation changes the topology version as well, we can
immediately tell whether the cache operation should happen or not.
If the activation process is not finished yet, then the active(true) method did
not return, then it means that a cache operation happens concurrently with
active(true) and it is fine to throw an exception (the cluster is not active
_yet_).
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTx
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520507#comment-16520507
]
ASF GitHub Bot commented on IGNITE-8426:
GitHub user ezhuravl opened a pull request:
https://github.com/apache/ignite/pull/4249
IGNITE-8426 LongJVMPauseDetector add logger from context
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8426
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4249.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4249
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8854) sqlline: !indexes and !primarykeys return nothing for o.a.i.IgniteJdbcDriver
[
https://issues.apache.org/jira/browse/IGNITE-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-8854:
--
Description:
# Start cluster
# Start {{bin/sqlline.sh -d org.apache.ignite.IgniteJdbcDriver ...}}
# Create tables with indexes like following:
{noformat}
3/151CREATE TABLE PUBLIC.CAR(ID INT PRIMARY KEY, PARKINGID INT NOT
NULL, NAME VARCHAR(255)) WITH "TEMPLATE=PARTITIONED";
No rows affected (0,249 seconds)
4/151CREATE TABLE PUBLIC.PARKING(ID INT PRIMARY KEY, NAME VARCHAR(255),
CAPACITY INT NOT NULL) WITH "TEMPLATE=REPLICATED";
No rows affected (0,155 seconds)
...
8/151!primarykeys PUBLIC.CAR
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
9/151!primarykeys PUBLIC.PARKING
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
...
12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
No rows affected (0.071 seconds)
13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
No rows affected (0.022 seconds)
14/151 !indexes
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
...
{noformat}
For {{org.apache.ignite.IgniteJdbcDriver}} commands work as expected:
{noformat}
8/151!primarykeys PUBLIC.CAR
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
'','PUBLIC','CAR','_KEY','1','ID'
9/151!primarykeys PUBLIC.PARKING
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
'','PUBLIC','PARKING','_KEY','1','ID'
...
12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
No rows affected (0.067 seconds)
13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
No rows affected (0.023 seconds)
14/151 !indexes
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
'','PUBLIC','CAR','true','','CAR_NAME_IDX','3','0','NAME','A','0','0',''
'','PUBLIC','PARKING','true','','PARKING_IDX','3','0','NAME','A','0','0',''
'','PUBLIC','PARKING','true','','PARKING_IDX','3','1','CAPACITY','A','0','0',''
{noformat}
was:
# Start cluster
# Start {{bin/sqlline.sh -d org.apache.ignite.IgniteJdbcDriver ...}}
# Create tables with indexes like following:
{noformat}
3/151CREATE TABLE PUBLIC.CAR(ID INT PRIMARY KEY, PARKINGID INT NOT
NULL, NAME VARCHAR(255)) WITH "TEMPLATE=PARTITIONED";
No rows affected (0,249 seconds)
4/151CREATE TABLE PUBLIC.PARKING(ID INT PRIMARY KEY, NAME VARCHAR(255),
CAPACITY INT NOT NULL) WITH "TEMPLATE=REPLICATED";
No rows affected (0,155 seconds)
...
8/151!primarykeys PUBLIC.CAR
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
9/151!primarykeys PUBLIC.PARKING
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
...
12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
No rows affected (0.071 seconds)
13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
No rows affected (0.022 seconds)
14/151 !indexes
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
...
{noformat}
For {{ org.apache.ignite.IgniteJdbcDriver}} commands work as expected:
{noformat}
8/151!primarykeys PUBLIC.CAR
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
'','PUBLIC','CAR','_KEY','1','ID'
9/151!primarykeys PUBLIC.PARKING
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
'','PUBLIC','PARKING','_KEY','1','ID'
...
12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
No rows affected (0.067 seconds)
13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
No rows affected (0.023 seconds)
14/151 !indexes
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
'','PUBLIC','CAR','true','','CAR_NAME_IDX','3','0','NAME','A','0','0',''
'','PUBLIC','PARKING','true','','PARKING_IDX','3','0','NAME','A','0','0',''
'','PUBLIC','PARKING','true','','PARKING_IDX','3','1','CAPACITY','A','0','0',''
{noformat}
> sqlline: !indexes and !primarykeys return nothing for o.a.i.IgniteJdbcDriver
>
>
> Key: IGNITE-8854
> URL: https://issues.apache.org/jira/browse/IGNITE-8854
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.4
>Reporter: Sergey Kozlov
>Priority: Major
>
> # Start cluster
> # Start {{bin/sqlline.sh -d
[jira] [Created] (IGNITE-8861) Wrong method call in IgniteServise documentation snippet
Oleg Ostanin created IGNITE-8861:
Summary: Wrong method call in IgniteServise documentation snippet
Key: IGNITE-8861
URL: https://issues.apache.org/jira/browse/IGNITE-8861
Project: Ignite
Issue Type: Improvement
Components: documentation
Reporter: Oleg Ostanin
[https://apacheignite.readme.io/docs/service-example]
{{ClusterGroup cacheGrp = ignite.cluster().forCache("myCounterService");}}
{{This string does not compile if we use 2.5 version:}}
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile)
on project poc-tester: Compilation failure}}
{{[ERROR]
/home/oostanin/gg-qa/poc-tester/src/main/java/org/apache/ignite/scenario/ServiceTask.java:[53,51]
cannot find symbol}}
{{[ERROR] symbol: method forCache(java.lang.String)}}
{{[ERROR] location: interface org.apache.ignite.IgniteCluster}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
[ https://issues.apache.org/jira/browse/IGNITE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520485#comment-16520485 ] ASF GitHub Bot commented on IGNITE-8860: GitHub user andrey-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/4248 IGNITE-8860 Returned IgniteDiscoveryThread to RingMessageWorker. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrey-kuznetsov/ignite ignite-8860 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4248.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4248 commit a94403222ad429bfb13446132c83d07ce9e55be6 Author: Andrey Kuznetsov Date: 2018-06-22T15:12:39Z IGNITE-8860 Returned IgniteDiscoveryThread to RingMessageWorker. > IgniteDiscoveryThread marker interface should be restored on > RingMessageWorker class > > > Key: IGNITE-8860 > URL: https://issues.apache.org/jira/browse/IGNITE-8860 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Sergey Chugunov >Assignee: Andrey Kuznetsov >Priority: Major > > It seems that *IgniteDiscoveryThread* interface was removed from > *ServerImpl.RingMessageWorker* class. > It should be restored as it is used to prevent deadlocks on updates of > BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520447#comment-16520447 ] Dmitriy Pavlov commented on IGNITE-7196: [~agoncharuk] are you going to implement this ticket? If not could you please move it to unassigned? > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.6 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31
[jira] [Assigned] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
[ https://issues.apache.org/jira/browse/IGNITE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov reassigned IGNITE-8860: Assignee: Andrey Kuznetsov > IgniteDiscoveryThread marker interface should be restored on > RingMessageWorker class > > > Key: IGNITE-8860 > URL: https://issues.apache.org/jira/browse/IGNITE-8860 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Sergey Chugunov >Assignee: Andrey Kuznetsov >Priority: Major > > It seems that *IgniteDiscoveryThread* interface was removed from > *ServerImpl.RingMessageWorker* class. > It should be restored as it is used to prevent deadlocks on updates of > BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
[ https://issues.apache.org/jira/browse/IGNITE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8860: Component/s: general > IgniteDiscoveryThread marker interface should be restored on > RingMessageWorker class > > > Key: IGNITE-8860 > URL: https://issues.apache.org/jira/browse/IGNITE-8860 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Sergey Chugunov >Priority: Major > > It seems that *IgniteDiscoveryThread* interface was removed from > *ServerImpl.RingMessageWorker* class. > It should be restored as it is used to prevent deadlocks on updates of > BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.
[ https://issues.apache.org/jira/browse/IGNITE-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520443#comment-16520443 ] Andrew Mashenkov commented on IGNITE-8238: -- [~sharpler], Now PR looks good, can be merged. Thanks for contribution. > Operation can fails with unexpected RuntimeException when node is stopping. > --- > > Key: IGNITE-8238 > URL: https://issues.apache.org/jira/browse/IGNITE-8238 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov >Priority: Minor > Fix For: 2.6 > > > Operation can fails with RuntimeException when node is stoped in other > thread. > It is not clear from javadoc that operation can throws RuntimeException. > We should add it to javadoc or e.g. throws IllegalStateException which > already present in java cache api javadoc. > Failure in thread: Thread [id=3484, name=updater-2] > java.lang.RuntimeException: Failed to perform cache update: node is stopping. > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796) > at > org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834) > at > org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240) > at > org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945) > at > org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261) > at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
Sergey Chugunov created IGNITE-8860: --- Summary: IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class Key: IGNITE-8860 URL: https://issues.apache.org/jira/browse/IGNITE-8860 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov It seems that *IgniteDiscoveryThread* interface was removed from *ServerImpl.RingMessageWorker* class. It should be restored as it is used to prevent deadlocks on updates of BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8709) CacheMBStatisticsBeanTest.testPutIfAbsent failed
[ https://issues.apache.org/jira/browse/IGNITE-8709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-8709. -- Resolution: Fixed Thanks for contribution. Merged to master. Tests failed at Jcache 1.0 muted CacheMBStatisticsBeanTest.testPutIfAbsent > CacheMBStatisticsBeanTest.testPutIfAbsent failed > > > Key: IGNITE-8709 > URL: https://issues.apache.org/jira/browse/IGNITE-8709 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Alexander Menshikov >Priority: Major > Labels: iep-21 > Fix For: 2.6 > > > Now Cache#putIfAbsent should change hit/miss statistic. > But test in TCK 1.0.1 was incorrect. > *So we can't make this test pass in both versions of TCK.* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520428#comment-16520428 ] Dmitry Karachentsev commented on IGNITE-8618: - Created related ticket: IGNITE-8859 > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8859) Open upper Java verison bounds
Dmitry Karachentsev created IGNITE-8859: --- Summary: Open upper Java verison bounds Key: IGNITE-8859 URL: https://issues.apache.org/jira/browse/IGNITE-8859 Project: Ignite Issue Type: Improvement Reporter: Dmitry Karachentsev Fix For: 2.6 JDK is going to be release twice a year and it will be always an issue for users to start Ignite on newer Java version as we have explicit bounds. Ignite should not disallow starting in latest JDK, but show warning that it wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520421#comment-16520421 ] Dmitry Karachentsev commented on IGNITE-8618: - Probably it would be better test against Java 11 LTS, because support of 10 ends on the [September|http://www.oracle.com/technetwork/java/javase/eol-135779.html]. > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520416#comment-16520416 ] Alexei Scherbakov commented on IGNITE-8820: --- [~ivandasch], Thanks for fixing some important issues. Checked again, looks good. > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8503) Fix wrong GridCacheMapEntry startVersion initialization.
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520413#comment-16520413
]
ASF GitHub Bot commented on IGNITE-8503:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4141
> Fix wrong GridCacheMapEntry startVersion initialization.
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: cache, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test, tck
> Fix For: 2.6
>
>
> GridCacheMapEntry initialize startVersion in wrong way.
> This leads to IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart failure and
> reason is "Entry which should be expired by TTL policy is available after
> grid restart."
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5798755758125626876&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8831) MarshallerMappingFileStore: Incorrect locks on files
[ https://issues.apache.org/jira/browse/IGNITE-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8831: --- Fix Version/s: (was: 2.6) 2.7 > MarshallerMappingFileStore: Incorrect locks on files > > > Key: IGNITE-8831 > URL: https://issues.apache.org/jira/browse/IGNITE-8831 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8858) Client none may not stop
[
https://issues.apache.org/jira/browse/IGNITE-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520388#comment-16520388
]
ASF GitHub Bot commented on IGNITE-8858:
GitHub user dkarachentsev opened a pull request:
https://github.com/apache/ignite/pull/4247
IGNITE-8858 - Client none may not stop.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8858
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4247.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4247
commit a7e1d6358185c69c551b5927ff8d223c11ec5527
Author: dkarachentsev
Date: 2018-06-22T13:55:26Z
IGNITE-8858 - Client none may not stop.
> Client none may not stop
>
>
> Key: IGNITE-8858
> URL: https://issues.apache.org/jira/browse/IGNITE-8858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.6
>
>
> There is possible case when client node is not stopped and blocked on waiting
> when SocketReader will be completed. Looks like interruption was lost, and
> the only place where it could happen is in unmarshaling message from input
> stream.
> The way to overcome/fix it is to check if InterruptedException was in cause
> of IgniteCheckedException and repeatedly interrupt reader on stop.
>
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1245)
> - locked <0x00041016a140> (a
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader)
> at java.lang.Thread.join(Thread.java:1319)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4604)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:315)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2061)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1608)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2216)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x000410065e80> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:365)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3417)
> "tcp-client-disco-sock-reader-#35%Default%" #746 prio=5 os_prio=0
> tid=0x7f6090561800 nid=0x3441 in Object.wait() [0x7f60f23d8000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader.body(ClientImpl.java:1006)
> - locked <0x00041016a2e0> (a java.lang.Object)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8503) Fix wrong GridCacheMapEntry startVersion initialization.
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520387#comment-16520387
]
Ilya Lantukh commented on IGNITE-8503:
--
Changes look OK to me.
> Fix wrong GridCacheMapEntry startVersion initialization.
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: cache, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test, tck
> Fix For: 2.6
>
>
> GridCacheMapEntry initialize startVersion in wrong way.
> This leads to IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart failure and
> reason is "Entry which should be expired by TTL policy is available after
> grid restart."
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5798755758125626876&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8858) Client none may not stop
Dmitry Karachentsev created IGNITE-8858:
---
Summary: Client none may not stop
Key: IGNITE-8858
URL: https://issues.apache.org/jira/browse/IGNITE-8858
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
Fix For: 2.6
There is possible case when client node is not stopped and blocked on waiting
when SocketReader will be completed. Looks like interruption was lost, and the
only place where it could happen is in unmarshaling message from input stream.
The way to overcome/fix it is to check if InterruptedException was in cause of
IgniteCheckedException and repeatedly interrupt reader on stop.
{noformat}
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1245)
- locked <0x00041016a140> (a
org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader)
at java.lang.Thread.join(Thread.java:1319)
at
org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4604)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:315)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2061)
at
org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1608)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2216)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
- locked <0x000410065e80> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:365)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3417)
"tcp-client-disco-sock-reader-#35%Default%" #746 prio=5 os_prio=0
tid=0x7f6090561800 nid=0x3441 in Object.wait() [0x7f60f23d8000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader.body(ClientImpl.java:1006)
- locked <0x00041016a2e0> (a java.lang.Object)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8831) MarshallerMappingFileStore: Incorrect locks on files
[ https://issues.apache.org/jira/browse/IGNITE-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520367#comment-16520367 ] ASF GitHub Bot commented on IGNITE-8831: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4224 > MarshallerMappingFileStore: Incorrect locks on files > > > Key: IGNITE-8831 > URL: https://issues.apache.org/jira/browse/IGNITE-8831 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8857) ZookeeperClusterNode class instances sneak into BaselineTopology when non-empty user attributes are defined
[
https://issues.apache.org/jira/browse/IGNITE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-8857:
Component/s: zookeeper
> ZookeeperClusterNode class instances sneak into BaselineTopology when
> non-empty user attributes are defined
> ---
>
> Key: IGNITE-8857
> URL: https://issues.apache.org/jira/browse/IGNITE-8857
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> When persistence-enabled cluster is activated for the first time, it saves
> information about cluster nodes into BaselineTopology, including user
> attributes.
> It turned out that in case of cluster started with ZookeeperDiscoverySpi on
> first activation instances of ZookeeperClusterNode are persisted to disk
> within BaselineTopology.
> After that the same nodes cannot be switched to TcpDiscoverySpi without
> having ignite-zookeeper.jar on classpath, an attempt to start cluster results
> in the following exception:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1754)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:998)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:671)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:596)
> at org.apache.ignite.Ignition.start(Ignition.java:327)
> ... 33 common frames omitted
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7e532bb8,
> cls=org.apache.ignite.spi.discovery.zk.internal.ZookeeperClusterNode$1]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:144)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:161)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.read(MetaStorage.java:158)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:216)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:437)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:633)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:700)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1751)
> ... 40 common frames omitted
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClusterNode$1
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 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:8608)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1819)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1713)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1986)
> at java.io.ObjectInputStream.readObject0(Objec
[jira] [Updated] (IGNITE-8857) ZookeeperClusterNode class instances sneak into BaselineTopology when non-empty user attributes are defined
[
https://issues.apache.org/jira/browse/IGNITE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-8857:
Description:
When persistence-enabled cluster is activated for the first time, it saves
information about cluster nodes into BaselineTopology, including user
attributes.
It turned out that in case of cluster started with ZookeeperDiscoverySpi on
first activation instances of ZookeeperClusterNode are persisted to disk within
BaselineTopology.
After that the same nodes cannot be switched to TcpDiscoverySpi without having
ignite-zookeeper.jar on classpath, an attempt to start cluster results in the
following exception:
{code}
org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1754)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:998)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:671)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:596)
at org.apache.ignite.Ignition.start(Ignition.java:327)
... 33 common frames omitted
Caused by: org.apache.ignite.IgniteCheckedException: Failed to find class with
given class loader for unmarshalling (make sure same versions of all classes
are available on all nodes or enable peer-class-loading)
[clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7e532bb8,
cls=org.apache.ignite.spi.discovery.zk.internal.ZookeeperClusterNode$1]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:144)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:161)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.read(MetaStorage.java:158)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:216)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:437)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:633)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:539)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:700)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1751)
... 40 common frames omitted
Caused by: java.lang.ClassNotFoundException:
org.apache.ignite.spi.discovery.zk.internal.ZookeeperClusterNode$1
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
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:8608)
at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1819)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1713)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1986)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1919)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1529)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.Obje
[jira] [Created] (IGNITE-8857) ZookeeperClusterNode class instances sneak into BaselineTopology when non-empty user attributes are defined
Sergey Chugunov created IGNITE-8857: --- Summary: ZookeeperClusterNode class instances sneak into BaselineTopology when non-empty user attributes are defined Key: IGNITE-8857 URL: https://issues.apache.org/jira/browse/IGNITE-8857 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Assignee: Sergey Chugunov When persistence-enabled cluster is activated for the first time, it saves information about cluster nodes into BaselineTopology, including user attributes. It turned out that in case of cluster started with ZookeeperDiscoverySpi on first activation instances of ZookeeperClusterNode are persisted to disk within BaselineTopology. After that the same nodes cannot be switched to TcpDiscoverySpi without having ignite-zookeeper.jar on classpath. We should prevent ZookeeperClusterNode instances to be persisted to disk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8495) CPP Thin: Implement thin client start and connection establishment
[ https://issues.apache.org/jira/browse/IGNITE-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520318#comment-16520318 ] Sergey Kalashnikov commented on IGNITE-8495: [~isapego], I have left a couple of comments in the upsource. Please see. > CPP Thin: Implement thin client start and connection establishment > -- > > Key: IGNITE-8495 > URL: https://issues.apache.org/jira/browse/IGNITE-8495 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 2.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.6 > > > Need to implement basic functionality for C++ thin client - configuration, > starting, connection to server, handshake. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[
https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520306#comment-16520306
]
Aleksey Plekhanov commented on IGNITE-8203:
---
[~agoncharuk] I have made changes according to your proposal. Now init, read
and write operations are atomic.
{{write}} method acquires readLock, so failover routine for {{write}} and
{{read}} methods are differ.
In addition to {{ClosedByInterruptException}} another thread can also get
{{ClosedChannelException}} if work with the same channel at the same time. So I
added {{FileIO}} reinit routine for all kinds of {{ClosedChannelException}}. In
case when channel closed excplicitly, field {{fileIO}} will be null and
{{FileIO}} will not be reinited.
In some cases visibility of {{fileIO}} field now not guarded by {{inited}}
volatile field, as it was before, so I have made {{fileIO}} field volitile too.
TC passed, please have a look again.
> Interrupting task can cause node fail with PersistenceStorageIOException.
> --
>
> Key: IGNITE-8203
> URL: https://issues.apache.org/jira/browse/IGNITE-8203
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Ivan Daschinskiy
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.6
>
> Attachments: GridFailNodesOnCanceledTaskTest.java
>
>
> Interrupting task with simple cache operations (i.e. get, put) can cause
> PersistenceStorageIOException. Main cause of this failure is lack of proper
> handling InterruptedException in FilePageStore.init() etc. This cause a throw
> of ClosedByInterruptException by FileChannel.write() and so on.
> PersistenceStorageIOException is a critical failure and typically makes a
> node to stop. As a workaround, I would suggest to enable AsyncFileIO by
> default until the fix was available.
> A reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8813) Add ComputeJobResultPolicy to JobEvent
[ https://issues.apache.org/jira/browse/IGNITE-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520303#comment-16520303 ] ASF GitHub Bot commented on IGNITE-8813: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4213 > Add ComputeJobResultPolicy to JobEvent > -- > > Key: IGNITE-8813 > URL: https://issues.apache.org/jira/browse/IGNITE-8813 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 2.5 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.6 > > > There is no way to determine on node-mapper what action would be performed on > EVT_JOB_RESULTED event, as got result could return different policies: WAIT, > REDUCE, FAILOVER. This knowledge might be critical for user if it relies on > events, and, for instance, he need to know if EVT_JOB_RESULTED is final > event, or it will be failed over and will be fired again. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8813) Add ComputeJobResultPolicy to JobEvent
[ https://issues.apache.org/jira/browse/IGNITE-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520301#comment-16520301 ] Alexey Goncharuk commented on IGNITE-8813: -- Thanks, Dmitriy, merged your changes to master. > Add ComputeJobResultPolicy to JobEvent > -- > > Key: IGNITE-8813 > URL: https://issues.apache.org/jira/browse/IGNITE-8813 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 2.5 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.6 > > > There is no way to determine on node-mapper what action would be performed on > EVT_JOB_RESULTED event, as got result could return different policies: WAIT, > REDUCE, FAILOVER. This knowledge might be critical for user if it relies on > events, and, for instance, he need to know if EVT_JOB_RESULTED is final > event, or it will be failed over and will be fired again. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8836) NullPointerException during Ignition.start prevents JVM shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520283#comment-16520283 ] ASF GitHub Bot commented on IGNITE-8836: GitHub user antkr opened a pull request: https://github.com/apache/ignite/pull/4245 IGNITE-8836 Added IGNITE_FORCE_JVM_SHUTDOWN_TIMEOUT property to force… … node shutdown within given timout. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8836 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4245.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4245 commit f67bfb9b93a56e921f99dd47b0a65b21543c25ef Author: Anton Kurbanov Date: 2018-05-17T18:49:29Z IGNITE-8836 Added IGNITE_FORCE_JVM_SHUTDOWN_TIMEOUT property to force node shutdown within given timout. > NullPointerException during Ignition.start prevents JVM shutdown > > > Key: IGNITE-8836 > URL: https://issues.apache.org/jira/browse/IGNITE-8836 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kurbanov >Assignee: Anton Kurbanov >Priority: Major > Fix For: 1.9 > > > The exception like below leaves node in stopping state forever: > java.lang.NullPointerException: null > at > java.util.concurrent.ConcurrentLinkedQueue.checkNotNull(ConcurrentLinkedQueue.java:914) > at > java.util.concurrent.ConcurrentLinkedQueue.offer(ConcurrentLinkedQueue.java:327) > at > java.util.concurrent.ConcurrentLinkedQueue.add(ConcurrentLinkedQueue.java:297) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:347) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicSingleUpdateFuture.addFailedKeys(GridDhtAtomicSingleUpdateFuture.java:166) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:446) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:56) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:345) > at > org.apache.ignite.internal.processors.cache.GridCacheMvccManager.cancelClientFutures(GridCacheMvccManager.java:388) > at > org.apache.ignite.internal.processors.cache.GridCacheMvccManager.onStop(GridCacheMvccManager.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:956) > at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2095) > at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2041) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2397) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2360) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:1871) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7526) SQL: Introduce memory region for reducer merge results with disk offload
[
https://issues.apache.org/jira/browse/IGNITE-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520282#comment-16520282
]
Taras Ledkov commented on IGNITE-7526:
--
Unfortunately H2 ResultTempTable isn't full appropriate for Ignite case.
H2 storage corrupts in simplest concurrent queries, e.g.: {{SELECT * FROM
}}
H2 Error (h2 version: 1.4.195):
{code}
java.lang.RuntimeException: old!=record pos:1037 old:page[1037] data leaf
table:30 TEMP_RESULT_SET_30 entries:0 parent:0 keys:null offsets:null
new:page[1037] data leaf table:29 TEMP_RESULT_SET_29 entries:28 parent:1051
keys:[309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322,
323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 350, 350]
offsets:[4004, 3912, 3820, 3728, 3636, 3544, 3452, 3360, 3268, 3176, 3084,
2992, 2900, 2808, 2716, 2624, 2532, 2440, 2348, 2256, 2164, 2072, 1980, 1888,
1796, 1704, 1612, 1520, 1428, 1336]
at org.h2.message.DbException.throwInternalError(DbException.java:242)
at org.h2.util.CacheLRU.update(CacheLRU.java:126)
at org.h2.store.PageStore.update(PageStore.java:1097)
at org.h2.index.PageDataNode.addRowTry(PageDataNode.java:139)
at org.h2.index.PageDataIndex.addTry(PageDataIndex.java:172)
at org.h2.index.PageDataIndex.add(PageDataIndex.java:135)
at org.h2.table.RegularTable.addRow(RegularTable.java:121)
{code}
I guess we have to implement our own implementation of the
{{org.h2.result.ResultExternal}} and patch the H2 to configure type of the
external result.
> SQL: Introduce memory region for reducer merge results with disk offload
>
>
> Key: IGNITE-7526
> URL: https://issues.apache.org/jira/browse/IGNITE-7526
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
>
> Currently all results received from map nodes are stored inside reducer's
> heap memory. What is worse, in case of complex queries, such as having sorts
> or groupings, need to collect all results from mappers first before final
> processing could be applied. In case of big results set (or intermediate
> results) this could easily lead to OOME on reducer.
> To mitigate this we should introduce special memory area where intermediate
> results could be stored. All final processing should be stored in the same
> area as well. This area should be of limited size and should be able to
> offload results to disk in case of overflow.
> We could start with our B+Tree and free list and store results in some K-V
> form.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8752) Deadlock when registering binary metadata while holding topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh updated IGNITE-8752:
-
Comment: was deleted
(was: https://ci.ignite.apache.org/viewQueued.html?itemId=1410836)
> Deadlock when registering binary metadata while holding topology read lock
> --
>
> Key: IGNITE-8752
> URL: https://issues.apache.org/jira/browse/IGNITE-8752
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DeadlockTest.java
>
>
> The following deadlock was reproduced on ignite-2.4 version:
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassName(BinaryContext.java:1191)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:773)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:622)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:875)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4667)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4484)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1732)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1736)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNea
[jira] [Commented] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520266#comment-16520266 ] Amelchev Nikita commented on IGNITE-8188: - [sergey-chugunov], I have some questions about the issue, If I understood correctly this methods should need to check request for this limit and if it is exceeded do nothing? I have looked at using these methods and when a batch operation fails it processes one-by-one everywhere. I have suggestions: 1) If the size of the request is exceeded, divide them into valid size batches and try to process by batches. 2) Make methods "max-size" + "NoNodeException/NodeExistsException" safe. If batch operation fails then process one-by-one in this methods. Because request processing one-by-one happens everywhere after failing batch operation it will allow to avoid code duplication and to close other issues(IGNITE-8189, TODO in cleanupPreviousClusterData()). > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520266#comment-16520266 ] Amelchev Nikita edited comment on IGNITE-8188 at 6/22/18 11:29 AM: --- [~sergey-chugunov], I have some questions about the issue, If I understood correctly this methods should need to check request for this limit and if it is exceeded do nothing? I have looked at using these methods and when a batch operation fails it processes one-by-one everywhere. I have suggestions: 1) If the size of the request is exceeded, divide them into valid size batches and try to process by batches. 2) Make methods "max-size" + "NoNodeException/NodeExistsException" safe. If batch operation fails then process one-by-one in this methods. Because request processing one-by-one happens everywhere after failing batch operation it will allow to avoid code duplication and to close other issues(IGNITE-8189, TODO in cleanupPreviousClusterData()). was (Author: nsamelchev): [sergey-chugunov], I have some questions about the issue, If I understood correctly this methods should need to check request for this limit and if it is exceeded do nothing? I have looked at using these methods and when a batch operation fails it processes one-by-one everywhere. I have suggestions: 1) If the size of the request is exceeded, divide them into valid size batches and try to process by batches. 2) Make methods "max-size" + "NoNodeException/NodeExistsException" safe. If batch operation fails then process one-by-one in this methods. Because request processing one-by-one happens everywhere after failing batch operation it will allow to avoid code duplication and to close other issues(IGNITE-8189, TODO in cleanupPreviousClusterData()). > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520224#comment-16520224
]
Ivan Daschinskiy edited comment on IGNITE-8820 at 6/22/18 11:28 AM:
[~ascherbakov]
1. Yes, I will add it to ExchangeFuture and explanation of my decision is below.
2. ExchangeFuture is waiting for partition release during init phase, so we are
hangs in exchFut.init, before exchFut.get()
{code:java}
exchFut.init(newCrd);
int dumpCnt = 0;
final long dumpTimeout = 2 *
cctx.gridConfig().getNetworkTimeout();
long nextDumpTime = 0;
while (true) {
try {
resVer = exchFut.get(dumpTimeout);
{code}
So rollback code is not neccessary at all in ExchangeManager. I'll refactor a
little bit exchangeFuture init and waitForPartitionRelease to ensure that
rollback logic executed once.
was (Author: ivandasch):
[~ascherbakov]
1. Yes, I will add it to ExchangeFuture and explanation is below.
2. ExchangeFuture are waiting for partition release during init phase, so we
are hangs in exchFut.init, before exchFut.get()
{code:java}
exchFut.init(newCrd);
int dumpCnt = 0;
final long dumpTimeout = 2 *
cctx.gridConfig().getNetworkTimeout();
long nextDumpTime = 0;
while (true) {
try {
resVer = exchFut.get(dumpTimeout);
{code}
So rollback code is not neccessary at all in ExchangeManager. I'll refactor a
little bit exchangeFuture init and waitForPartitionRelease to ensure that
rollback logic executed once.
> Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting
> for pending transactions.
> --
>
> Key: IGNITE-8820
> URL: https://issues.apache.org/jira/browse/IGNITE-8820
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, if ExchangeFuture waits whith old value of
> txTimeoutOnPartitionMapExchange, new value is not accepted until next
> exchange starts. Sometimes it's very usefull (while timeout is too long and
> must be shorter applied immediatelly)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8737) Improve checkpoint logging information
[
https://issues.apache.org/jira/browse/IGNITE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520261#comment-16520261
]
Andrew Medvedev commented on IGNITE-8737:
-
[~agoncharuk]
Thank you for you comments!
Now logs come in the following form (this is from test, checkpoints only):
{quote}Checkpoint finished [cpId=fb5fb8cf-c02d-409b-9245-c49a8b524ecc,
pages=22, markPos=FileWALPointer [idx=8, fileOff=89582, len=21409],
walSegmentsCleared=0, walSegmentsCovered=[0, 1, 2, 3, 4, 5, 6, 7],
markDuration=38ms, pagesWrite=35ms, fsync=84ms, total=157ms]
Checkpoint finished [cpId=7230d796-286d-4256-808a-bf61b8e7da95, pages=16662,
markPos=FileWALPointer [idx=12, fileOff=1504455, len=21409],
walSegmentsCleared=8, walSegmentsCovered=[8, 9, 10, 11], markDuration=53ms,
pagesWrite=330ms, fsync=209ms, total=592ms]
Checkpoint finished [cpId=2765afca-8a30-4010-b705-f864ef6e2316, pages=33311,
markPos=FileWALPointer [idx=16, fileOff=3855917, len=21409],
walSegmentsCleared=4, walSegmentsCovered=[12, 13, 14, 15], markDuration=79ms,
pagesWrite=334ms, fsync=174ms, total=588ms]
Checkpoint finished [cpId=5c1333d2-2434-456d-9c2c-a9b906a43c25, pages=33311,
markPos=FileWALPointer [idx=21, fileOff=6172282, len=21409],
walSegmentsCleared=4, walSegmentsCovered=[16, 17, 18, 19, 20],
markDuration=55ms, pagesWrite=375ms, fsync=255ms, total=685ms]
{quote}
TC [https://ci.ignite.apache.org/viewQueued.html?itemId=1414300]
PR https://github.com/apache/ignite/pull/4244
> Improve checkpoint logging information
> --
>
> Key: IGNITE-8737
> URL: https://issues.apache.org/jira/browse/IGNITE-8737
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Andrew Medvedev
>Priority: Major
> Fix For: 2.6
>
>
> 1) Move to INFO log rollover and log archivation events
> 2) Make sure log rollover and archive errors are logged
> 3) When checkpoint finishes, we need to print out which segments were fully
> covered by this checkpoint in the "Checkpoint finished ..." message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8737) Improve checkpoint logging information
[ https://issues.apache.org/jira/browse/IGNITE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520256#comment-16520256 ] ASF GitHub Bot commented on IGNITE-8737: Github user andrewmed closed the pull request at: https://github.com/apache/ignite/pull/4186 > Improve checkpoint logging information > -- > > Key: IGNITE-8737 > URL: https://issues.apache.org/jira/browse/IGNITE-8737 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Andrew Medvedev >Priority: Major > Fix For: 2.6 > > > 1) Move to INFO log rollover and log archivation events > 2) Make sure log rollover and archive errors are logged > 3) When checkpoint finishes, we need to print out which segments were fully > covered by this checkpoint in the "Checkpoint finished ..." message -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8737) Improve checkpoint logging information
[ https://issues.apache.org/jira/browse/IGNITE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520255#comment-16520255 ] ASF GitHub Bot commented on IGNITE-8737: GitHub user andrewmed opened a pull request: https://github.com/apache/ignite/pull/4244 IGNITE-8737: Improve checkpoint logging information You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmed/ignite ignite-8737-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4244.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4244 commit da94d37d4f8ad08dcc623eb594ecd6f41680fb40 Author: AMedvedev Date: 2018-06-22T11:15:25Z IGNITE-8737: Improve checkpoint logging information > Improve checkpoint logging information > -- > > Key: IGNITE-8737 > URL: https://issues.apache.org/jira/browse/IGNITE-8737 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Andrew Medvedev >Priority: Major > Fix For: 2.6 > > > 1) Move to INFO log rollover and log archivation events > 2) Make sure log rollover and archive errors are logged > 3) When checkpoint finishes, we need to print out which segments were fully > covered by this checkpoint in the "Checkpoint finished ..." message -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test
[
https://issues.apache.org/jira/browse/IGNITE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520239#comment-16520239
]
Peter Ivanov commented on IGNITE-8731:
--
It seems that downgrade is not possible, will try working OS image cloning.
> .NET: intermittent failures in DataStreamerTest.TestFinalizer test
> --
>
> Key: IGNITE-8731
> URL: https://issues.apache.org/jira/browse/IGNITE-8731
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {{DataStreamerTest.TsetFinalizer}} constantly fails on some TC agents, while
> work OK on others. Most likely we have an environmental issue.
> OK:
> # publicagent01_03_9090
> # publicagent02_02_9090
> Not OK:
> # publicagent01_01_9090
> # publicagent01_02_9090
> # publicagent02_01_9090
> # publicagent02_03_9090
> Quick comparison of agent's configuration reveals only one difference -
> version of PowerShell. On "good" machines it is {{5.1.16299.15}}, on "bad"
> machines it is {{5.1.17134.1}}.
> PowerShell is essential part of build infrastructure so chances that some
> incorrect dependencies are linked at some point. I am not sure that this
> might be the root cause of failures, but at the very least we can try.
> Let's downgrade PowerShell on one of affected machines and see if it works.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test
[
https://issues.apache.org/jira/browse/IGNITE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov reassigned IGNITE-8731:
Assignee: Peter Ivanov
> .NET: intermittent failures in DataStreamerTest.TestFinalizer test
> --
>
> Key: IGNITE-8731
> URL: https://issues.apache.org/jira/browse/IGNITE-8731
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {{DataStreamerTest.TsetFinalizer}} constantly fails on some TC agents, while
> work OK on others. Most likely we have an environmental issue.
> OK:
> # publicagent01_03_9090
> # publicagent02_02_9090
> Not OK:
> # publicagent01_01_9090
> # publicagent01_02_9090
> # publicagent02_01_9090
> # publicagent02_03_9090
> Quick comparison of agent's configuration reveals only one difference -
> version of PowerShell. On "good" machines it is {{5.1.16299.15}}, on "bad"
> machines it is {{5.1.17134.1}}.
> PowerShell is essential part of build infrastructure so chances that some
> incorrect dependencies are linked at some point. I am not sure that this
> might be the root cause of failures, but at the very least we can try.
> Let's downgrade PowerShell on one of affected machines and see if it works.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4939) Receive event before cache initialized
[
https://issues.apache.org/jira/browse/IGNITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520229#comment-16520229
]
Ilya Lantukh commented on IGNITE-4939:
--
Code changes look OK to me.
> Receive event before cache initialized
> --
>
> Key: IGNITE-4939
> URL: https://issues.apache.org/jira/browse/IGNITE-4939
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Receive event before cache initialized that leads to the following:
> {noformat}
> Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException:
> Cache is not configured: ignite-sys-cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8856) Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard fro type names
Vyacheslav Koptilin created IGNITE-8856:
---
Summary: Incorrect behavior of BinaryTypeConfiguration in case of
using a wildcard fro type names
Key: IGNITE-8856
URL: https://issues.apache.org/jira/browse/IGNITE-8856
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.5
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Let's consider the following BinaryConfiguration:
{code:java}
...
{code}
My intention is using custom BinaryBasicMapper for all classes in the specified
package and its sub packages,
but BinaryContext implementation matches only classes that reside in the
"org.apache.ignite.examples" package.
Classes from subpackages are not matched, and therefore do not use the
specified BinaryBasicNameMapper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8855) Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is significantly smaller than number of clients
Sergey Chugunov created IGNITE-8855: --- Summary: Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is significantly smaller than number of clients Key: IGNITE-8855 URL: https://issues.apache.org/jira/browse/IGNITE-8855 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov After fixing client nodes hangs in IGNITE-8567 another issue was found out: when EXCHANGE_HISTORY is significantly smaller than number of clients they interfere with each other on initial exchange and make reconnect attempts over and over again. To avoid this random delay (maybe exponential) should be added for clients before making new reconnect attempt. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520224#comment-16520224
]
Ivan Daschinskiy commented on IGNITE-8820:
--
[~ascherbakov]
1. Yes, I will add it to ExchangeFuture and explanation is below.
2. ExchangeFuture are waiting for partition release during init phase, so we
are hangs in exchFut.init, before exchFut.get()
{code:java}
exchFut.init(newCrd);
int dumpCnt = 0;
final long dumpTimeout = 2 *
cctx.gridConfig().getNetworkTimeout();
long nextDumpTime = 0;
while (true) {
try {
resVer = exchFut.get(dumpTimeout);
{code}
So rollback code is not neccessary at all in ExchangeManager. I'll refactor a
little bit exchangeFuture init and waitForPartitionRelease to ensure that
rollback logic executed once.
> Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting
> for pending transactions.
> --
>
> Key: IGNITE-8820
> URL: https://issues.apache.org/jira/browse/IGNITE-8820
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, if ExchangeFuture waits whith old value of
> txTimeoutOnPartitionMapExchange, new value is not accepted until next
> exchange starts. Sometimes it's very usefull (while timeout is too long and
> must be shorter applied immediatelly)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8854) !indexes and !primarykeys return nothing for o.a.i.IgniteJdbcDriver
Sergey Kozlov created IGNITE-8854:
-
Summary: !indexes and !primarykeys return nothing for
o.a.i.IgniteJdbcDriver
Key: IGNITE-8854
URL: https://issues.apache.org/jira/browse/IGNITE-8854
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.4
Reporter: Sergey Kozlov
# Start cluster
# Start {{bin/sqlline.sh -d org.apache.ignite.IgniteJdbcDriver ...}}
# Create tables with indexes like following:
{noformat}
3/151CREATE TABLE PUBLIC.CAR(ID INT PRIMARY KEY, PARKINGID INT NOT
NULL, NAME VARCHAR(255)) WITH "TEMPLATE=PARTITIONED";
No rows affected (0,249 seconds)
4/151CREATE TABLE PUBLIC.PARKING(ID INT PRIMARY KEY, NAME VARCHAR(255),
CAPACITY INT NOT NULL) WITH "TEMPLATE=REPLICATED";
No rows affected (0,155 seconds)
...
8/151!primarykeys PUBLIC.CAR
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
9/151!primarykeys PUBLIC.PARKING
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
...
12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
No rows affected (0.071 seconds)
13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
No rows affected (0.022 seconds)
14/151 !indexes
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
...
{noformat}
For {{ org.apache.ignite.IgniteJdbcDriver}} commands work as expected:
{noformat}
8/151!primarykeys PUBLIC.CAR
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
'','PUBLIC','CAR','_KEY','1','ID'
9/151!primarykeys PUBLIC.PARKING
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
'','PUBLIC','PARKING','_KEY','1','ID'
...
12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
No rows affected (0.067 seconds)
13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
No rows affected (0.023 seconds)
14/151 !indexes
'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
'','PUBLIC','CAR','true','','CAR_NAME_IDX','3','0','NAME','A','0','0',''
'','PUBLIC','PARKING','true','','PARKING_IDX','3','0','NAME','A','0','0',''
'','PUBLIC','PARKING','true','','PARKING_IDX','3','1','CAPACITY','A','0','0',''
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8854) sqlline: !indexes and !primarykeys return nothing for o.a.i.IgniteJdbcDriver
[
https://issues.apache.org/jira/browse/IGNITE-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-8854:
--
Summary: sqlline: !indexes and !primarykeys return nothing for
o.a.i.IgniteJdbcDriver (was: !indexes and !primarykeys return nothing for
o.a.i.IgniteJdbcDriver)
> sqlline: !indexes and !primarykeys return nothing for o.a.i.IgniteJdbcDriver
>
>
> Key: IGNITE-8854
> URL: https://issues.apache.org/jira/browse/IGNITE-8854
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.4
>Reporter: Sergey Kozlov
>Priority: Major
>
> # Start cluster
> # Start {{bin/sqlline.sh -d org.apache.ignite.IgniteJdbcDriver ...}}
> # Create tables with indexes like following:
> {noformat}
> 3/151CREATE TABLE PUBLIC.CAR(ID INT PRIMARY KEY, PARKINGID INT NOT
> NULL, NAME VARCHAR(255)) WITH "TEMPLATE=PARTITIONED";
> No rows affected (0,249 seconds)
> 4/151CREATE TABLE PUBLIC.PARKING(ID INT PRIMARY KEY, NAME
> VARCHAR(255), CAPACITY INT NOT NULL) WITH "TEMPLATE=REPLICATED";
> No rows affected (0,155 seconds)
> ...
> 8/151!primarykeys PUBLIC.CAR
> 'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
> 9/151!primarykeys PUBLIC.PARKING
> 'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
> ...
> 12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
> No rows affected (0.071 seconds)
> 13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
> No rows affected (0.022 seconds)
> 14/151 !indexes
> 'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
> ...
> {noformat}
> For {{ org.apache.ignite.IgniteJdbcDriver}} commands work as expected:
> {noformat}
> 8/151!primarykeys PUBLIC.CAR
> 'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
> '','PUBLIC','CAR','_KEY','1','ID'
> 9/151!primarykeys PUBLIC.PARKING
> 'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','COLUMN_NAME','KEY_SEQ','PK_NAME'
> '','PUBLIC','PARKING','_KEY','1','ID'
> ...
> 12/151 CREATE INDEX CAR_NAME_IDX ON PUBLIC.CAR(NAME);
> No rows affected (0.067 seconds)
> 13/151 CREATE INDEX PARKING_IDX ON PUBLIC.PARKING(NAME, CAPACITY);
> No rows affected (0.023 seconds)
> 14/151 !indexes
> 'TABLE_CAT','TABLE_SCHEM','TABLE_NAME','NON_UNIQUE','INDEX_QUALIFIER','INDEX_NAME','TYPE','ORDINAL_POSITION','COLUMN_NAME','ASC_OR_DESC','CARDINALITY','PAGES','FILTER_CONDITION'
> '','PUBLIC','CAR','true','','CAR_NAME_IDX','3','0','NAME','A','0','0',''
> '','PUBLIC','PARKING','true','','PARKING_IDX','3','0','NAME','A','0','0',''
> '','PUBLIC','PARKING','true','','PARKING_IDX','3','1','CAPACITY','A','0','0',''
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly
[
https://issues.apache.org/jira/browse/IGNITE-8436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520217#comment-16520217
]
Maxim Muzafarov commented on IGNITE-8436:
-
[~dpavlov], [~vkulichenko]
Hello,
Changes looks good to me (except changing a little bit method signature which
is not related to this change).
Can we proceed with this?
> Executor service for services does not shutdown properly
>
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
> Labels: newbie
> Fix For: 2.6
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802]
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls
> Grid life cycle and allows listening for grid events.
> As cotributor, you should ensure that execution pool shutdowns properly and
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8428: - Fix Version/s: 2.7 > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-8428. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. Please retest. > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8428: Assignee: Alexey Kuznetsov > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520210#comment-16520210 ] ASF GitHub Bot commented on IGNITE-8428: Github user akuznetsov-gridgain closed the pull request at: https://github.com/apache/ignite/pull/4221 > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8462) DataStreamerImpl.close(true) should done all futures
[ https://issues.apache.org/jira/browse/IGNITE-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-8462. -- Resolution: Fixed Merged to master branch. Thanks for contribution. > DataStreamerImpl.close(true) should done all futures > > > Key: IGNITE-8462 > URL: https://issues.apache.org/jira/browse/IGNITE-8462 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > DataStreamerImpl.close(true) should throw CacheException in case if there was > addition data to DataStreamerImpl. Future, returned by > DataStreamerImpl.addData() also should be done after close streamer. > Update. New design for this ticket is described in comments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8462) DataStreamerImpl.close(true) should done all futures
[ https://issues.apache.org/jira/browse/IGNITE-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-8462: - Summary: DataStreamerImpl.close(true) should done all futures (was: DataStreamerImpl.close(true) should throw exception) > DataStreamerImpl.close(true) should done all futures > > > Key: IGNITE-8462 > URL: https://issues.apache.org/jira/browse/IGNITE-8462 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > DataStreamerImpl.close(true) should throw CacheException in case if there was > addition data to DataStreamerImpl. Future, returned by > DataStreamerImpl.addData() also should be done after close streamer. > Update. New design for this ticket is described in comments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8747) Remove\RemoveAll method should not count expired entry as removed.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8747: - Comment: was deleted (was: Need to check if it is fixes IGNITE-305.) > Remove\RemoveAll method should not count expired entry as removed. > -- > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > Fix For: 2.6 > > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8774) Daemon moves cluster to compatibility mode when joins
[
https://issues.apache.org/jira/browse/IGNITE-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520202#comment-16520202
]
ASF GitHub Bot commented on IGNITE-8774:
GitHub user alex-plekhanov opened a pull request:
https://github.com/apache/ignite/pull/4243
IGNITE-8774 Daemon moves cluster to compatibility mode when joins
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alex-plekhanov/ignite ignite-8774
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4243.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4243
commit 0e7b5be1d76ee0742a615e3a892e556d86d3f668
Author: Aleksey Plekhanov
Date: 2018-06-22T10:00:50Z
IGNITE-8774 Daemon moves cluster to compatibility mode when joins
> Daemon moves cluster to compatibility mode when joins
> -
>
> Key: IGNITE-8774
> URL: https://issues.apache.org/jira/browse/IGNITE-8774
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.6
>
>
> When a daemon node joins the cluster seems to switch to compatibility mode
> (allowing nodes without baseline support). It prevents baseline nodes from
> being restarted.
> Example:
> {code}
> Ignite ignite1 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv1");
> Ignite ignite2 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> ignite2.cluster().active(true);
> IgnitionEx.setClientMode(true);
> IgnitionEx.setDaemon(true);
> Ignite daemon =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "daemon");
> IgnitionEx.setClientMode(false);
> IgnitionEx.setDaemon(false);
> ignite2.close();
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> {code}
> The attempt to restart ignite2 throws an exception:
> {code}
> [2018-06-11 18:45:25,766][ERROR][tcp-disco-msg-worker-#39%srv2%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteException: Node with BaselineTopology cannot join mixed cluster
> running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:714)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:883)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4354)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520147#comment-16520147
]
Anton Vinogradov commented on IGNITE-640:
-
[~aakhmedov],
I checked your solution and found you made multimap similar to IgniteQueue.
Could you please explain reasons to choosing such approach?
Some issues with such approach:
1) multimap.size() is not consistent.
"Add" and "set sise" are two sparated atomic operations, so it's possible to
have 1M keys inside multimap, but see size 1K.
2)You duplicated all IgniteQueue structures
- CollocatedMultimapItemKey
- GridCacheMultimapHeader
- GridCacheMultimapHeaderKey
- GridCacheMultimapItemKey
- MultimapItemKey
3) You added methods almost equals to IgniteSet's methods to "cast" IgniteQueue
to IgniteMultimap.
For example
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor#getCollection
->
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor#getMultimap
I'm proposing to refactor this implementation to use IgniteSet as a base
1) size() method can be shared between IgniteSet and IgniteMultimap without
modifications
2) IgniteSet's datastructures
- CollocatedSetItemKey
- SetItemKey
- GridCacheSetHeader
- GridCacheSetHeaderKey
- GridCacheSetItemKey
can be reused without modification. You can rename them to ***Map***.
3) As far as I can see, all you need to do in that case is to implement
GridCacheMultimapImpl based on GridCacheAbstractMapImpl.
GridCacheAbstractMapImpl will contains methods shared between IgniteMultimap
and IgniteSet in that case , eg. size() or clear().
Thoughts?
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.6
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> Lis
[jira] [Commented] (IGNITE-8807) Apache Ignite Linux packages 2.6 update
[ https://issues.apache.org/jira/browse/IGNITE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520145#comment-16520145 ] ASF GitHub Bot commented on IGNITE-8807: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4195 > Apache Ignite Linux packages 2.6 update > --- > > Key: IGNITE-8807 > URL: https://issues.apache.org/jira/browse/IGNITE-8807 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.6 > > > Update RPM and DEB packages' specifications for 2.6 release. > h3. How to test > ([artifacts|https://ci.ignite.apache.org/viewLog.html?buildId=1390464&buildTypeId=Releases_NightlyRelease_ApacheIgniteNightlyRelease3AssemblePackages&tab=artifacts]) > # Bare linux RPM / DEB installation. > # Bare linux RPM / DEB upgrade (from all versions). > # Windows 10 WSL Ubuntu DEB installation and upgrade. > # Windows 10 WSL Debian DEB installation and upgrade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8853) Test CacheSerializableTransactionsTest#testIncrementTxRestart fails on TC
Sergey Chugunov created IGNITE-8853:
---
Summary: Test
CacheSerializableTransactionsTest#testIncrementTxRestart fails on TC
Key: IGNITE-8853
URL: https://issues.apache.org/jira/browse/IGNITE-8853
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
Test started to fail after implementing IGNITE-8657.
There is the following message in logs that makes it clear what happens:
{noformat}
junit.framework.AssertionFailedError: Unexpected exception [err=class
org.apache.ignite.IgniteException: Node need try to reconnect
[nodeId=5a7cfccb-d87e-4d2a-b044-f0a43e36], cause=class
org.apache.ignite.internal.IgniteNeedReconnectException: Node need try to
reconnect [nodeId=5a7cfccb-d87e-4d2a-b044-f0a43e36]]
{noformat}
IGNITE-8657 fixed issue with client nodes hanging when their initial
ExchangeFutures were preempted from exchange queue on coordinator because of
EXCHANGE_HISTORY setting.
It turned out that for some reason client may be instructed to reconnect even
when it has already joined topology but now server node joining or leaving it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode
[
https://issues.apache.org/jira/browse/IGNITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520122#comment-16520122
]
Tim Shea commented on IGNITE-6346:
--
I am a user in the wild hitting this bug. :( Just FYI since I see an open pull
request to fix it..
> Distributed set does not work in REPLICATED mode
>
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>Priority: Major
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
> at ReplicatedSet.main(ReplicatedSet.java:36)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
> ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520123#comment-16520123 ] Alexei Scherbakov commented on IGNITE-8820: --- [~ivandasch], 1. You've removed important message "Consider changing TransactionConfiguration.txTimeoutOnPartitionMapSynchronization to non default value to avoid this message". Please return it back with valid property reference: txTimeoutOnPartitionMapExchange 2. You should ensure what tx rollback attempt is performed only once. I suggest removing duplicated code from exchange future (because waitPartitionRelease is called twice) and keep it only in exchange manager. > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8852) CacheJoinNodeDiscoveryData.CacheInfo has boolean flags and long field for flags
Dmitry Karachentsev created IGNITE-8852: --- Summary: CacheJoinNodeDiscoveryData.CacheInfo has boolean flags and long field for flags Key: IGNITE-8852 URL: https://issues.apache.org/jira/browse/IGNITE-8852 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Dmitry Karachentsev Fix For: 3.0 CacheJoinNodeDiscoveryData.CacheInfo has two types of flags: boolean stored in fields and long. Latter is not used. Should be picked one approach: or boolean fields, or bitmask, not both. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8851) StoredCacheData and CacheJoinNodeDiscoveryData.CacheInfo duplicate "sql" flag
Dmitry Karachentsev created IGNITE-8851: --- Summary: StoredCacheData and CacheJoinNodeDiscoveryData.CacheInfo duplicate "sql" flag Key: IGNITE-8851 URL: https://issues.apache.org/jira/browse/IGNITE-8851 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Dmitry Karachentsev Fix For: 3.0 Node when joins cluster sends cache configurations. Configuration is wrapped into StoredCacheData, and StoredCacheData into CacheJoinNodeDiscoveryData.CacheInfo. Both CacheInfo and StoredCacheData have "sql" flag that seems means the same. It should appear only once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520104#comment-16520104 ] Ivan Daschinskiy commented on IGNITE-8820: -- [~ascherbakov] Alexei, I've just removed some copypaste from GridPartitionExchangeManager, kept all logic regarding transactions rollback when waiting for partition release in GridDhtPartitionsExchangeFuture. Could you please take a look again? > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8746) EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node
[ https://issues.apache.org/jira/browse/IGNITE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520076#comment-16520076 ] ASF GitHub Bot commented on IGNITE-8746: GitHub user pvinokurov opened a pull request: https://github.com/apache/ignite/pull/4242 IGNITE-8746 EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice … …on the coordinator node You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8746 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4242.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4242 commit 0cfb33faabd1a008117d38b2a6433c873c5ab897 Author: pvinokurov Date: 2018-06-22T06:46:15Z IGNITE-8746 EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node > EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator > node > --- > > Key: IGNITE-8746 > URL: https://issues.apache.org/jira/browse/IGNITE-8746 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Priority: Major > Fix For: 2.6 > > Attachments: EvtDataLostTwiceOnCoordinatorReprocuder.java > > > After a node left the cluster the coordinator recieves the partition lost > event twice. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
