[jira] [Updated] (IGNITE-10682) Disable unnecessary loaded plugins for the Inspection test suite
[
https://issues.apache.org/jira/browse/IGNITE-10682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10682:
-
Ignite Flags: (was: Docs Required)
> Disable unnecessary loaded plugins for the Inspection test suite
>
>
> Key: IGNITE-10682
> URL: https://issues.apache.org/jira/browse/IGNITE-10682
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> As part of discussion [1] we've faced with the problem: the set of
> unnecessary plugins are loaded during the Inspection test suite run. This
> leads to unnecessary checking inspection rules which are not used in the
> Apache Ignite project and wasting agent CPU resources.
> The log can be found at [2] execution suite results.
> {code}
> > 46 plugins initialized in 1031 ms
> > 2018-12-13 10:55:24,875 [ 1342] INFO - llij.ide.plugins.PluginManager -
> > Loaded bundled plugins: Android Support (10.2.3), Ant Support (1.0), CSS
> > Support (172.4574.11), Database Tools and SQL (172.4574.11), Eclipse
> > Integration (3.0), FreeMarker support (1.0), GWT Support (1.0), Gradle
> > (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools (2.0), Hibernate
> > Support (1.0), I18n for Java (172.4574.11), IDEA CORE (172.4574.11),
> > IntelliLang (8.0), JBoss Seam Support (1.0), JUnit (1.0), Java EE: Bean
> > Validation Support (1.1), Java EE: Contexts and Dependency Injection (1.1),
> > Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server Faces (2.2.X.),
> > Java EE: Web Services (JAX-WS) (1.9), Java Server Pages (JSP) Integration
> > (1.0), JavaScript Support (1.0), Kotlin (1.1.4-release-IJ2017.2-3), Maven
> > Integration (172.4574.11), Persistence Frameworks Support (1.0), Plugin
> > DevKit (1.0), Properties Support (172.4574.11), QuirksMode (172.4574.11),
> > Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring Data (1.0), Spring
> > Integration Patterns (1.0), Spring Security (1.0), Spring Support (1.0),
> > Spring Web Flow (1.0), Spring Web Services (1.0), Struts 1.x (2.0), Struts
> > 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11), Velocity support (1.0),
> > W3C Validators (2.0), WebLogic Integration (1.0), XPathView + XSLT Support
> > (4)
> {code}
> We need to disable these loaded plugins as they don't need for checking core
> inspection rules.
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p39471.html
> [2]
> https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10682) Disable unnecessary loaded plugins for the Inspection test suite
[
https://issues.apache.org/jira/browse/IGNITE-10682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10682:
-
Fix Version/s: 2.8
> Disable unnecessary loaded plugins for the Inspection test suite
>
>
> Key: IGNITE-10682
> URL: https://issues.apache.org/jira/browse/IGNITE-10682
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> As part of discussion [1] we've faced with the problem: the set of
> unnecessary plugins are loaded during the Inspection test suite run. This
> leads to unnecessary checking inspection rules which are not used in the
> Apache Ignite project and wasting agent CPU resources.
> The log can be found at [2] execution suite results.
> {code}
> > 46 plugins initialized in 1031 ms
> > 2018-12-13 10:55:24,875 [ 1342] INFO - llij.ide.plugins.PluginManager -
> > Loaded bundled plugins: Android Support (10.2.3), Ant Support (1.0), CSS
> > Support (172.4574.11), Database Tools and SQL (172.4574.11), Eclipse
> > Integration (3.0), FreeMarker support (1.0), GWT Support (1.0), Gradle
> > (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools (2.0), Hibernate
> > Support (1.0), I18n for Java (172.4574.11), IDEA CORE (172.4574.11),
> > IntelliLang (8.0), JBoss Seam Support (1.0), JUnit (1.0), Java EE: Bean
> > Validation Support (1.1), Java EE: Contexts and Dependency Injection (1.1),
> > Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server Faces (2.2.X.),
> > Java EE: Web Services (JAX-WS) (1.9), Java Server Pages (JSP) Integration
> > (1.0), JavaScript Support (1.0), Kotlin (1.1.4-release-IJ2017.2-3), Maven
> > Integration (172.4574.11), Persistence Frameworks Support (1.0), Plugin
> > DevKit (1.0), Properties Support (172.4574.11), QuirksMode (172.4574.11),
> > Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring Data (1.0), Spring
> > Integration Patterns (1.0), Spring Security (1.0), Spring Support (1.0),
> > Spring Web Flow (1.0), Spring Web Services (1.0), Struts 1.x (2.0), Struts
> > 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11), Velocity support (1.0),
> > W3C Validators (2.0), WebLogic Integration (1.0), XPathView + XSLT Support
> > (4)
> {code}
> We need to disable these loaded plugins as they don't need for checking core
> inspection rules.
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p39471.html
> [2]
> https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10682) Disable unnecessary loaded plugins for the Inspection test suite
Maxim Muzafarov created IGNITE-10682:
Summary: Disable unnecessary loaded plugins for the Inspection
test suite
Key: IGNITE-10682
URL: https://issues.apache.org/jira/browse/IGNITE-10682
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
As part of discussion [1] we've faced with the problem: the set of unnecessary
plugins are loaded during the Inspection test suite run. This leads to
unnecessary checking inspection rules which are not used in the Apache Ignite
project and wasting agent CPU resources.
The log can be found at [2] execution suite results.
{code}
> 46 plugins initialized in 1031 ms
> 2018-12-13 10:55:24,875 [ 1342] INFO - llij.ide.plugins.PluginManager -
> Loaded bundled plugins: Android Support (10.2.3), Ant Support (1.0), CSS
> Support (172.4574.11), Database Tools and SQL (172.4574.11), Eclipse
> Integration (3.0), FreeMarker support (1.0), GWT Support (1.0), Gradle
> (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools (2.0), Hibernate
> Support (1.0), I18n for Java (172.4574.11), IDEA CORE (172.4574.11),
> IntelliLang (8.0), JBoss Seam Support (1.0), JUnit (1.0), Java EE: Bean
> Validation Support (1.1), Java EE: Contexts and Dependency Injection (1.1),
> Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server Faces (2.2.X.),
> Java EE: Web Services (JAX-WS) (1.9), Java Server Pages (JSP) Integration
> (1.0), JavaScript Support (1.0), Kotlin (1.1.4-release-IJ2017.2-3), Maven
> Integration (172.4574.11), Persistence Frameworks Support (1.0), Plugin
> DevKit (1.0), Properties Support (172.4574.11), QuirksMode (172.4574.11),
> Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring Data (1.0), Spring
> Integration Patterns (1.0), Spring Security (1.0), Spring Support (1.0),
> Spring Web Flow (1.0), Spring Web Services (1.0), Struts 1.x (2.0), Struts
> 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11), Velocity support (1.0),
> W3C Validators (2.0), WebLogic Integration (1.0), XPathView + XSLT Support
> (4)
{code}
We need to disable these loaded plugins as they don't need for checking core
inspection rules.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p39471.html
[2]
https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10239) Web Console: Create a new top menu
[ https://issues.apache.org/jira/browse/IGNITE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16721026#comment-16721026 ] Ilya Borisov commented on IGNITE-10239: --- [~anovikov] all done. > Web Console: Create a new top menu > -- > > Key: IGNITE-10239 > URL: https://issues.apache.org/jira/browse/IGNITE-10239 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Andrey Novikov >Priority: Major > Attachments: Top-ignite-menu.png, navigation links block scroll > example.png, new design example.png > > Time Spent: 10h 55m > Remaining Estimate: 0h > > New navigation menu design moves navigation to left sidebar in order to save > some vertical space. The sidebar with navigation links has two modes - > collapsed, with icon-only link, and expanded, with full-text links. By > default, it's kept collapsed, but user can click on toggle sidebar button > left of logo to expand or collapse it again. For now, the sidebar state does > not persist between page reloads. The footer should be moved to expanded > sidebar, except for public screens like "sign in" or "reset password". > Navigation links block in sidebar should scroll and indicate that some > content is hidden when viewport height is low enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10239) Web Console: Create a new top menu
[ https://issues.apache.org/jira/browse/IGNITE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10239: - Assignee: Andrey Novikov (was: Ilya Borisov) > Web Console: Create a new top menu > -- > > Key: IGNITE-10239 > URL: https://issues.apache.org/jira/browse/IGNITE-10239 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Andrey Novikov >Priority: Major > Attachments: Top-ignite-menu.png, navigation links block scroll > example.png, new design example.png > > Time Spent: 10h 55m > Remaining Estimate: 0h > > New navigation menu design moves navigation to left sidebar in order to save > some vertical space. The sidebar with navigation links has two modes - > collapsed, with icon-only link, and expanded, with full-text links. By > default, it's kept collapsed, but user can click on toggle sidebar button > left of logo to expand or collapse it again. For now, the sidebar state does > not persist between page reloads. The footer should be moved to expanded > sidebar, except for public screens like "sign in" or "reset password". > Navigation links block in sidebar should scroll and indicate that some > content is hidden when viewport height is low enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.
[ https://issues.apache.org/jira/browse/IGNITE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8245: Assignee: Pavel Konstantinov (was: Ilya Borisov) > Web console: "Warning" icon is displayed above "secured key" icon. > -- > > Key: IGNITE-8245 > URL: https://issues.apache.org/jira/browse/IGNITE-8245 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.4 >Reporter: Andrey Novikov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > warning_icon.png > > > See attachment. Reproduced in Safari. > Make the actual input borderless, move the border to outer element, shrink > the input element when an error notification has to be shown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.
[ https://issues.apache.org/jira/browse/IGNITE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16721015#comment-16721015 ] Ilya Borisov commented on IGNITE-8245: -- [~pkonstantinov] can't reproduce. > Web console: "Warning" icon is displayed above "secured key" icon. > -- > > Key: IGNITE-8245 > URL: https://issues.apache.org/jira/browse/IGNITE-8245 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.4 >Reporter: Andrey Novikov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > warning_icon.png > > > See attachment. Reproduced in Safari. > Make the actual input borderless, move the border to outer element, shrink > the input element when an error notification has to be shown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10239) Web Console: Create a new top menu
[ https://issues.apache.org/jira/browse/IGNITE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-10239: --- Assignee: Ilya Borisov (was: Andrey Novikov) > Web Console: Create a new top menu > -- > > Key: IGNITE-10239 > URL: https://issues.apache.org/jira/browse/IGNITE-10239 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Major > Attachments: Top-ignite-menu.png, navigation links block scroll > example.png, new design example.png > > Time Spent: 10h 55m > Remaining Estimate: 0h > > New navigation menu design moves navigation to left sidebar in order to save > some vertical space. The sidebar with navigation links has two modes - > collapsed, with icon-only link, and expanded, with full-text links. By > default, it's kept collapsed, but user can click on toggle sidebar button > left of logo to expand or collapse it again. For now, the sidebar state does > not persist between page reloads. The footer should be moved to expanded > sidebar, except for public screens like "sign in" or "reset password". > Navigation links block in sidebar should scroll and indicate that some > content is hidden when viewport height is low enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10239) Web Console: Create a new top menu
[ https://issues.apache.org/jira/browse/IGNITE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16721000#comment-16721000 ] Andrey Novikov commented on IGNITE-10239: - [~Klaster_1] I added several comments in GitHub PR, please check them out. > Web Console: Create a new top menu > -- > > Key: IGNITE-10239 > URL: https://issues.apache.org/jira/browse/IGNITE-10239 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Andrey Novikov >Priority: Major > Attachments: Top-ignite-menu.png, navigation links block scroll > example.png, new design example.png > > Time Spent: 10h 55m > Remaining Estimate: 0h > > New navigation menu design moves navigation to left sidebar in order to save > some vertical space. The sidebar with navigation links has two modes - > collapsed, with icon-only link, and expanded, with full-text links. By > default, it's kept collapsed, but user can click on toggle sidebar button > left of logo to expand or collapse it again. For now, the sidebar state does > not persist between page reloads. The footer should be moved to expanded > sidebar, except for public screens like "sign in" or "reset password". > Navigation links block in sidebar should scroll and indicate that some > content is hidden when viewport height is low enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10680) Add the ability to use existing shared cache context in standalone WAL iterator
[
https://issues.apache.org/jira/browse/IGNITE-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10680:
---
Summary: Add the ability to use existing shared cache context in standalone
WAL iterator (was: Add the ability to use started kernel context in standalone
WAL iterator)
> Add the ability to use existing shared cache context in standalone WAL
> iterator
> ---
>
> Key: IGNITE-10680
> URL: https://issues.apache.org/jira/browse/IGNITE-10680
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In the current implementation it's only possible to use fake kernel context
> in standalone WAL iterator. If we need to use binary meta from the running
> Ignite node we must specify binary meta directory in parameters of standalone
> WAL iterator factory. But there is a possible race with binary meta files
> read/write since binary meta received with {{MetadataUpdateProposedMessage}}
> can be written to the file and concurrently read from the same file at the
> same time. This can lead to assertions like the following:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
> {noformat}
> To solve this we can use in standalone WAL iterator existing kernel context
> of the started node instead of creating new fake one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10680) Add the ability to use existing kernel context in standalone WAL iterator
[
https://issues.apache.org/jira/browse/IGNITE-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10680:
---
Summary: Add the ability to use existing kernel context in standalone WAL
iterator (was: Add the ability to use existing shared cache context in
standalone WAL iterator)
> Add the ability to use existing kernel context in standalone WAL iterator
> -
>
> Key: IGNITE-10680
> URL: https://issues.apache.org/jira/browse/IGNITE-10680
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In the current implementation it's only possible to use fake kernel context
> in standalone WAL iterator. If we need to use binary meta from the running
> Ignite node we must specify binary meta directory in parameters of standalone
> WAL iterator factory. But there is a possible race with binary meta files
> read/write since binary meta received with {{MetadataUpdateProposedMessage}}
> can be written to the file and concurrently read from the same file at the
> same time. This can lead to assertions like the following:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
> {noformat}
> To solve this we can use in standalone WAL iterator existing kernel context
> of the started node instead of creating new fake one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10680) Add the ability to use existing shared cache context in standalone WAL iterator
[
https://issues.apache.org/jira/browse/IGNITE-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10680:
---
Description:
In the current implementation it's only possible to use fake kernel context in
standalone WAL iterator. If we need to use binary meta from the running Ignite
node we must specify binary meta directory in parameters of standalone WAL
iterator factory. But there is a possible race with binary meta files
read/write since binary meta received with {{MetadataUpdateProposedMessage}}
can be written to the file and concurrently read from the same file at the same
time. This can lead to assertions like the following:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
{noformat}
To solve this we can use in standalone WAL iterator existing kernel context of
the started node instead of creating new fake one.
was:
In the current implementation it's only possible to use fake shared cache
context in standalone WAL iterator. If we need to use binary meta from the
running Ignite node we must specify binary meta directory in parameters of
standalone WAL iterator factory. But there is a possible race with binary meta
files read/write since binary meta received with
{{MetadataUpdateProposedMessage}} can be written to the file and concurrently
read from the same file at the same time. This can lead to assertions like the
following:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
{noformat}
To solve this we can use in standalone WAL iterator existing kernel context of
the started node instead of creating new fake one.
> Add the ability to use existing shared cache context in standalone WAL
> iterator
> ---
>
> Key: IGNITE-10680
> URL: https://issues.apache.org/jira/browse/IGNITE-10680
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In the current implementation it's only possible to use fake kernel context
> in standalone WAL iterator. If we need to use binary meta from the running
> Ignite node we must specify binary meta directory in
[jira] [Updated] (IGNITE-10680) Add the ability to use existing shared cache context in standalone WAL iterator
[
https://issues.apache.org/jira/browse/IGNITE-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10680:
---
Description:
In the current implementation it's only possible to use fake shared cache
context in standalone WAL iterator. If we need to use binary meta from the
running Ignite node we must specify binary meta directory in parameters of
standalone WAL iterator factory. But there is a possible race with binary meta
files read/write since binary meta received with
{{MetadataUpdateProposedMessage}} can be written to the file and concurrently
read from the same file at the same time. This can lead to assertions like the
following:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
{noformat}
To solve this we can use in standalone WAL iterator existing kernel context of
the started node instead of creating new fake one.
was:
In the current implementation it's only possible to use fake kernel context in
standalone WAL iterator. If we need to use binary meta from the running Ignite
node we must specify binary meta directory in parameters of standalone WAL
iterator factory. But there is a possible race with binary meta files
read/write since binary meta received with {{MetadataUpdateProposedMessage}}
can be written to the file and concurrently read from the same file at the same
time. This can lead to assertions like the following:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
{noformat}
To solve this we can use in standalone WAL iterator existing kernel context of
the started node instead of creating new fake one.
> Add the ability to use existing shared cache context in standalone WAL
> iterator
> ---
>
> Key: IGNITE-10680
> URL: https://issues.apache.org/jira/browse/IGNITE-10680
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In the current implementation it's only possible to use fake shared cache
> context in standalone WAL iterator. If we need to use binary meta from the
> running Ignite node we must specify binary meta
[jira] [Commented] (IGNITE-10324) Disallow fallback to Scanner in control.sh when asking password
[ https://issues.apache.org/jira/browse/IGNITE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720986#comment-16720986 ] Pavel Voronkin commented on IGNITE-10324: - [~a-polyakov] i've put one comment, please check. > Disallow fallback to Scanner in control.sh when asking password > --- > > Key: IGNITE-10324 > URL: https://issues.apache.org/jira/browse/IGNITE-10324 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Alexand Polyakov >Priority: Major > > After implementing IGNITE-9990 we still can fallback to Scanner in case of > Console is not allowed, user can easily fallback to non-secure mode by using > some java agent. We should not allow this, cause otherwise all efforts in > IGNITE-9990 are useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10679) Add more debug info for 'Affinity changes' PME stage.
Pavel Voronkin created IGNITE-10679:
---
Summary: Add more debug info for 'Affinity changes' PME stage.
Key: IGNITE-10679
URL: https://issues.apache.org/jira/browse/IGNITE-10679
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Voronkin
At current stage of PME time optimizations, next possible target to optimize is
'Affinity changes' apply stage, because it starts to slowdown PME when
configured number of partitions is increased (up to 32k)
We need to add more debug information to understand what is the sources of
slowdown.
Example log:
{noformat}
[15:21:55,326][INFO][sys-#121][GridDhtPartitionsExchangeFuture] Received full
message, will finish exchange [node=8ca2f878-70cf-4d34-a3ea-97b244f8d3d6,
resVer=AffinityTopologyVersion [topVer=13, minorTopVer=0]]
[15:21:55,725][INFO][sys-#121][CacheAffinitySharedManager] Affinity applying
from full message performed in 398 ms.
[15:21:56,173][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=740ms, reason='timeout']
[15:21:57,150][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping checkpoint (no pages were modified) [checkpointLockWait=13ms,
checkpointLockHoldTime=699ms, reason='timeout']
[15:21:58,189][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping checkpoint (no pages were modified) [checkpointLockWait=4ms,
checkpointLockHoldTime=730ms, reason='timeout']
[15:21:58,340][INFO][sys-#121][GridDhtPartitionsExchangeFuture] Affinity
changes applied in 3013 ms.
[15:21:59,131][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping checkpoint (no pages were modified) [checkpointLockWait=6ms,
checkpointLockHoldTime=664ms, reason='timeout']
[15:21:59,311][INFO][sys-#121][GridDhtPartitionsExchangeFuture] Full map
updating for 67 groups performed in 971 ms.
[15:21:59,311][INFO][sys-#121][GridDhtPartitionsExchangeFuture] Finish exchange
future [startVer=AffinityTopologyVersion [topVer=13, minorTopVer=0],
resVer=AffinityTopologyVersion [topVer=13, minorTopVer=0], err=null]
[15:22:00,039][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping checkpoint (no pages were modified) [checkpointLockWait=4ms,
checkpointLockHoldTime=569ms, reason='timeout']
[15:22:00,108][INFO][sys-#121][GridDhtPartitionsExchangeFuture] Detecting lost
partitions performed in 796 ms.
[15:22:00,376][WARNING][sys-stripe-14-#15][finish] Received finish request for
completed transaction (the message may be too late) [txId=GridCacheVersion
[topVer=153677859, order=1542197978690, nodeOrder=10], dhtTxId=null,
node=ca22eac2-862a-4fed-a84b-4abe85bfab25, commit=false]
[15:22:00,376][WARNING][sys-stripe-9-#10][finish] Received finish request for
completed transaction (the message may be too late) [txId=GridCacheVersion
[topVer=153677859, order=1542197978695, nodeOrder=10], dhtTxId=null,
node=ca22eac2-862a-4fed-a84b-4abe85bfab25, commit=false]
[15:22:00,376][WARNING][sys-stripe-10-#11][GridDhtColocatedCache]
Failed to acquire lock (transaction has been completed):
GridCacheVersion [topVer=153677859, order=1542197978695, nodeOrder=10]
[15:22:00,376][WARNING][sys-stripe-11-#12][GridDhtColocatedCache]
Failed to acquire lock (transaction has been completed):
GridCacheVersion [topVer=153677859, order=1542197978690, nodeOrder=10]
[15:22:01,404][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping checkpoint (no pages were modified) [checkpointLockWait=2ms,
checkpointLockHoldTime=928ms, reason='timeout']
[15:22:02,069][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Checkpoint started [checkpointId=4a3ff280-b07c-48fc-8352-dd1b09e4ddbb,
startPtr=FileWALPointer [idx=35, fileOff=11841470, len=11791007],
checkpointLockWait=5ms, checkpointLockHoldTime=568ms,
walCpRecordFsyncDuration=14ms, pages=12, reason='timeout']
[15:22:02,070][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Checkpoint finished [cpId=4a3ff280-b07c-48fc-8352-dd1b09e4ddbb, pages=12,
markPos=FileWALPointer [idx=35, fileOff=11841470, len=11791007],
walSegmentsCleared=0, walSegmentsCovered=[], markDuration=584ms,
pagesWrite=0ms, fsync=1ms, total=590ms]
[15:22:02,476][INFO][exchange-worker-#66][GridCachePartitionExchangeManager]
Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
[topVer=13, minorTopVer=0], evt=NODE_FAILED,
node=a10011b8-7431-4bba-8b17-565a2a2be222]
[15:22:02,760][WARNING][sys-stripe-11-#12][finish] Received finish request for
completed transaction (the message may be too late) [txId=GridCacheVersion
[topVer=153677859, order=1542197978805, nodeOrder=10], dhtTxId=null,
node=ca22eac2-862a-4fed-a84b-4abe85bfab25, commit=false]
[15:22:03,044][INFO][db-checkpoint-thread-#85][GridCacheDatabaseSharedManager]
Skipping
[jira] [Created] (IGNITE-10680) Add the ability to use started kernel context in standalone WAL iterator
Aleksey Plekhanov created IGNITE-10680:
--
Summary: Add the ability to use started kernel context in
standalone WAL iterator
Key: IGNITE-10680
URL: https://issues.apache.org/jira/browse/IGNITE-10680
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.8
In the current implementation it's only possible to use fake kernel context in
standalone WAL iterator. If we need to use binary meta from the running Ignite
node we must specify binary meta directory in parameters of standalone WAL
iterator factory. But there is a possible race with binary meta files
read/write since binary meta received with {{MetadataUpdateProposedMessage}}
can be written to the file and concurrently read from the same file at the same
time. This can lead to assertions like the following:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
{noformat}
To solve this we can use in standalone WAL iterator existing kernel context of
the started node instead of creating new fake one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10681) PME benchmarks become unstable at high number of partitions per cache.
Pavel Voronkin created IGNITE-10681:
---
Summary: PME benchmarks become unstable at high number of
partitions per cache.
Key: IGNITE-10681
URL: https://issues.apache.org/jira/browse/IGNITE-10681
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Voronkin
With increased number of partitions per cache (20-32k), some of the stages
happening during PME become very unstable both per node and per run. This must
be investigated because it blocks us from fine-tuning PME time optimizations
further.
Example: same configuration, same servers, same version (8.5.1-p150)
a run 2018-11-13:
{noformat}
Exchange [13,0] during LEAVE 1 server(s): 8942 msec, 8952 msec
New topology version after JOIN 1 server(s): 14
Exchange [14,0] during JOIN 1 server(s): 7558 msec, 8225 msec
Exchange [14,1] during JOIN 1 server(s): 19510 msec, 19562 msec
{noformat}
a run 2018-11-14:
{noformat}
Exchange [13, 0] during LEAVE 1 server(s): 14434 msec, 14448 msec
New topology version after JOIN 1 server(s): 14
Exchange [14, 1] during JOIN 1 server(s): 9089 msec, 9512 msec
Exchange [14, 0] during JOIN 1 server(s): 14455 msec, 14671 msec
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.
[ https://issues.apache.org/jira/browse/IGNITE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8245: Assignee: Ilya Borisov (was: Alexey Kuznetsov) [~Klaster_1] Could you take a look? Ask [~pkonstantinov] for details. > Web console: "Warning" icon is displayed above "secured key" icon. > -- > > Key: IGNITE-8245 > URL: https://issues.apache.org/jira/browse/IGNITE-8245 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.4 >Reporter: Andrey Novikov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > warning_icon.png > > > See attachment. Reproduced in Safari. > Make the actual input borderless, move the border to outer element, shrink > the input element when an error notification has to be shown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10245) o.a.i.internal.util.nio.ssl.GridNioSslFilter failed with Assertion if invalid SSL Cipher suite name specified
[ https://issues.apache.org/jira/browse/IGNITE-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10245: - Assignee: (was: Alexey Kuznetsov) > o.a.i.internal.util.nio.ssl.GridNioSslFilter failed with Assertion if invalid > SSL Cipher suite name specified > - > > Key: IGNITE-10245 > URL: https://issues.apache.org/jira/browse/IGNITE-10245 > Project: Ignite > Issue Type: Task >Reporter: Alexey Kuznetsov >Priority: Major > > This issue is related to IGNITE-10189. > In case of invalid cipher suite name GridNioSslFilter failed with assertion > in org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter#sslHandler method. > Need to investigate and fix. > > See test: ClientSslParametersTest.testNonExistentCipherSuite() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10245) o.a.i.internal.util.nio.ssl.GridNioSslFilter failed with Assertion if invalid SSL Cipher suite name specified
[ https://issues.apache.org/jira/browse/IGNITE-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10245: -- Fix Version/s: (was: 2.8) > o.a.i.internal.util.nio.ssl.GridNioSslFilter failed with Assertion if invalid > SSL Cipher suite name specified > - > > Key: IGNITE-10245 > URL: https://issues.apache.org/jira/browse/IGNITE-10245 > Project: Ignite > Issue Type: Task >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > This issue is related to IGNITE-10189. > In case of invalid cipher suite name GridNioSslFilter failed with assertion > in org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter#sslHandler method. > Need to investigate and fix. > > See test: ClientSslParametersTest.testNonExistentCipherSuite() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9213) CacheLockReleaseNodeLeaveTest.testLockTopologyChange hangs sometimes, leading to TC timeout
[
https://issues.apache.org/jira/browse/IGNITE-9213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov reassigned IGNITE-9213:
Assignee: Semen Boikov
> CacheLockReleaseNodeLeaveTest.testLockTopologyChange hangs sometimes, leading
> to TC timeout
> ---
>
> Key: IGNITE-9213
> URL: https://issues.apache.org/jira/browse/IGNITE-9213
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Semen Boikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: ignite-9213-threaddump.txt
>
>
> Probability is quite low, < 5%.
> One thread gets stuck in GridCacheAdapter.lockAll(...), holding gw readlock
> and waiting for future that never completes. Another one cannot acquire gw
> writelock.
> {code}
> "test-runner-#123405%distributed.CacheLockReleaseNodeLeaveTest%" #136172
> prio=5 os_prio=0 tid=0x7f20cd3d7000 nid=0x356f
> sleeping[0x7f1eae48b000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7678)
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.onStopped(GridCacheGateway.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.blockGateways(GridCacheProcessor.java:970)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2195)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2082)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0xc2e69580> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1153)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1196)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1174)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheLockReleaseNodeLeaveTest.testLockTopologyChange(CacheLockReleaseNodeLeaveTest.java:177)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2156)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2071)
> at java.lang.Thread.run(Thread.java:745)
> "test-lock-thread-4" #136488 prio=5 os_prio=0 tid=0x7f208802a000
> nid=0x36a5 waiting on condition [0x7f1ea81c3000]
>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.cache.GridCacheAdapter.lockAll(GridCacheAdapter.java:3405)
> at
> org.apache.ignite.internal.processors.cache.CacheLockImpl.lock(CacheLockImpl.java:74)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheLockReleaseNodeLeaveTest$3.run(CacheLockReleaseNodeLeaveTest.java:154)
> at
> org.apache.ignite.testframework.GridTestUtils$6.call(GridTestUtils.java:1254)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10678) Shell script unification
Sergey Kozlov created IGNITE-10678:
--
Summary: Shell script unification
Key: IGNITE-10678
URL: https://issues.apache.org/jira/browse/IGNITE-10678
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 3.0
Ignite distriburion package includes following scripts:
{noformat}
bin/control.sh
bin/ignite.sh
bin/ignite-rf.sh
bin/igniterouter.sh
bin/ignitevisorcmd.sh
bin/sqlline.sh
{noformat}
and same set with {{.bat}} extension
The scripts has own logic for java version detecting, set ignite home, class
path and so on. Also similar commands for different scripts designed
differently (like argument naming).
I suppose the scripts should be redesigned by following rules:
- the script code should contain one line - just call a proper java class and
pass all command-line arguments
- use common argument parser for all scripts
Optional:
- make interactive controls.sh
- deprecate ignitevisorcmd and move the commands into control.sh (also it will
allow to remove demo node mode)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10657) Thin clients (ODBC, JDBC, Java) should call ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible leaking of the memory
[
https://issues.apache.org/jira/browse/IGNITE-10657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720499#comment-16720499
]
Ignite TC Bot commented on IGNITE-10657:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2536720buildTypeId=IgniteTests24Java8_RunAll]
> Thin clients (ODBC, JDBC, Java) should call
> ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible
> leaking of the memory
> -
>
> Key: IGNITE-10657
> URL: https://issues.apache.org/jira/browse/IGNITE-10657
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Andrey Aleksandrov
>Assignee: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
>
> At the moment all classes that implement
> ClientListenerAbstractConnectionContext don't call the
> ctx.security().onSessionExpired(subjid) on disconect.
> It provides the leaking of the memory related to resources that were
> generated during authentification.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10176) migrate non-core modules tests from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720483#comment-16720483
]
Ignite TC Bot commented on IGNITE-10176:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2538419buildTypeId=IgniteTests24Java8_RunAll]
> migrate non-core modules tests from Junit 3 to 4
>
>
> Key: IGNITE-10176
> URL: https://issues.apache.org/jira/browse/IGNITE-10176
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> Migrate using new API introduced and tested at prior step.
> Also, make sure that there are no inappropriate annotations in methods that
> override {{beforeTest}} and {{afterTest}} as explained in more details [in
> comments
> below|https://issues.apache.org/jira/browse/IGNITE-10176?focusedCommentId=16718914=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16718914].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10670) investigate why Cassandra modules don't have testsuite(s)
[ https://issues.apache.org/jira/browse/IGNITE-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10670: --- Labels: MakeTeamcityGreenAgain (was: ) > investigate why Cassandra modules don't have testsuite(s) > - > > Key: IGNITE-10670 > URL: https://issues.apache.org/jira/browse/IGNITE-10670 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > Unlike most if not all other Ignite modules, > [cassandra|https://github.com/apache/ignite/tree/master/modules/cassandra] > currently doesn't have testsuites. > Find out why is that and if it is a matter of simple omission, add testsuites > and integrate them in Teamcity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10673) Prepare instructions for ASC and SHA512 verification
[ https://issues.apache.org/jira/browse/IGNITE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720465#comment-16720465 ] Peter Ivanov commented on IGNITE-10673: --- I hoped [~pgarg] will. Not sure I have enough permissions. > Prepare instructions for ASC and SHA512 verification > > > Key: IGNITE-10673 > URL: https://issues.apache.org/jira/browse/IGNITE-10673 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Prepare instructions for ASC and SHA512 verification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720448#comment-16720448 ] ASF GitHub Bot commented on IGNITE-9532: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4720 > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720439#comment-16720439
]
Ignite TC Bot commented on IGNITE-9532:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2539366buildTypeId=IgniteTests24Java8_RunAll]
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10673) Prepare instructions for ASC and SHA512 verification
[ https://issues.apache.org/jira/browse/IGNITE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720438#comment-16720438 ] Dmitriy Pavlov commented on IGNITE-10673: - Could you please place it to Apache Ignite wiki? > Prepare instructions for ASC and SHA512 verification > > > Key: IGNITE-10673 > URL: https://issues.apache.org/jira/browse/IGNITE-10673 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Prepare instructions for ASC and SHA512 verification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5003) Parallel write same key in CacheWriteBehindStore
[ https://issues.apache.org/jira/browse/IGNITE-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5003: --- Description: Now GridCacheWriteBehindStore.updateCache wait for writeLock in StatefulValue and, moreover, waitForFlush() if value is in pending (flushing) state. We need to remove waiting. was:Now GridCacheWriteBehindStore.updateCache wait for writeLock in StatefulValue and, moreover, waitForFlush() if value is in pending (flushing) state. We need to remove waiting. > Parallel write same key in CacheWriteBehindStore > -- > > Key: IGNITE-5003 > URL: https://issues.apache.org/jira/browse/IGNITE-5003 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.9 >Reporter: Alexander Belyak >Assignee: Andrey Aleksandrov >Priority: Major > > Now GridCacheWriteBehindStore.updateCache wait for writeLock in StatefulValue > and, moreover, waitForFlush() if value is in pending (flushing) state. > We need to remove waiting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10677) [TC Bot] Include build failure on metric & exit code into critical failures
[ https://issues.apache.org/jira/browse/IGNITE-10677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10677: Ignite Flags: (was: Docs Required) > [TC Bot] Include build failure on metric & exit code into critical failures > --- > > Key: IGNITE-10677 > URL: https://issues.apache.org/jira/browse/IGNITE-10677 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > It is necessary to setup dev.list notifications for _License_ failure > and for Inspections: Core failures notification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10677) [TC Bot] Include build failure on metric & exit code into critical failures
Dmitriy Pavlov created IGNITE-10677: --- Summary: [TC Bot] Include build failure on metric & exit code into critical failures Key: IGNITE-10677 URL: https://issues.apache.org/jira/browse/IGNITE-10677 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov It is necessary to setup dev.list notifications for _License_ failure and for Inspections: Core failures notification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8983) .NET long-running suite fails in master
[
https://issues.apache.org/jira/browse/IGNITE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8983:
---
Labels: MakeTeamcityGreenAgain (was: )
> .NET long-running suite fails in master
> ---
>
> Key: IGNITE-8983
> URL: https://issues.apache.org/jira/browse/IGNITE-8983
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.6
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> One of the following changes triggered the fails:
> {code}
> IGNITE-8681 Using ExpiryPolicy with persistence causes significant slowdown
> - Fixes #4285.
> IGNITE-7149 : Gradient boosting for decision tree
> IGNITE-8746 EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the
> coordinator IGNITE-8821 Reduced amount of logs for BPlusTreeSelfTest
> put/remove family tests - Fixes #4218.
> IGNITE-8203 Handle ClosedByInterruptionException in FilePageStore - Fixes
> #4211.
> IGNITE-8857 new IgnitePredicate filtering credential attribute
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720348#comment-16720348 ] ASF GitHub Bot commented on IGNITE-10671: - GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/5665 IGNITE-10671 Introduced state machine to handle lifecycle of start/ac… …tivate/stop. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10671 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5665.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 #5665 commit 467a0916286482ffa41362e5f88307695912048c Author: Pavel Voronkin Date: 2018-12-13T16:10:01Z IGNITE-10671 Introduced state machine to handle lifecycle of start/activate/stop. > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > > Race is painful when you switch your cluster from walCompaction=false to > walCompaction=true. > The same FileCompressor instance will use different segmentAwares due to > start0() is called twice which leads to inconsistent behaviour and errors > during compaction, basically we will try to archive files twice concurrently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10615) Ignite Compatibility: fix arguments' checking in the node runner
[
https://issues.apache.org/jira/browse/IGNITE-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720317#comment-16720317
]
ASF GitHub Bot commented on IGNITE-10615:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5618
> Ignite Compatibility: fix arguments' checking in the node runner
>
>
> Key: IGNITE-10615
> URL: https://issues.apache.org/jira/browse/IGNITE-10615
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Minor
> Fix For: 2.8
>
>
> There is the checking of arguments number In
> {{IgniteCompatibilityNodeRunner#main}}, which expected at least 3 arguments,
> but in actual code at least 5 arguments are required.
> The checking should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6205) Stability testing on CI server
[ https://issues.apache.org/jira/browse/IGNITE-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720305#comment-16720305 ] Dmitriy Pavlov commented on IGNITE-6205: [~vveider] For me, it seems it is not relevant. We still have an idea of adding multiple-trigger to TC Bot. But it is needed not so often. Contributors prepare their own PRs with for(int i;) > Stability testing on CI server > -- > > Key: IGNITE-6205 > URL: https://issues.apache.org/jira/browse/IGNITE-6205 > Project: Ignite > Issue Type: Task >Affects Versions: 2.1 >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > CI server shows many sporadic failures and the communty spend significant > efforts to fix them. > We should to avoid such cases by adding the task on teamcity where new or > modified tests wil run 100 times. Once it will be done the "100 times run" > can become the part/requirement of review procedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10675) Refactor Release Candidate check build
[ https://issues.apache.org/jira/browse/IGNITE-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720308#comment-16720308 ] Peter Ivanov commented on IGNITE-10675: --- [~avinogradov], that's why first part of issue is "revise", not "implement" or "introduce" :) > Refactor Release Candidate check build > -- > > Key: IGNITE-10675 > URL: https://issues.apache.org/jira/browse/IGNITE-10675 > Project: Ignite > Issue Type: Sub-task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > # Revise build, ASC, SHA512, etc. steps. > # Add check for tasks in Jira: all tasks for current RC should be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10676) Binary: optionally do not check types in metadata
Vladimir Ozerov created IGNITE-10676: Summary: Binary: optionally do not check types in metadata Key: IGNITE-10676 URL: https://issues.apache.org/jira/browse/IGNITE-10676 Project: Ignite Issue Type: Task Components: binary Reporter: Vladimir Ozerov Consider a situation when user want to re-create a table with different type for some columns. Currently it is not possible due to strict metadata checks. To fix this we may optionally skip metadata checks for certain data types. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720300#comment-16720300
]
Vladimir Ozerov commented on IGNITE-10643:
--
Returned "_KEY" to pruning logic. Fixed several other issues.
Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=2540436
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10643:
-
Comment: was deleted
(was: https://ci.ignite.apache.org/viewQueued.html?itemId=2539046)
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[ https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720286#comment-16720286 ] Pavel Kuznetsov commented on IGNITE-10645: -- Fixed one more configuration: https://ci.ignite.apache.org/viewQueued.html?itemId=2540136 > SQL properties ownership flag should be set at configuration parsing, not > query execution. > -- > > Key: IGNITE-10645 > URL: https://issues.apache.org/jira/browse/IGNITE-10645 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > At processing time, query entities are transformed and validated, table > descriptors with properties are created. > Now in some case (thre's no keyFields and key is of complex non-sql type), > ownership flag of query property is calculated at execution time (for example > at first put()): > https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132 > So we can't access metadata, that uses this not-yet-initialized field before > we put the data. > But we already have all necessary info to set this field at processing time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6727) Ignite assembly should not require ignite-tools installation
[ https://issues.apache.org/jira/browse/IGNITE-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-6727: Assignee: Peter Ivanov (was: Oleg Ostanin) > Ignite assembly should not require ignite-tools installation > > > Key: IGNITE-6727 > URL: https://issues.apache.org/jira/browse/IGNITE-6727 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.8 > > > Need to research how to solve this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5003) Parallel write same key in CacheWriteBehindStore
[ https://issues.apache.org/jira/browse/IGNITE-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720285#comment-16720285 ] ASF GitHub Bot commented on IGNITE-5003: GitHub user aealeksandrov opened a pull request: https://github.com/apache/ignite/pull/5664 IGNITE-5003: Hanging of parallel write for the same key in Cach… …eWriteBehindStore fixed. Now GridCacheWriteBehindStore.updateCache wait for writeLock in StatefulValue and, moreover, waitForFlush() if value is in pending (flushing) state. We need to remove waiting. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5003 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5664.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 #5664 commit 759fbb5e271d86583087b897e3659d86bd41a125 Author: Andrei Aleksandrov Date: 2018-12-13T15:16:17Z IGNITE-5003: Hanging of parallel write for the same key in CacheWriteBehindStore fixed. > Parallel write same key in CacheWriteBehindStore > -- > > Key: IGNITE-5003 > URL: https://issues.apache.org/jira/browse/IGNITE-5003 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.9 >Reporter: Alexander Belyak >Assignee: Andrey Aleksandrov >Priority: Major > > Now GridCacheWriteBehindStore.updateCache wait for writeLock in StatefulValue > and, moreover, waitForFlush() if value is in pending (flushing) state. We > need to remove waiting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10675) Refactor Release Candidate check build
[ https://issues.apache.org/jira/browse/IGNITE-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720281#comment-16720281 ] Anton Vinogradov commented on IGNITE-10675: --- [~vveider] step 1 already implemented see https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum > Refactor Release Candidate check build > -- > > Key: IGNITE-10675 > URL: https://issues.apache.org/jira/browse/IGNITE-10675 > Project: Ignite > Issue Type: Sub-task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > # Revise build, ASC, SHA512, etc. steps. > # Add check for tasks in Jira: all tasks for current RC should be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5604) Activate fails in case node was stopped with cancel=true and big objects in cache
[
https://issues.apache.org/jira/browse/IGNITE-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720272#comment-16720272
]
ASF GitHub Bot commented on IGNITE-5604:
Github user tledkov-gridgain closed the pull request at:
https://github.com/apache/ignite/pull/2211
> Activate fails in case node was stopped with cancel=true and big objects in
> cache
> -
>
> Key: IGNITE-5604
> URL: https://issues.apache.org/jira/browse/IGNITE-5604
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.1
>
>
> Please take a look at the test
> {{IgniteWalRecoveryTest#testWalBigObjectNodeCancel}}.
> The test is available at the [pull
> request|https://github.com/apache/ignite/pull/2211].
> The error is:
> {code}
> [2017-06-28 15:50:46,020][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Fail activate
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
> at
> org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3408)
> at
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest.testWalBigObjectNodeCancel(IgniteWalRecoveryTest.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1995)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1910)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Fail activate
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> restore memory state (checkpoint marker is present on disk, but checkpoint
> record is missed in WAL) [cpStatus=CheckpointStatus [cpStartTs=1498654243491,
> cpStartId=7f873e0b-b1ee-4bd6-8605-b139b82898c9, startPtr=FileWALPointer
> [idx=0, fileOffset=8657376, len=2425, forceFlush=false],
> cpEndId=----, endPtr=FileWALPointer [idx=0,
> fileOffset=0, len=0, forceFlush=false]], lastRead=FileWALPointer [idx=0,
> fileOffset=4340447, len=39, forceFlush=false]]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1471)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.initCachesAndRestoreMemory(GridCacheDatabaseSharedManager.java:492)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.onActivate(GridCacheDatabaseSharedManager.java:508)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onActivate(GridClusterStateProcessor.java:747)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onChangeGlobalState(GridClusterStateProcessor.java:655)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:719)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:563)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1872)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5003) Parallel write same key in CacheWriteBehindStore
[ https://issues.apache.org/jira/browse/IGNITE-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov reassigned IGNITE-5003: -- Assignee: Andrey Aleksandrov > Parallel write same key in CacheWriteBehindStore > -- > > Key: IGNITE-5003 > URL: https://issues.apache.org/jira/browse/IGNITE-5003 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.9 >Reporter: Alexander Belyak >Assignee: Andrey Aleksandrov >Priority: Major > > Now GridCacheWriteBehindStore.updateCache wait for writeLock in StatefulValue > and, moreover, waitForFlush() if value is in pending (flushing) state. We > need to remove waiting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5833) Change maven goal from "install" to "package" for building from sour
[ https://issues.apache.org/jira/browse/IGNITE-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-5833: Assignee: Peter Ivanov (was: Oleg Ostanin) > Change maven goal from "install" to "package" for building from sour > > > Key: IGNITE-5833 > URL: https://issues.apache.org/jira/browse/IGNITE-5833 > Project: Ignite > Issue Type: Bug >Reporter: Oleg Ostanin >Assignee: Peter Ivanov >Priority: Major > > Currently we need to run 'mvn clean install' to build Apache Ignite from > sources, otherwise we can not perform javadoc generation in the next build > step in DEVNOTES.txt. We need to fix this issue before next release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8227) Research possibility and implement JUnit test failure handler for TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720203#comment-16720203 ] ASF GitHub Bot commented on IGNITE-8227: GitHub user SomeFire opened a pull request: https://github.com/apache/ignite/pull/5662 IGNITE-8227 Research possibility and implement JUnit test failure handler for TeamCity You can merge this pull request into a Git repository by running: $ git pull https://github.com/SomeFire/ignite IGNITE-8227 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5662.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 #5662 commit 94e51509128141c899b995f3b72a0cd9933c7872 Author: Dmitrii Ryabov Date: 2018-12-13T14:02:21Z test > Research possibility and implement JUnit test failure handler for TeamCity > -- > > Key: IGNITE-8227 > URL: https://issues.apache.org/jira/browse/IGNITE-8227 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Ryabov Dmitrii >Priority: Major > > After IEP-14 > (https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling) > we found a lot of TC failures involving unexpected nodes stop. > To avoid suites exit codes, tests have NoOpFailureHandler as default. > But instead of this, better handler could be > stopNode + fail currenly running test with message. > This default allows to identify such failures without log-message fail > condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6766) RC check automation
[ https://issues.apache.org/jira/browse/IGNITE-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-6766. > RC check automation > --- > > Key: IGNITE-6766 > URL: https://issues.apache.org/jira/browse/IGNITE-6766 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Peter Ivanov >Priority: Major > Labels: teamcity > > Need to add task which downloads RC from > https://dist.apache.org/repos/dist/dev/ignite/X.Y.Z-rcK > and checks that sha1, md5, gpg, src(license, build)) are ok. > Also it should check that all Jira issues are resolved or closed for this > version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6766) RC check automation
[ https://issues.apache.org/jira/browse/IGNITE-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-6766. -- Resolution: Invalid Fix Version/s: (was: 2.8) RC check automation task is partially ready, final steps will be done in IGNITE-10675 > RC check automation > --- > > Key: IGNITE-6766 > URL: https://issues.apache.org/jira/browse/IGNITE-6766 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Peter Ivanov >Priority: Major > Labels: teamcity > > Need to add task which downloads RC from > https://dist.apache.org/repos/dist/dev/ignite/X.Y.Z-rcK > and checks that sha1, md5, gpg, src(license, build)) are ok. > Also it should check that all Jira issues are resolved or closed for this > version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10053) IgniteAbstractBenchmark: NPE in waitForNodes
[
https://issues.apache.org/jira/browse/IGNITE-10053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720263#comment-16720263
]
ASF GitHub Bot commented on IGNITE-10053:
-
Github user pavel-kuznetsov closed the pull request at:
https://github.com/apache/ignite/pull/5205
> IgniteAbstractBenchmark: NPE in waitForNodes
>
>
> Key: IGNITE-10053
> URL: https://issues.apache.org/jira/browse/IGNITE-10053
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> <14:58:02> Failed to set up benchmark drivers (will shutdown
> and exit).
> java.lang.NullPointerException
> <-->at
> org.apache.ignite.yardstick.IgniteAbstractBenchmark.topologyContainsId(IgniteAbstractBenchmark.java:182)
> <-->at
> org.apache.ignite.yardstick.IgniteAbstractBenchmark.nodesStarted(IgniteAbstractBenchmark.java:169)
> <-->at
> org.apache.ignite.yardstick.IgniteAbstractBenchmark.waitForNodes(IgniteAbstractBenchmark.java:144)
> <-->at
> org.apache.ignite.yardstick.IgniteAbstractBenchmark.setUp(IgniteAbstractBenchmark.java:68)
> <-->at
> org.apache.ignite.yardstick.cache.IgniteCacheAbstractBenchmark.setUp(IgniteCacheAbstractBenchmark.java:108)
> <-->at
> org.yardstickframework.BenchmarkDriverStartUp.main(BenchmarkDriverStartUp.java:130
> {noformat}
> 1) Given 4 server nodes in the cluster
> 2) Cluster gets activated
> 3) client nodes join topology and start waiting for nodes
> 4) on one node NPE is thrown
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10675) Refactor Release Candidate check build
Peter Ivanov created IGNITE-10675: - Summary: Refactor Release Candidate check build Key: IGNITE-10675 URL: https://issues.apache.org/jira/browse/IGNITE-10675 Project: Ignite Issue Type: Sub-task Reporter: Peter Ivanov Assignee: Peter Ivanov # Revise build, ASC, SHA512, etc. steps. # Add check for tasks in Jira: all tasks for current RC should be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6766) RC check automation
[ https://issues.apache.org/jira/browse/IGNITE-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-6766: Assignee: Peter Ivanov (was: Oleg Ostanin) > RC check automation > --- > > Key: IGNITE-6766 > URL: https://issues.apache.org/jira/browse/IGNITE-6766 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Peter Ivanov >Priority: Major > Labels: teamcity > Fix For: 2.8 > > > Need to add task which downloads RC from > https://dist.apache.org/repos/dist/dev/ignite/X.Y.Z-rcK > and checks that sha1, md5, gpg, src(license, build)) are ok. > Also it should check that all Jira issues are resolved or closed for this > version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6205) Stability testing on CI server
[ https://issues.apache.org/jira/browse/IGNITE-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720254#comment-16720254 ] Peter Ivanov commented on IGNITE-6205: -- [~skozlov], [~dpavlov] -- is issue still relevant? > Stability testing on CI server > -- > > Key: IGNITE-6205 > URL: https://issues.apache.org/jira/browse/IGNITE-6205 > Project: Ignite > Issue Type: Task >Affects Versions: 2.1 >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > CI server shows many sporadic failures and the communty spend significant > efforts to fix them. > We should to avoid such cases by adding the task on teamcity where new or > modified tests wil run 100 times. Once it will be done the "100 times run" > can become the part/requirement of review procedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6763) Release process automation
[ https://issues.apache.org/jira/browse/IGNITE-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-6763. > Release process automation > -- > > Key: IGNITE-6763 > URL: https://issues.apache.org/jira/browse/IGNITE-6763 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: teamcity > Fix For: 2.5 > > > See devlist for details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6205) Stability testing on CI server
[ https://issues.apache.org/jira/browse/IGNITE-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-6205: Assignee: Peter Ivanov (was: Oleg Ostanin) > Stability testing on CI server > -- > > Key: IGNITE-6205 > URL: https://issues.apache.org/jira/browse/IGNITE-6205 > Project: Ignite > Issue Type: Task >Affects Versions: 2.1 >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > CI server shows many sporadic failures and the communty spend significant > efforts to fix them. > We should to avoid such cases by adding the task on teamcity where new or > modified tests wil run 100 times. Once it will be done the "100 times run" > can become the part/requirement of review procedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720252#comment-16720252
]
ASF GitHub Bot commented on IGNITE-10514:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5558
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> transactionalCache.put(...);
> atomicCache.put(...);
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
> related to {{NODE_JOIN}} event,
> on the other hand, the corresponding request
> {{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
> using the next topology version, triggered by {{CacheAffinityMessage}}.
> {code:java|title=GridDhtAtomicCache.java}
> private void updateAllAsyncInternal0() {
> ...
> if (validateCache) {
> GridDhtTopologyFuture topFut = top.topologyVersionFuture();
> // There is a chance that the topFut is not done yet!
> assert topFut.isDone() : topFut;
> Throwable err = topFut.validateCache(ctx, req.recovery(), false,
> null, null);
> ...
> }
> }{code}
> That is the root cause of the {{AssertionError}} mentioned above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6237) Script for signing and uploading artifacts to remote staging.
[ https://issues.apache.org/jira/browse/IGNITE-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-6237. -- Resolution: Fixed Assignee: Peter Ivanov (was: Oleg Ostanin) Fix Version/s: (was: 2.8) The issue is already resolved, moreover -- release scripts are moved to separate repository ignite-release. > Script for signing and uploading artifacts to remote staging. > - > > Key: IGNITE-6237 > URL: https://issues.apache.org/jira/browse/IGNITE-6237 > Project: Ignite > Issue Type: Sub-task > Components: build >Reporter: Oleg Ostanin >Assignee: Peter Ivanov >Priority: Major > > Create script for signing artifacts in locally staged repository and > uploading to the remote staging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5249) The release build procedure
[ https://issues.apache.org/jira/browse/IGNITE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-5249. -- Resolution: Invalid There is already release build for Apache Ignite that will be refactored in 2.8. > The release build procedure > --- > > Key: IGNITE-5249 > URL: https://issues.apache.org/jira/browse/IGNITE-5249 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > The release build procedure should be placed on the CI/CD server and > available to run for the release engineer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5249) The release build procedure
[ https://issues.apache.org/jira/browse/IGNITE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-5249. > The release build procedure > --- > > Key: IGNITE-5249 > URL: https://issues.apache.org/jira/browse/IGNITE-5249 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > The release build procedure should be placed on the CI/CD server and > available to run for the release engineer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5249) The release build procedure
[ https://issues.apache.org/jira/browse/IGNITE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-5249: Assignee: Peter Ivanov (was: Oleg Ostanin) > The release build procedure > --- > > Key: IGNITE-5249 > URL: https://issues.apache.org/jira/browse/IGNITE-5249 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > The release build procedure should be placed on the CI/CD server and > available to run for the release engineer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6237) Script for signing and uploading artifacts to remote staging.
[ https://issues.apache.org/jira/browse/IGNITE-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-6237. > Script for signing and uploading artifacts to remote staging. > - > > Key: IGNITE-6237 > URL: https://issues.apache.org/jira/browse/IGNITE-6237 > Project: Ignite > Issue Type: Sub-task > Components: build >Reporter: Oleg Ostanin >Assignee: Peter Ivanov >Priority: Major > > Create script for signing artifacts in locally staged repository and > uploading to the remote staging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9893) add hibernate-5.3 module
[ https://issues.apache.org/jira/browse/IGNITE-9893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720236#comment-16720236 ] Ilya Kasnacheev edited comment on IGNITE-9893 at 12/13/18 2:37 PM: --- Hello [~scottmf]. Thank you for the huge amount of work that you have performed! There are several things I will ask you to do so that we can merge this new module: - Please rename Ignite*Hibernate5TestSuite to e.g. Ignite*Hibernate53TestSuite in the new module. This is required so that we can easily differentiate between them on our Teamcity. - Please rebase your commit on top of master branch, and fix compilation errors (DFLT_CACHE_NAME_PROPERTY is unavailable, which is used by hibernate-4.2 module). - Please avoid reformatting code that you edit. We have extensive coding guidelines: https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines - in short, please avoid removing blank lines between everything, please avoid putting curly braces around single statements, please keep single level of indentation, even for method parameters. Note that I can try to do that for you. After that is done we'll do a TC run, I'll fix the remaining minor issues if there are any, and merge to master. was (Author: ilyak): Hello [~scottmf]. Thank you for the huge amount of work that you have performed! There are several things I will ask you to do so that we can merge this new module: - Please rename Ignite*Hibernate5TestSuite to e.g. Ignite*Hibernate53TestSuite. This is required so that we can easily differentiate between them on our Teamcity. - Please rebase your commit on top of master branch, and fix compilation errors (DFLT_CACHE_NAME_PROPERTY is unavailable, which is used by hibernate-4.2 module). - Please avoid reformatting code that you edit. We have extensive coding guidelines: https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines - in short, please avoid removing blank lines between everything, please avoid putting curly braces around single statements, please keep single level of indentation, even for method parameters. Note that I can try to do that for you. After that is done we'll do a TC run, I'll fix the remaining minor issues if there are any, and merge to master. > add hibernate-5.3 module > > > Key: IGNITE-9893 > URL: https://issues.apache.org/jira/browse/IGNITE-9893 > Project: Ignite > Issue Type: New Feature > Components: hibernate >Reporter: Scott Feldstein >Assignee: Scott Feldstein >Priority: Major > > hi, > I have ported hibernate-5.2 to ignite 2.7.0-SNAPSHOT HEAD. > commit: > [https://github.com/scottmf/ignite/commit/4f2caafb8c433e3f840d14f91c2d83da1052afd9] > All tests pass except > CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which is carryover > from the hibernate-5.1 implementation. There is a bug already associated with > the failure: > https://issues.apache.org/jira/browse/IGNITE-1757 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9893) add hibernate-5.3 module
[ https://issues.apache.org/jira/browse/IGNITE-9893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720236#comment-16720236 ] Ilya Kasnacheev commented on IGNITE-9893: - Hello [~scottmf]. Thank you for the huge amount of work that you have performed! There are several things I will ask you to do so that we can merge this new module: - Please rename Ignite*Hibernate5TestSuite to e.g. Ignite*Hibernate53TestSuite. This is required so that we can easily differentiate between them on our Teamcity. - Please rebase your commit on top of master branch, and fix compilation errors (DFLT_CACHE_NAME_PROPERTY is unavailable, which is used by hibernate-4.2 module). - Please avoid reformatting code that you edit. We have extensive coding guidelines: https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines - in short, please avoid removing blank lines between everything, please avoid putting curly braces around single statements, please keep single level of indentation, even for method parameters. Note that I can try to do that for you. After that is done we'll do a TC run, I'll fix the remaining minor issues if there are any, and merge to master. > add hibernate-5.3 module > > > Key: IGNITE-9893 > URL: https://issues.apache.org/jira/browse/IGNITE-9893 > Project: Ignite > Issue Type: New Feature > Components: hibernate >Reporter: Scott Feldstein >Assignee: Scott Feldstein >Priority: Major > > hi, > I have ported hibernate-5.2 to ignite 2.7.0-SNAPSHOT HEAD. > commit: > [https://github.com/scottmf/ignite/commit/4f2caafb8c433e3f840d14f91c2d83da1052afd9] > All tests pass except > CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which is carryover > from the hibernate-5.1 implementation. There is a bug already associated with > the failure: > https://issues.apache.org/jira/browse/IGNITE-1757 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10621) Track all running queries on initial query node
[ https://issues.apache.org/jira/browse/IGNITE-10621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-10621: --- Summary: Track all running queries on initial query node (was: Track all running queries) > Track all running queries on initial query node > --- > > Key: IGNITE-10621 > URL: https://issues.apache.org/jira/browse/IGNITE-10621 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > As of now Ignite track running queries in few places and use > GridRunningQueryInfo to keep information about each of running query. > Unfortunately we track not all running queries. Need to track all DML and > Select queries. Be able to distinguish user initial queries and system > auxiliary queries, e.g. map/reduce queries or select for DML operations. Also > there is single point to track all running queries. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10257) Control.sh utility should request a SSL keystore password and SSL truststore password if necessary
[ https://issues.apache.org/jira/browse/IGNITE-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720228#comment-16720228 ] Vladislav Pyatkov commented on IGNITE-10257: Look good to me. > Control.sh utility should request a SSL keystore password and SSL truststore > password if necessary > -- > > Key: IGNITE-10257 > URL: https://issues.apache.org/jira/browse/IGNITE-10257 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > Using passwords (–ssl_key_strore_password and --ssl_trust_store_password) in > command line parametrs is not safe. We must request them if necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10621) Track all running queries on initial query node
[ https://issues.apache.org/jira/browse/IGNITE-10621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720224#comment-16720224 ] ASF GitHub Bot commented on IGNITE-10621: - GitHub user ygerzhedovich opened a pull request: https://github.com/apache/ignite/pull/5663 IGNITE-10621 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10621-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5663.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 #5663 commit 86c6c4845854ec67e348ed1334cd0140a7629ff4 Author: Yury Gerzhedovich Date: 2018-12-13T14:29:49Z IGNITE-10621: Track all running queries on initial query node commit 5e35144e6f6bad326709767d9e8fc519a73ec75d Author: Yury Gerzhedovich Date: 2018-12-13T14:30:34Z Merge branch 'master' into ignite-10621-1 > Track all running queries on initial query node > --- > > Key: IGNITE-10621 > URL: https://issues.apache.org/jira/browse/IGNITE-10621 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > As of now Ignite track running queries in few places and use > GridRunningQueryInfo to keep information about each of running query. > Unfortunately we track not all running queries. Need to track all DML and > Select queries. It should be single point to track all running queries. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10621) Track all running queries on initial query node
[ https://issues.apache.org/jira/browse/IGNITE-10621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-10621: --- Description: As of now Ignite track running queries in few places and use GridRunningQueryInfo to keep information about each of running query. Unfortunately we track not all running queries. Need to track all DML and Select queries. It should be single point to track all running queries. was: As of now Ignite track running queries in few places and use GridRunningQueryInfo to keep information about each of running query. Unfortunately we track not all running queries. Need to track all DML and Select queries. Be able to distinguish user initial queries and system auxiliary queries, e.g. map/reduce queries or select for DML operations. Also there is single point to track all running queries. > Track all running queries on initial query node > --- > > Key: IGNITE-10621 > URL: https://issues.apache.org/jira/browse/IGNITE-10621 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > As of now Ignite track running queries in few places and use > GridRunningQueryInfo to keep information about each of running query. > Unfortunately we track not all running queries. Need to track all DML and > Select queries. It should be single point to track all running queries. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10667) Web console: 'key store file' field is uneditable in SSL configuration
[ https://issues.apache.org/jira/browse/IGNITE-10667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10667: - Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good to me. Merged to master. > Web console: 'key store file' field is uneditable in SSL configuration > -- > > Key: IGNITE-10667 > URL: https://issues.apache.org/jira/browse/IGNITE-10667 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: image-2018-12-13-13-23-15-844.png > > > !image-2018-12-13-13-23-15-844.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10667) Web console: 'key store file' field is uneditable in SSL configuration
[ https://issues.apache.org/jira/browse/IGNITE-10667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10667: -- Component/s: wizards > Web console: 'key store file' field is uneditable in SSL configuration > -- > > Key: IGNITE-10667 > URL: https://issues.apache.org/jira/browse/IGNITE-10667 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Attachments: image-2018-12-13-13-23-15-844.png > > > !image-2018-12-13-13-23-15-844.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10667) Web console: 'key store file' field is uneditable in SSL configuration
[ https://issues.apache.org/jira/browse/IGNITE-10667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10667: -- Fix Version/s: 2.8 > Web console: 'key store file' field is uneditable in SSL configuration > -- > > Key: IGNITE-10667 > URL: https://issues.apache.org/jira/browse/IGNITE-10667 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Attachments: image-2018-12-13-13-23-15-844.png > > > !image-2018-12-13-13-23-15-844.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10674) Remove MARSH_CLASS_NAME=BinaryMarshaller from tests
Ilya Kasnacheev created IGNITE-10674: Summary: Remove MARSH_CLASS_NAME=BinaryMarshaller from tests Key: IGNITE-10674 URL: https://issues.apache.org/jira/browse/IGNITE-10674 Project: Ignite Issue Type: Test Affects Versions: 2.7 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev We have quite a few tests which set MARSH_CLASS_NAME to BinaryMarshaller. It is pointless because BinaryMarshaller seems to be default. Hibernate suites even have "Binary" suites which are never ran and which sole difference is that they set this property. We should probably remove such code from tests and tests/suites which are not needed anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10673) Prepare instructions for ASC and SHA512 verification
[ https://issues.apache.org/jira/browse/IGNITE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-10673. --- Resolution: Done http://apache-ignite-developers.2346864.n4.nabble.com/Re-Fwd-Returned-post-for-announce-apache-org-tp39334p39465.html > Prepare instructions for ASC and SHA512 verification > > > Key: IGNITE-10673 > URL: https://issues.apache.org/jira/browse/IGNITE-10673 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Prepare instructions for ASC and SHA512 verification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10673) Prepare instructions for ASC and SHA512 verification
[ https://issues.apache.org/jira/browse/IGNITE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-10673. - > Prepare instructions for ASC and SHA512 verification > > > Key: IGNITE-10673 > URL: https://issues.apache.org/jira/browse/IGNITE-10673 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Prepare instructions for ASC and SHA512 verification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10673) Prepare instructions for ASC and SHA512 verification
[ https://issues.apache.org/jira/browse/IGNITE-10673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-10673: -- Issue Type: Task (was: Improvement) > Prepare instructions for ASC and SHA512 verification > > > Key: IGNITE-10673 > URL: https://issues.apache.org/jira/browse/IGNITE-10673 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Prepare instructions for ASC and SHA512 verification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10528) [ML] Fix incorrect comparing of double values in ML examples
[ https://issues.apache.org/jira/browse/IGNITE-10528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720194#comment-16720194 ] ASF GitHub Bot commented on IGNITE-10528: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5655 > [ML] Fix incorrect comparing of double values in ML examples > > > Key: IGNITE-10528 > URL: https://issues.apache.org/jira/browse/IGNITE-10528 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Look at code row > if (groundTruth != prediction) > in each example > Fix with Math.abs or Double.compare method (don't forget precision) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-10671: - Assignee: Pavel Voronkin > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > > Race is painful when you switch your cluster from walCompaction=false to > walCompaction=true. > The same FileCompressor instance will use different segmentAwares due to > start0() is called twice which leads to inconsistent behaviour and errors > during compaction, basically we will try to archive files twice concurrently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10673) Prepare instructions for ASC and SHA512 verification
Peter Ivanov created IGNITE-10673: - Summary: Prepare instructions for ASC and SHA512 verification Key: IGNITE-10673 URL: https://issues.apache.org/jira/browse/IGNITE-10673 Project: Ignite Issue Type: Improvement Reporter: Peter Ivanov Assignee: Peter Ivanov Prepare instructions for ASC and SHA512 verification -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10588) Fail to clean internal structure in the test on Zookeeper Discovery Spi
[
https://issues.apache.org/jira/browse/IGNITE-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Fedotov updated IGNITE-10588:
--
Description:
In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk[1] and
ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients[2]
sometimes fails check on clean internal structure [3]. It seems that it is too
small timeout on waiting for condition.
{code}
junit.framework.AssertionFailedError: Expected: but was:
ZkCommunicationErrorProcessFuture
[impl=org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl@61e86192,
endTime=1544622093736, id=ed20d92a761-4bcce1f9-712a-4c88-a52f-1bafdea00019,
state=DONE, resolveTopVer=0, resErr=class
org.apache.ignite.IgniteCheckedException: Node stopped., collectResFut=null]
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.checkInternalStructuresCleanup(ZookeeperDiscoverySpiTest.java:545)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.afterTest(ZookeeperDiscoverySpiTest.java:504)
{code}
[1]https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4243396221762709202=testDetails
[2]https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-158901212115483601=testDetails\
[3]
https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L539
was:
In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk and
ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients
sometimes fails check on clean internal structure [1]. It seems that it is too
small timeout on waiting for condition.
[1]
https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L539
> Fail to clean internal structure in the test on Zookeeper Discovery Spi
> ---
>
> Key: IGNITE-10588
> URL: https://issues.apache.org/jira/browse/IGNITE-10588
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
>
> In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk[1] and
> ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients[2]
> sometimes fails check on clean internal structure [3]. It seems that it is
> too small timeout on waiting for condition.
> {code}
> junit.framework.AssertionFailedError: Expected: but was:
> ZkCommunicationErrorProcessFuture
> [impl=org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl@61e86192,
> endTime=1544622093736, id=ed20d92a761-4bcce1f9-712a-4c88-a52f-1bafdea00019,
> state=DONE, resolveTopVer=0, resErr=class
> org.apache.ignite.IgniteCheckedException: Node stopped., collectResFut=null]
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.checkInternalStructuresCleanup(ZookeeperDiscoverySpiTest.java:545)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.afterTest(ZookeeperDiscoverySpiTest.java:504)
> {code}
> [1]https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4243396221762709202=testDetails
> [2]https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-158901212115483601=testDetails\
> [3]
> https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L539
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720187#comment-16720187 ] Dmitriy Pavlov commented on IGNITE-9532: Retriggered: https://ci.ignite.apache.org/viewQueued.html?itemId=2539366 Comment should appear here later > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9211) Remove IgniteExamplesJ8SelfTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720185#comment-16720185
]
ASF GitHub Bot commented on IGNITE-9211:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5603
> Remove IgniteExamplesJ8SelfTestSuite
>
>
> Key: IGNITE-9211
> URL: https://issues.apache.org/jira/browse/IGNITE-9211
> Project: Ignite
> Issue Type: Sub-task
> Components: examples
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> //suite.addTest(new TestSuite(ContinuationExamplesSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesSelfTest.class));
> //suite.addTest(new TestSuite(DeploymentExamplesSelfTest.class));
> //suite.addTest(new TestSuite(LifecycleExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MemcacheRestExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MonteCarloExamplesSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesSelfTest.class));
> //suite.addTest(new TestSuite(SpringBeanExamplesSelfTest.class));
> //suite.addTest(new TestSuite(IgfsExamplesSelfTest.class));
> //suite.addTest(new TestSuite(CheckpointExamplesSelfTest.class));
> //suite.addTest(new TestSuite(HibernateL2CacheExampleSelfTest.class));
> //suite.addTest(new TestSuite(ClusterGroupExampleSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuationExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(DeploymentExamplesMultiNodeSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MemcacheRestExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MonteCarloExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(HibernateL2CacheExampleMultiNodeSelfTest.class));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9211) Remove IgniteExamplesJ8SelfTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9211:
---
Summary: Remove IgniteExamplesJ8SelfTestSuite (was: Uncomment 19 test
classes in IgniteExamplesJ8SelfTestSuite)
> Remove IgniteExamplesJ8SelfTestSuite
>
>
> Key: IGNITE-9211
> URL: https://issues.apache.org/jira/browse/IGNITE-9211
> Project: Ignite
> Issue Type: Sub-task
> Components: examples
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> //suite.addTest(new TestSuite(ContinuationExamplesSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesSelfTest.class));
> //suite.addTest(new TestSuite(DeploymentExamplesSelfTest.class));
> //suite.addTest(new TestSuite(LifecycleExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MemcacheRestExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MonteCarloExamplesSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesSelfTest.class));
> //suite.addTest(new TestSuite(SpringBeanExamplesSelfTest.class));
> //suite.addTest(new TestSuite(IgfsExamplesSelfTest.class));
> //suite.addTest(new TestSuite(CheckpointExamplesSelfTest.class));
> //suite.addTest(new TestSuite(HibernateL2CacheExampleSelfTest.class));
> //suite.addTest(new TestSuite(ClusterGroupExampleSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuationExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(DeploymentExamplesMultiNodeSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MemcacheRestExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MonteCarloExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(HibernateL2CacheExampleMultiNodeSelfTest.class));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9211) Uncomment 19 test classes in IgniteExamplesJ8SelfTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9211:
---
Fix Version/s: 2.8
> Uncomment 19 test classes in IgniteExamplesJ8SelfTestSuite
> --
>
> Key: IGNITE-9211
> URL: https://issues.apache.org/jira/browse/IGNITE-9211
> Project: Ignite
> Issue Type: Sub-task
> Components: examples
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> //suite.addTest(new TestSuite(ContinuationExamplesSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesSelfTest.class));
> //suite.addTest(new TestSuite(DeploymentExamplesSelfTest.class));
> //suite.addTest(new TestSuite(LifecycleExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MemcacheRestExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MonteCarloExamplesSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesSelfTest.class));
> //suite.addTest(new TestSuite(SpringBeanExamplesSelfTest.class));
> //suite.addTest(new TestSuite(IgfsExamplesSelfTest.class));
> //suite.addTest(new TestSuite(CheckpointExamplesSelfTest.class));
> //suite.addTest(new TestSuite(HibernateL2CacheExampleSelfTest.class));
> //suite.addTest(new TestSuite(ClusterGroupExampleSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuationExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(DeploymentExamplesMultiNodeSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MemcacheRestExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MonteCarloExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(HibernateL2CacheExampleMultiNodeSelfTest.class));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720168#comment-16720168
]
Amelchev Nikita commented on IGNITE-4380:
-
[~agoncharuk] Hi.
The failure scenario is that cached value can be read on starting remote tx in
case of entry hasn't value and read through configured (when dht prepare
message processed). It's fixed by setting the write flag to txEntry. It'll lead
to including its to dht prepare message. When txHandler will process message it
will not read the cached value on starting remote tx.
For a local cache, the prepare step does not wait for the key's prepare futures
to complete. Multiple threads can process a single value and write it. It's
solved by waiting for prepare future during the prepare step.
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9211) Uncomment 19 test classes in IgniteExamplesJ8SelfTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720174#comment-16720174
]
Ignite TC Bot commented on IGNITE-9211:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hibernate 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2488804]]
* HibernateL2CacheTransactionalUseSyncSelfTest.testRegionClear (last started)
{color:#d04437}Hibernate 1{color} [[tests
10|https://ci.ignite.apache.org/viewLog.html?buildId=2488803]]
* IgniteHibernateTestSuite:
HibernateL2CacheTransactionalUseSyncSelfTest.testQueryCache - 0,0% fails in
last 344 master runs.
* IgniteHibernateTestSuite:
HibernateL2CacheTransactionalUseSyncSelfTest.testTwoEntitiesSameCache - 0,0%
fails in last 344 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=246buildTypeId=IgniteTests24Java8_RunAll]
> Uncomment 19 test classes in IgniteExamplesJ8SelfTestSuite
> --
>
> Key: IGNITE-9211
> URL: https://issues.apache.org/jira/browse/IGNITE-9211
> Project: Ignite
> Issue Type: Sub-task
> Components: examples
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> {code}
> //suite.addTest(new TestSuite(ContinuationExamplesSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesSelfTest.class));
> //suite.addTest(new TestSuite(DeploymentExamplesSelfTest.class));
> //suite.addTest(new TestSuite(LifecycleExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MemcacheRestExamplesSelfTest.class));
> //suite.addTest(new TestSuite(MonteCarloExamplesSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesSelfTest.class));
> //suite.addTest(new TestSuite(SpringBeanExamplesSelfTest.class));
> //suite.addTest(new TestSuite(IgfsExamplesSelfTest.class));
> //suite.addTest(new TestSuite(CheckpointExamplesSelfTest.class));
> //suite.addTest(new TestSuite(HibernateL2CacheExampleSelfTest.class));
> //suite.addTest(new TestSuite(ClusterGroupExampleSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuationExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(ContinuousMapperExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(DeploymentExamplesMultiNodeSelfTest.class));
> //suite.addTest(new TestSuite(TaskExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MemcacheRestExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(MonteCarloExamplesMultiNodeSelfTest.class));
> //suite.addTest(new
> TestSuite(HibernateL2CacheExampleMultiNodeSelfTest.class));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10588) Fail to clean internal structure in the test on Zookeeper Discovery Spi
[ https://issues.apache.org/jira/browse/IGNITE-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10588: -- Description: In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk and ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients sometimes fails check on clean internal structure [1]. It seems that it is too small timeout on waiting for condition. [1] https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L539 was: In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk and ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients sometimes fails check on clean internal structure [1]. It seems that it is too small timeout on waiting for condition. [1] https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L552 > Fail to clean internal structure in the test on Zookeeper Discovery Spi > --- > > Key: IGNITE-10588 > URL: https://issues.apache.org/jira/browse/IGNITE-10588 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > > In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk and > ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients > sometimes fails check on clean internal structure [1]. It seems that it is > too small timeout on waiting for condition. > [1] > https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L539 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16719073#comment-16719073
]
Vladimir Ozerov edited comment on IGNITE-10643 at 12/13/18 1:09 PM:
https://ci.ignite.apache.org/viewQueued.html?itemId=2539046
was (Author: vozerov):
Another test run: https://ci.ignite.apache.org/viewQueued.html?itemId=2531616
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720148#comment-16720148
]
Ilya Kasnacheev commented on IGNITE-10451:
--
This also affects CacheStore restoration from Persistent cache config.
See
https://stackoverflow.com/questions/53758153/error-in-implementing-ignite-net-with-persistence/53761856
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object with given class loader:
> sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
>
[jira] [Commented] (IGNITE-10659) Possible deadlock causing by metadata request in grid-timeout-worker
[
https://issues.apache.org/jira/browse/IGNITE-10659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720131#comment-16720131
]
ASF GitHub Bot commented on IGNITE-10659:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5652
> Possible deadlock causing by metadata request in grid-timeout-worker
> -
>
> Key: IGNITE-10659
> URL: https://issues.apache.org/jira/browse/IGNITE-10659
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.8
>
>
> It looks like IGNITE-9840 fixes not all the cases.
> We have similar problem on a sever node:
> {code}
> Thread [name="grid-timeout-worker-#119%DPL_GRID%DplGridNodeName%", id=235,
> state=WAITING, blockCnt=2, waitCnt=664073]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:592)
> at
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:550)
> at
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:200)
> at o.a.i.i.binary.BinaryContext.metadata(BinaryContext.java:1266)
> at o.a.i.i.binary.BinaryUtils.type(BinaryUtils.java:2425)
> at o.a.i.i.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
> at
> o.a.i.i.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:208)
> at
> o.a.i.i.binary.BinaryObjectExImpl.appendValue(BinaryObjectExImpl.java:286)
> at
> o.a.i.i.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:235)
> at
> o.a.i.i.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:187)
> at o.a.i.i.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:920)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> o.a.i.i.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
> at java.lang.String.valueOf(String.java:2994)
> at o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:849)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1067)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:994)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:754)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:722)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1273)
> at java.lang.String.valueOf(String.java:2994)
> at o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:849)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:807)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.addCollection(GridToStringBuilder.java:900)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:845)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:807)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.appendVals(GridToStringBuilder.java:1662)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1070)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:994)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:754)
> at
> o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:722)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxStateImpl.toString(IgniteTxStateImpl.java:491)
> at java.lang.String.valueOf(String.java:2994)
> at o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> at
>
[jira] [Commented] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720129#comment-16720129
]
Alexey Goncharuk commented on IGNITE-9303:
--
IgniteLogicalRecoveryTest#testRecoveryOnCrushDuringCheckpointOnNodeStart still
fails locally for me after applying this change.
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8532) GA Grid: Implement Roulette Wheel Selection
[ https://issues.apache.org/jira/browse/IGNITE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720125#comment-16720125 ] Yury Babak commented on IGNITE-8532: [~netmille], I looking forward to your pr > GA Grid: Implement Roulette Wheel Selection > --- > > Key: IGNITE-8532 > URL: https://issues.apache.org/jira/browse/IGNITE-8532 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Turik Campbell >Assignee: Turik Campbell >Priority: Minor > Fix For: 2.8 > > > Roulette Wheel Selection Method is a type of selection used for selecting > potentially useful solutions for recombination. This selection method gives > more chances of selection to the better performing chromosomes. > IE: > https://en.wikipedia.org/wiki/Fitness_proportionate_selection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720103#comment-16720103 ] Uday Kale commented on IGNITE-9532: --- I have rebased the changes against the master. > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10672) Changing walSegments property leads to fallen node
[
https://issues.apache.org/jira/browse/IGNITE-10672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sherstobitov updated IGNITE-10672:
-
Description:
Start cluster with
{code}
{code}
Load some data and then restart cluster with new config:
{code}
{code}
This will lead nodes to fail on start
{code}
[14:51:00,852][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1784)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1008)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
Caused by: class
org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to initialize wal (work directory contains incorrect number of segments)
[cur=10, expected=5]
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkOrPrepareFiles(FileWriteAheadLogManager.java:1408)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.start0(FileWriteAheadLogManager.java:435)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:741)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1781)
... 11 more
[14:51:00,853][WARNING][main][IgniteKernal] Attempt to stop starting grid. This
operation cannot be guaranteed to be successful.
[14:51:00,855][SEVERE][main][IgniteKernal] Failed to stop component (ignoring):
GridProcessorAdapter []
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:631)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:980)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2312)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2190)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1164)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
{code}
was:
Start cluster with
{code}
{code}
Load some data and then restart cluster with new config:
{code}
{code}
This will lead node
[jira] [Updated] (IGNITE-10672) Changing walSegments property leads to fallen node
[
https://issues.apache.org/jira/browse/IGNITE-10672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sherstobitov updated IGNITE-10672:
-
Description:
Start cluster with
{code}
{code}
Load some data and then restart cluster with new config:
{code}
{code}
This will lead nodes to fail on start
{code}
[14:51:00,852][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1784)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1008)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
Caused by: class
org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to initialize wal (work directory contains incorrect number of segments)
[cur=10, expected=5]
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkOrPrepareFiles(FileWriteAheadLogManager.java:1408)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.start0(FileWriteAheadLogManager.java:435)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:741)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1781)
... 11 more
[14:51:00,853][WARNING][main][IgniteKernal] Attempt to stop starting grid. This
operation cannot be guaranteed to be successful.
[14:51:00,855][SEVERE][main][IgniteKernal] Failed to stop component (ignoring):
GridProcessorAdapter []
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:631)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:980)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2312)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2190)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1164)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
{code}
was:
Start cluster with
{code}
{code}
Load some data and then restart cluster with new config:
{code}
{code}
This will lead nodes to fail on
[jira] [Created] (IGNITE-10672) Changing walSegments property leads to fallen node
Dmitry Sherstobitov created IGNITE-10672:
Summary: Changing walSegments property leads to fallen node
Key: IGNITE-10672
URL: https://issues.apache.org/jira/browse/IGNITE-10672
Project: Ignite
Issue Type: Bug
Reporter: Dmitry Sherstobitov
Start cluster with
{code}
{code}
Load some data and then restart cluster with new config:
{code}
{code}
This will lead node to error on start
{code}
[14:51:00,852][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1784)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1008)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
Caused by: class
org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to initialize wal (work directory contains incorrect number of segments)
[cur=10, expected=5]
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkOrPrepareFiles(FileWriteAheadLogManager.java:1408)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.start0(FileWriteAheadLogManager.java:435)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:741)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1781)
... 11 more
[14:51:00,853][WARNING][main][IgniteKernal] Attempt to stop starting grid. This
operation cannot be guaranteed to be successful.
[14:51:00,855][SEVERE][main][IgniteKernal] Failed to stop component (ignoring):
GridProcessorAdapter []
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:631)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:980)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2312)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2190)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1164)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10671: Attachment: WalCompactionSwitchOverTest.java > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9322) MVCC: implement deadlock detector
[ https://issues.apache.org/jira/browse/IGNITE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709741#comment-16709741 ] Ivan Pavlukhin edited comment on IGNITE-9322 at 12/13/18 11:56 AM: --- Basic points for prototype: * Edge-chasing detection algorithm. * Configurable timeout before triggering detection. * Ability to disable deadlock detection. was (Author: pavlukhin): Basic points for prototype: * Edge-chasing detection algorithm. * Configurable timeout before triggering detection. > MVCC: implement deadlock detector > - > > Key: IGNITE-9322 > URL: https://issues.apache.org/jira/browse/IGNITE-9322 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Ivan Pavlukhin >Priority: Major > > Deadlocks are not uncommon during SQL execution. > We need to implement distributed deadlock detection protocol for MVCC. > Essentially, nodes should exchange some map of tx wait lists, and try to find > a loop. If loop is found, then one of problematic transactions should be > rolled back. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10671: Description: Race is painful when you switch your cluster from walCompaction=false to walCompaction=true. The same FileCompressor instance will use different segmentAwares due to start0() is called twice which leads to inconsistent behaviour and errors during compaction, basically we will try to archive files twice concurrently. > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > > Race is painful when you switch your cluster from walCompaction=false to > walCompaction=true. > The same FileCompressor instance will use different segmentAwares due to > start0() is called twice which leads to inconsistent behaviour and errors > during compaction, basically we will try to archive files twice concurrently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
Pavel Voronkin created IGNITE-10671: --- Summary: Double initialization of segmentAware and FileArchiver lead to race breaking file compression. Key: IGNITE-10671 URL: https://issues.apache.org/jira/browse/IGNITE-10671 Project: Ignite Issue Type: Bug Reporter: Pavel Voronkin Attachments: WalCompactionSwitchOverTest.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10257) Control.sh utility should request a SSL keystore password and SSL truststore password if necessary
[
https://issues.apache.org/jira/browse/IGNITE-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720073#comment-16720073
]
Ignite TC Bot commented on IGNITE-10257:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2529580buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh utility should request a SSL keystore password and SSL truststore
> password if necessary
> --
>
> Key: IGNITE-10257
> URL: https://issues.apache.org/jira/browse/IGNITE-10257
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Using passwords (–ssl_key_strore_password and --ssl_trust_store_password) in
> command line parametrs is not safe. We must request them if necessary.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
