[jira] [Commented] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117237#comment-17117237
]
Ignite TC Bot commented on IGNITE-12823:
{panel:title=Branch: [pull/7844/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5340825]]
{color:#d04437}Cache 8{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5340831]]
* IgniteCacheTestSuite8: GridCacheNearMetricsSelfTest.testNearRead - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5340860]]
* IgniteCacheMvccTestSuite2:
IgniteCachePartitionMapUpdateSafeLossPolicyTest.testRandom - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5340876&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116970#comment-17116970
]
Pavel Tupitsyn edited comment on IGNITE-12823 at 5/26/20, 6:47 PM:
---
[~zzzadruga], [~kukushal], [~nizhikov] my PR is ready for the review:
https://github.com/apache/ignite/pull/7844
In particular, please check Java-side array conversion: can it be improved?
In C# we pre-compile the conversion code, but in Java I had to use reflection.
was (Author: ptupitsyn):
[~zzzadruga][~kukushal][~nizhikov] my PR is ready for the review:
https://github.com/apache/ignite/pull/7844
In particular, please check Java-side array conversion: can it be improved?
In C# we pre-compile the conversion code, but in Java I had to use reflection.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116970#comment-17116970
]
Pavel Tupitsyn commented on IGNITE-12823:
-
[~zzzadruga][~kukushal][~nizhikov] my PR is ready for the review:
https://github.com/apache/ignite/pull/7844
In particular, please check Java-side array conversion: can it be improved?
In C# we pre-compile the conversion code, but in Java I had to use reflection.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment
[
https://issues.apache.org/jira/browse/IGNITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned IGNITE-5836:
---
Assignee: Maxim Muzafarov
> AffinityFunctionContext should provide consistent previous assignment
> -
>
> Key: IGNITE-5836
> URL: https://issues.apache.org/jira/browse/IGNITE-5836
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: usability
>
> Currently each cache maintains its own {{AffinityFunctionContext}}. This
> leads to the case that {{previousAssignment}} can be different for two caches
> created on different topology versions. In particular, this broke
> {{FairAffinityFunction}} which was removed because of that.
> We should do the following:
> * Make sure that {{previousAssignment}} is consistent for all caches with
> same affinity function, regardless of topology versions caches were created
> on.
> * Add mechanism to enforce equality check for affinity functions. We probably
> will need to force user to implement {{equals}} for cache node filter and
> backup filter.
> * When above is done, bring back {{FairAffinityFunction}}.
> This is also discussed on dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13079) Replace deprecated cluster activation methods in tests.
Sergey Antonov created IGNITE-13079:
---
Summary: Replace deprecated cluster activation methods in tests.
Key: IGNITE-13079
URL: https://issues.apache.org/jira/browse/IGNITE-13079
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
After we IGNITE-12225 we have a new API for a changing cluster state. We must
replace deprecated methods ({{IgniteCluster#active()}},
{{IgniteCluster#active(boolean)}} and etc) to a new API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13078) С++: Add CMake build support
Ivan Daschinskiy created IGNITE-13078: - Summary: С++: Add CMake build support Key: IGNITE-13078 URL: https://issues.apache.org/jira/browse/IGNITE-13078 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.9 Currently, it is hard to build Ignite.C++. Different build process for windows and linux, lack of building support on Mac OS X (quite popular OS among developers), absolutely not IDE support, except windows and only Visual Studio is supported. I’d suggest to migrate to CMake build system. It is very popular among open source projects, and in Apache Software Foundation too. Notable user: Apache Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache Thrift. Popular column-oriented database ClickHouse also uses CMake. CMake is widely supported in many IDE’s on various platforms, notably Visual Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13077) .NET: transaction shared for multiple Ignite instances trying to start transactions in one thread
[
https://issues.apache.org/jira/browse/IGNITE-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Stronchinskiy updated IGNITE-13077:
--
Summary: .NET: transaction shared for multiple Ignite instances trying to
start transactions in one thread (was: .NET: transaction shared for multiple
Ignite trying to start transactions in one thread)
> .NET: transaction shared for multiple Ignite instances trying to start
> transactions in one thread
> -
>
> Key: IGNITE-13077
> URL: https://issues.apache.org/jira/browse/IGNITE-13077
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Sergey Stronchinskiy
>Priority: Minor
> Labels: .NET
>
> {code:c#}
> var trs1 = Ignition.Start(new IgniteConfiguration
> {
> IgniteInstanceName = "First"
> })
> .GetTransactions();
> trs1.TxStart();
> var trs2 = Ignition.Start(new IgniteConfiguration
> {
> IgniteInstanceName = "Second"
> })
> .GetTransactions();
> Assert.IsNull(trs2.Tx); // fails
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13077) .NET: transaction shared for multiple Ignite trying to start transactions in one thread
[
https://issues.apache.org/jira/browse/IGNITE-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Stronchinskiy updated IGNITE-13077:
--
Summary: .NET: transaction shared for multiple Ignite trying to start
transactions in one thread (was: .NET transaction gets overwritten for
multiple Ignite trying to start transactions in one thread)
> .NET: transaction shared for multiple Ignite trying to start transactions in
> one thread
> ---
>
> Key: IGNITE-13077
> URL: https://issues.apache.org/jira/browse/IGNITE-13077
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Sergey Stronchinskiy
>Priority: Minor
> Labels: .NET
>
> {code:c#}
> var trs1 = Ignition.Start(new IgniteConfiguration
> {
> IgniteInstanceName = "First"
> })
> .GetTransactions();
> trs1.TxStart();
> var trs2 = Ignition.Start(new IgniteConfiguration
> {
> IgniteInstanceName = "Second"
> })
> .GetTransactions();
> Assert.IsNull(trs2.Tx); // fails
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13077) .NET transaction gets overwritten for multiple Ignite trying to start transactions in one thread
Sergey Stronchinskiy created IGNITE-13077:
-
Summary: .NET transaction gets overwritten for multiple Ignite
trying to start transactions in one thread
Key: IGNITE-13077
URL: https://issues.apache.org/jira/browse/IGNITE-13077
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Sergey Stronchinskiy
{code:c#}
var trs1 = Ignition.Start(new IgniteConfiguration
{
IgniteInstanceName = "First"
})
.GetTransactions();
trs1.TxStart();
var trs2 = Ignition.Start(new IgniteConfiguration
{
IgniteInstanceName = "Second"
})
.GetTransactions();
Assert.IsNull(trs2.Tx); // fails
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13076) Cluster read-only mode doesn't affect LOCAL caches
Sergey Antonov created IGNITE-13076:
---
Summary: Cluster read-only mode doesn't affect LOCAL caches
Key: IGNITE-13076
URL: https://issues.apache.org/jira/browse/IGNITE-13076
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Sergey Antonov
Fix For: 2.9
You can make data modification operations with LOCAL cache even if cluster in a
{{ACTIVE_READ_ONLY}} state.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13075) NPE on request JDBC metadata
[
https://issues.apache.org/jira/browse/IGNITE-13075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-13075:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> NPE on request JDBC metadata
>
>
> Key: IGNITE-13075
> URL: https://issues.apache.org/jira/browse/IGNITE-13075
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>
> NPE occure when metadata is requested and there is a table created through
> java API like a
> {code:java}
> ignite.createCache(
> new CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setIndexedTypes(Integer.class, String.class)
> );{code}
> Error here:
> {code:java}
> [2020-05-26
> 15:52:24,502][ERROR][client-connector-#264%thin.JdbcThinMetadataSelfTest0%][JdbcRequestHandler]
> Failed to get columns metadata [reqId=15, req=JdbcMetaColumnsRequest
> [schemaName=testCache, tblName=null, colName=null]][2020-05-26
> 15:52:24,502][ERROR][client-connector-#264%thin.JdbcThinMetadataSelfTest0%][JdbcRequestHandler]
> Failed to get columns metadata [reqId=15, req=JdbcMetaColumnsRequest
> [schemaName=testCache, tblName=null,
> colName=null]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$null$10(IgniteH2Indexing.java:1902)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:270) at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.columnsInformation(IgniteH2Indexing.java:1910)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcMetadataInfo.getColumnsMeta(JdbcMetadataInfo.java:180)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.getColumnsMeta(JdbcRequestHandler.java:1128)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:348)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:200)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:54)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13075) NPE on request JDBC metadata
[
https://issues.apache.org/jira/browse/IGNITE-13075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116726#comment-17116726
]
Konstantin Orlov commented on IGNITE-13075:
---
[~tledkov-gridgain], [~amashenkov], guys, do a review please.
> NPE on request JDBC metadata
>
>
> Key: IGNITE-13075
> URL: https://issues.apache.org/jira/browse/IGNITE-13075
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>
> NPE occure when metadata is requested and there is a table created through
> java API like a
> {code:java}
> ignite.createCache(
> new CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setIndexedTypes(Integer.class, String.class)
> );{code}
> Error here:
> {code:java}
> [2020-05-26
> 15:52:24,502][ERROR][client-connector-#264%thin.JdbcThinMetadataSelfTest0%][JdbcRequestHandler]
> Failed to get columns metadata [reqId=15, req=JdbcMetaColumnsRequest
> [schemaName=testCache, tblName=null, colName=null]][2020-05-26
> 15:52:24,502][ERROR][client-connector-#264%thin.JdbcThinMetadataSelfTest0%][JdbcRequestHandler]
> Failed to get columns metadata [reqId=15, req=JdbcMetaColumnsRequest
> [schemaName=testCache, tblName=null,
> colName=null]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$null$10(IgniteH2Indexing.java:1902)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:270) at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.columnsInformation(IgniteH2Indexing.java:1910)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcMetadataInfo.getColumnsMeta(JdbcMetadataInfo.java:180)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.getColumnsMeta(JdbcRequestHandler.java:1128)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:348)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:200)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:54)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13041) PDS (Indexing) is failed with 137 code
[
https://issues.apache.org/jira/browse/IGNITE-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116723#comment-17116723
]
Ignite TC Bot commented on IGNITE-13041:
{panel:title=Branch: [pull/7820/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5329583&buildTypeId=IgniteTests24Java8_RunAll]
> PDS (Indexing) is failed with 137 code
> --
>
> Key: IGNITE-13041
> URL: https://issues.apache.org/jira/browse/IGNITE-13041
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Process exited with code 137
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexing?branch=%3Cdefault%3E&buildTypeTab=overview&mode=builds
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13075) NPE on request JDBC metadata
Konstantin Orlov created IGNITE-13075:
-
Summary: NPE on request JDBC metadata
Key: IGNITE-13075
URL: https://issues.apache.org/jira/browse/IGNITE-13075
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov
NPE occure when metadata is requested and there is a table created through java
API like a
{code:java}
ignite.createCache(
new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setIndexedTypes(Integer.class, String.class)
);{code}
Error here:
{code:java}
[2020-05-26
15:52:24,502][ERROR][client-connector-#264%thin.JdbcThinMetadataSelfTest0%][JdbcRequestHandler]
Failed to get columns metadata [reqId=15, req=JdbcMetaColumnsRequest
[schemaName=testCache, tblName=null, colName=null]][2020-05-26
15:52:24,502][ERROR][client-connector-#264%thin.JdbcThinMetadataSelfTest0%][JdbcRequestHandler]
Failed to get columns metadata [reqId=15, req=JdbcMetaColumnsRequest
[schemaName=testCache, tblName=null,
colName=null]]java.lang.NullPointerException at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$null$10(IgniteH2Indexing.java:1902)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:270) at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at
java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.columnsInformation(IgniteH2Indexing.java:1910)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcMetadataInfo.getColumnsMeta(JdbcMetadataInfo.java:180)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.getColumnsMeta(JdbcRequestHandler.java:1128)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:348)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:200)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:54)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116685#comment-17116685 ] Alexey Scherbakov commented on IGNITE-13051: [~timonin.maksim] This configuration causes cache to be started in client mode on a node0. > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13074) Thin client: Default compute cluster group should be "server nodes", but currently "all nodes"
Aleksey Plekhanov created IGNITE-13074: -- Summary: Thin client: Default compute cluster group should be "server nodes", but currently "all nodes" Key: IGNITE-13074 URL: https://issues.apache.org/jira/browse/IGNITE-13074 Project: Ignite Issue Type: Bug Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov When executing compute tasks from thin client without specifying cluster group, tasks should be executed only on server nodes. But currently client nodes are also included. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116613#comment-17116613 ] Maksim Timonin edited comment on IGNITE-13051 at 5/26/20, 10:42 AM: [~ascherbakov] hi! I've made some research and have a question about the test case [0 false false -1]. In this case: # 4 server nodes started; # 3 of them (id is in 1,2,3) configured with IgniteConfiguration *with* invoked setCacheConfiguration (*default* cache); # Node with id=0 configured with IgniteConfiguration *without* invocation setCacheConfiguration; It looks like the id=0 node is filtered by the fact that the cache is not configured at all, not by AttributeNodeFilter. Is it a valid case? Please check the code line, it is not invoked for the id=0 node: [CachePartitionLossWithRestartsTest.java#L135|https://github.com/gridgain/apache-ignite/blob/ignite-13003/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CachePartitionLossWithRestartsTest.java#L135] After configuring the cache on the id=0 node the test case passed. was (Author: timonin.maksim): [~ascherbakov] hi! I've made some research and have a question about the test case [0 false false -1]. In this case: # 4 server nodes started; # 3 of them (id is in 1,2,3) configured with IgniteConfiguration *with* invoked setCacheConfiguration (*default* cache); # Node with id=0 configured with IgniteConfiguration *without* invocation setCacheConfiguration; It looks like the id=0 node is filtered by the fact that the cache is not configured at all, not by AttributeNodeFilter. Is it a valid case? Please check the code line, it is not invoked for the id=0 node: [CachePartitionLossWithRestartsTest.java#L135|https://github.com/gridgain/apache-ignite/blob/ignite-13003/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CachePartitionLossWithRestartsTest.java#L135] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116613#comment-17116613 ] Maksim Timonin edited comment on IGNITE-13051 at 5/26/20, 10:40 AM: [~ascherbakov] hi! I've made some research and have a question about the test case [0 false false -1]. In this case: # 4 server nodes started; # 3 of them (id is in 1,2,3) configured with IgniteConfiguration *with* invoked setCacheConfiguration (*default* cache); # Node with id=0 configured with IgniteConfiguration *without* invocation setCacheConfiguration; It looks like the id=0 node is filtered by the fact that the cache is not configured at all, not by AttributeNodeFilter. Is it a valid case? Please check the code line, it is not invoked for the id=0 node: [CachePartitionLossWithRestartsTest.java#L135|https://github.com/gridgain/apache-ignite/blob/ignite-13003/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CachePartitionLossWithRestartsTest.java#L135] was (Author: timonin.maksim): [~ascherbakov] hi! I've made some research and have a question about the test case [0 false false -1]. In this case: # 4 server nodes started; # 3 of them (id is in 1,2,3) configured with IgniteConfiguration *with* invoked setCacheConfiguration (*default* cache); # Node with id=0 configured with IgniteConfiguration *without* invocation setCacheConfiguration; It looks like the node id=0 is filtered by the fact that the cache is not configured at all, **not by AttributeNodeFilter. Is it a valid case? Please check the code line, it is not invoked for the id=0 node: [CachePartitionLossWithRestartsTest.java#L135|https://github.com/gridgain/apache-ignite/blob/ignite-13003/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CachePartitionLossWithRestartsTest.java#L135] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116613#comment-17116613 ] Maksim Timonin commented on IGNITE-13051: - [~ascherbakov] hi! I've made some research and have a question about the test case [0 false false -1]. In this case: # 4 server nodes started; # 3 of them (id is in 1,2,3) configured with IgniteConfiguration *with* invoked setCacheConfiguration (*default* cache); # Node with id=0 configured with IgniteConfiguration *without* invocation setCacheConfiguration; It looks like the node id=0 is filtered by the fact that the cache is not configured at all, **not by AttributeNodeFilter. Is it a valid case? Please check the code line, it is not invoked for the id=0 node: [CachePartitionLossWithRestartsTest.java#L135|https://github.com/gridgain/apache-ignite/blob/ignite-13003/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CachePartitionLossWithRestartsTest.java#L135] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13042:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13073) NPE on closing node in communication SPI
Nikita Tolstunov created IGNITE-13073:
-
Summary: NPE on closing node in communication SPI
Key: IGNITE-13073
URL: https://issues.apache.org/jira/browse/IGNITE-13073
Project: Ignite
Issue Type: Bug
Reporter: Nikita Tolstunov
Assignee: Nikita Tolstunov
I got this exception on TC. The issue can leads to stuck Thin Client Java suite.
I have reproduced it local, when ReliabilityTest#testFailover looped.
{{[19:44:27,889][SEVERE][sys-stripe-1-#39670%533fdeb2-8079-45a3-874b-368c89491fb4%][]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NullPointerException]]
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2810)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2794)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1724)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1830)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3556)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$3300(GridDhtAtomicCache.java:138)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout.run(GridDhtAtomicCache.java:3802)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13072) Synchronization problems when different classloaders are used for deployment of same class
Vladislav Pyatkov created IGNITE-13072:
--
Summary: Synchronization problems when different classloaders are
used for deployment of same class
Key: IGNITE-13072
URL: https://issues.apache.org/jira/browse/IGNITE-13072
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Assignee: Vladislav Pyatkov
If you concurrently deploy one class using different classloaders you can get
error:
{noformat}
2020-04-28
14:36:42.523[ERROR][sys-stripe-45-#46%GRID%GridNodeName%][o.a.i.i.m.d.GridDeploymentLocalStore]
Found more than one active deployment for the same resource [cls=class
org.some.class.old.InvokeIndexRemover, depMode=SHARED, dep=GridDeployment
[ts=1588067100125, depMode=SHARED,
clsLdr=org.some.class.factory.NodeClassLoader@14035d21,
clsLdrId=85ab310c171-a9fad11c-9f8c-4d2a-8146-6c87254303e7, userVer=0, loc=true,
sampleClsName=org.some.class.predicates.CompositePredicate,
pendingUndeploy=false, undeployed=false, usage=0]]
2020-04-28
14:36:42.544[ERROR][sys-stripe-45-#46%GRID%GridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=f104e069-9d80-4202-b50a-b3dc1804ac89,
msg=GridNearAtomicSingleUpdateRequest [key=KeyCacheObject [hasValBytes=true],
super=GridNearAtomicSingleUpdateRequest [key=KeyCacheObject [hasValBytes=true],
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=1376257,
topVer=AffinityTopologyVersion [topVer=35, minorTopVer=0],
parent=GridNearAtomicAbstractUpdateRequest [res=null, flags=]
java.lang.AssertionError: null
at
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:203)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getLocalDeployment(GridDeploymentManager.java:383)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.findClass(GridCacheDeploymentManager.java:802)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.loadClass(GridCacheDeploymentManager.java:794)
at org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8561)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9959)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10017)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateInvokeRequest.finishUnmarshal(GridNearAtomicSingleUpdateInvokeRequest.java:200)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1560)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:546)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Looks like we lack synchronization for modifying
{{LocalDeploymentSpi.ldrRsrcs}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-4022) IgniteServices soesn't throw an exception if there are no server nodes
[ https://issues.apache.org/jira/browse/IGNITE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-4022: - Assignee: (was: Vladislav Pyatkov) > IgniteServices soesn't throw an exception if there are no server nodes > -- > > Key: IGNITE-4022 > URL: https://issues.apache.org/jira/browse/IGNITE-4022 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.8 >Reporter: Alexander Belyak >Priority: Major > > If you call deployNodeSingleton method, but there are no server nodes in > IgniteServices base ClusterGroup - you will never know about it and can't > find deployed service instance. Probably we should print out these errors in > logs as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-9391) Incorrect calculated esitmated rebalancing finish time
[ https://issues.apache.org/jira/browse/IGNITE-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-9391: - Assignee: (was: Vladislav Pyatkov) > Incorrect calculated esitmated rebalancing finish time > -- > > Key: IGNITE-9391 > URL: https://issues.apache.org/jira/browse/IGNITE-9391 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Time Spent: 10m > Remaining Estimate: 0h > > Actually looks like test > CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime is incorrect > or we have bug in esitmated rebalancing finish time calculation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-8391) Removing some WAL history segments leads to WAL rebalance hanging
[
https://issues.apache.org/jira/browse/IGNITE-8391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-8391:
-
Assignee: (was: Vladislav Pyatkov)
> Removing some WAL history segments leads to WAL rebalance hanging
> -
>
> Key: IGNITE-8391
> URL: https://issues.apache.org/jira/browse/IGNITE-8391
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Priority: Major
> Fix For: 2.9
>
>
> Problem:
> 1) Start 2 nodes, load some data to it.
> 2) Stop node 2, load some data to cache.
> 3) Remove WAL archived segment which doesn't contain Checkpoint record needed
> to find start point for WAL rebalance, but contains necessary data for
> rebalancing.
> 4) Start node 2, this node will start rebalance data from node 1 using WAL.
> Rebalance will be hanged with following assertion:
> {noformat}
> java.lang.AssertionError: Partitions after rebalance should be either done or
> missing: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
> 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:379)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
> This happened because we never reached necessary data and updateCounters
> contained in removed WAL segment.
> To resolve such problems we should introduce some fallback strategy if
> rebalance by WAL has been failed. Example of fallback strategy is - re-run
> full rebalance for partitions that were not able properly rebalanced using
> WAL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13071: Description: It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service * Updates to metastorage/distributed metastorage. was: It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13071) Improve test coverage for read-only cluster state
Sergey Antonov created IGNITE-13071: --- Summary: Improve test coverage for read-only cluster state Key: IGNITE-13071 URL: https://issues.apache.org/jira/browse/IGNITE-13071 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13057) Do not print /tmp path if pds file is not stored in tmp folder.
[ https://issues.apache.org/jira/browse/IGNITE-13057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-13057: - Ignite Flags: (was: Docs Required,Release Notes Required) > Do not print /tmp path if pds file is not stored in tmp folder. > --- > > Key: IGNITE-13057 > URL: https://issues.apache.org/jira/browse/IGNITE-13057 > Project: Ignite > Issue Type: Improvement >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Temporary folder for pds warning can be printed even if pds is not located > there -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116531#comment-17116531
]
Ilya Kasnacheev commented on IGNITE-10940:
--
[~nizhikov] please file a bug about broken Windows build, I will try to make
this stage optional.
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build, platforms
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: c++
> Fix For: 2.9
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116528#comment-17116528
]
Ilya Kasnacheev commented on IGNITE-13066:
--
Give me a few days, I will try to merge the "large" ticket or will merge just
this one change.
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116517#comment-17116517
]
Nikolai Kulagin commented on IGNITE-12823:
--
[~ptupitsyn], reading arrays as BinaryObject can be done in Ignite 3.0.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Kulagin reassigned IGNITE-12823:
Assignee: Pavel Tupitsyn (was: Nikolai Kulagin)
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
