[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[
https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811210#comment-16811210
]
Ignite TC Bot commented on IGNITE-11226:
{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=3500912buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Remove GridQueryIndexing.prepareNativeStatement
>
>
> Key: IGNITE-11226
> URL: https://issues.apache.org/jira/browse/IGNITE-11226
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This method is the only leak of H2 internals to the outer code. Close
> analysis of code reveals that the only reason we have it is *JDBC metadata*.
> Need to create a method which will prepare metadata for a statement and
> return it as a detached object. Most probably we already have all necessary
> mechanics. This is more about refactoring.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11525) .NET: Deprecate SqlQuery API
[
https://issues.apache.org/jira/browse/IGNITE-11525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811204#comment-16811204
]
Ignite TC Bot commented on IGNITE-11525:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3517334]]
* IgnitePdsWithIndexingCoreTestSuite:
WalRecoveryTxLogicalRecordsTest.testFreeListRecovery - 0,0% fails in last 181
master runs.
{color:#d04437}Cache 5{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3517322]]
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeWithBackupsAfterKillThreeNodesWithPersistence[TRANSACTIONAL]
- 0,0% fails in last 183 master runs.
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeWithBackupsWithPersistence[TRANSACTIONAL]
- 0,0% fails in last 183 master runs.
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodesWithPersistence[TRANSACTIONAL]
- 0,0% fails in last 183 master runs.
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3517291]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3517370buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Deprecate SqlQuery API
>
>
> Key: IGNITE-11525
> URL: https://issues.apache.org/jira/browse/IGNITE-11525
> Project: Ignite
> Issue Type: Task
> Components: platforms, thin client
>Reporter: Taras Ledkov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with
> proper links to SqlFieldsQuery. This should be not only deprecation on public
> API, but removal from examples as well.
> Also please remove hidden columns _key, _val from examples.
> All of this includes:
> * Thin client and examples
> * .NET Core examples
> * LINQPad examples
> Parent ticket: IGNITE-11334
> Ticket for documentation: IGNITE-11370
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11442) Renaming IGNITE schema to something more clear SYS, SYSTEM, ...
[
https://issues.apache.org/jira/browse/IGNITE-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811195#comment-16811195
]
Ignite TC Bot commented on IGNITE-11442:
{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=3505833buildTypeId=IgniteTests24Java8_RunAll]
> Renaming IGNITE schema to something more clear SYS, SYSTEM, ...
> ---
>
> Key: IGNITE-11442
> URL: https://issues.apache.org/jira/browse/IGNITE-11442
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider renaming IGNITE schema to something more clear. E.g. SYS or SYSTEM.
>
> We make decision to use SYS as schema name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading
[ https://issues.apache.org/jira/browse/IGNITE-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-11690: -- Labels: .NET (was: ) Component/s: clients > .NET: Cache iteration hangs with enabled peerAssemblyLoading > > > Key: IGNITE-11690 > URL: https://issues.apache.org/jira/browse/IGNITE-11690 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > > Original reproducer: > [https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0] With > two server nodes, and a client that spawn a computation with a simple cache > iteration for custom class value > Problem: > If peer assembly loading enabled and no assembly exist for the nodes, then > there is an endless loop: nodes are requesting the assembly from each other > and no one is able to locate it. > As an example of missing dll there could be a > "System.Configuration.Configuration" for the .NET Core app > [https://github.com/dotnet/standard/issues/506] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811031#comment-16811031
]
Andrey Gura commented on IGNITE-11687:
--
[~agoncharuk] You are right. It could be fixed easy.
{{FileHandleManagerImpl.WALWriter#writeBuffer}} method has only one usage so it
can just return delta that must be added to the {{hnd.written}.}
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.8
>
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
[ https://issues.apache.org/jira/browse/IGNITE-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811030#comment-16811030 ] Alexey Goncharuk commented on IGNITE-11691: --- Checked the PDS2 suite on TC, merging to master. > IgniteWalSerializerVersionTest fails in master with NoSuchElementException > -- > > Key: IGNITE-11691 > URL: https://issues.apache.org/jira/browse/IGNITE-11691 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails > The issue is caused by an incorrect test: test iterator should pass only > instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811031#comment-16811031
]
Andrey Gura edited comment on IGNITE-11687 at 4/5/19 4:38 PM:
--
[~agoncharuk] You are right. It could be fixed easy.
{{FileHandleManagerImpl.WALWriter#writeBuffer}} method has only one usage so it
can just return delta that must be added to the {{hnd.written}}.
was (Author: agura):
[~agoncharuk] You are right. It could be fixed easy.
{{FileHandleManagerImpl.WALWriter#writeBuffer}} method has only one usage so it
can just return delta that must be added to the {{hnd.written}.}
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.8
>
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
[ https://issues.apache.org/jira/browse/IGNITE-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-11691. --- Resolution: Fixed > IgniteWalSerializerVersionTest fails in master with NoSuchElementException > -- > > Key: IGNITE-11691 > URL: https://issues.apache.org/jira/browse/IGNITE-11691 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails > The issue is caused by an incorrect test: test iterator should pass only > instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura reassigned IGNITE-11687:
Assignee: Andrey Gura
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.8
>
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810959#comment-16810959 ] Ivan Bessonov edited comment on IGNITE-11684 at 4/5/19 4:12 PM: [~agoncharuk] I would remove new test if you don't mind. It doesn't add anything new. "Node.js" suite is unstable in master right now (always fails on all aitc-lin* agents). EDIT: I removed that test and rerun Node.js suite just in case: [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ThinClientNodeJs=pull%2F6410%2Fhead=buildTypeStatusDiv] was (Author: ibessonov): [~agoncharuk] I would remove new test if you don't mind. It doesn't add anything new. "Node.js" suite is unstable in master right now. EDIT: I removed that test and rerun Node.js suite just in case: [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ThinClientNodeJs=pull%2F6410%2Fhead=buildTypeStatusDiv] > CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky > > > Key: IGNITE-11684 > URL: https://issues.apache.org/jira/browse/IGNITE-11684 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E] > > Problem occurs when two optimistic transactions are being > executed from the same client with near cache, when one of transaction > removes key and another updates. > In this scenario near node can be removed from "readers" list if "remove" > transaction was completed before "update" transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading
[
https://issues.apache.org/jira/browse/IGNITE-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-11690:
--
Description:
Original reproducer:
[https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0] With
two server nodes, and a client that spawn a computation with a simple cache
iteration for custom class value
Problem:
If peer assembly loading enabled and no assembly exist for the nodes, then
there is an endless loop: nodes are requesting the assembly from each other and
no one is able to locate it.
As an example of missing dll there could be a
"System.Configuration.Configuration" for the .NET Core app
[https://github.com/dotnet/standard/issues/506]
was:
Solution to reproduce:
[https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0]
Given:
* 2 server .NET nodes with PeerAssembly = enabled
* Simple custom type cache with a few records
{code:java}
ignite.GetOrCreateCache(new CacheConfiguration(Hotel.Cache, new
QueryEntity(typeof(Guid), typeof(Hotel;
{code}
* 1 Client node that spawn computation task and performs a simple iteration
over cache
{code:java}
class HelloAction : IComputeAction
{
[InstanceResource]
private IIgnite _ignite;
public void Invoke()
{
var hotels = _ignite.GetCache("SomeName").ToList()
}
}
{code}
Problem:
One of the server nodes successfully performs the computation, but the other
getting locked inside the
{code:java}
AssemblyRequestResult ComputeApplySafe(ICompute compute, GetAssemblyFunc func,
AssemblyRequest req)
{code}
When I disable PeerAssembly then all is getting back to normal
> .NET: Cache iteration hangs with enabled peerAssemblyLoading
>
>
> Key: IGNITE-11690
> URL: https://issues.apache.org/jira/browse/IGNITE-11690
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Major
>
> Original reproducer:
> [https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0] With
> two server nodes, and a client that spawn a computation with a simple cache
> iteration for custom class value
> Problem:
> If peer assembly loading enabled and no assembly exist for the nodes, then
> there is an endless loop: nodes are requesting the assembly from each other
> and no one is able to locate it.
> As an example of missing dll there could be a
> "System.Configuration.Configuration" for the .NET Core app
> [https://github.com/dotnet/standard/issues/506]
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading
[
https://issues.apache.org/jira/browse/IGNITE-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810981#comment-16810981
]
Pavel Tupitsyn commented on IGNITE-11690:
-
Analysis:
* .NET Core is used
* PeerAssemblyLoading for System.Configuration.ConfigurationManager hangs: this
assembly is not present on any of the nodes (see
https://github.com/dotnet/standard/issues/506)
Root cause:
* Assembly.Load during peer loading triggers more peer requests if the assembly
is not present, this goes on forever if the assembly is not found on any nodes
> .NET: Cache iteration hangs with enabled peerAssemblyLoading
>
>
> Key: IGNITE-11690
> URL: https://issues.apache.org/jira/browse/IGNITE-11690
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Major
>
> Solution to reproduce:
> [https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0]
> Given:
> * 2 server .NET nodes with PeerAssembly = enabled
> * Simple custom type cache with a few records
> {code:java}
> ignite.GetOrCreateCache(new CacheConfiguration(Hotel.Cache, new
> QueryEntity(typeof(Guid), typeof(Hotel;
> {code}
> * 1 Client node that spawn computation task and performs a simple iteration
> over cache
>
>
> {code:java}
> class HelloAction : IComputeAction
> {
> [InstanceResource]
> private IIgnite _ignite;
> public void Invoke()
> {
> var hotels = _ignite.GetCache("SomeName").ToList()
> }
> }
> {code}
>
> Problem:
>
> One of the server nodes successfully performs the computation, but the other
> getting locked inside the
> {code:java}
> AssemblyRequestResult ComputeApplySafe(ICompute compute, GetAssemblyFunc func,
> AssemblyRequest req)
> {code}
> When I disable PeerAssembly then all is getting back to normal
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810959#comment-16810959 ] Ivan Bessonov edited comment on IGNITE-11684 at 4/5/19 4:00 PM: [~agoncharuk] I would remove new test if you don't mind. It doesn't add anything new. "Node.js" suite is unstable in master right now. EDIT: I removed that test and rerun Node.js suite just in case: [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ThinClientNodeJs=pull%2F6410%2Fhead=buildTypeStatusDiv] was (Author: ibessonov): [~agoncharuk] I would remove new test if you don't mind. It doesn't add anything new. "Node.js" suite is unstable in master right now. > CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky > > > Key: IGNITE-11684 > URL: https://issues.apache.org/jira/browse/IGNITE-11684 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E] > > Problem occurs when two optimistic transactions are being > executed from the same client with near cache, when one of transaction > removes key and another updates. > In this scenario near node can be removed from "readers" list if "remove" > transaction was completed before "update" transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810959#comment-16810959 ] Ivan Bessonov commented on IGNITE-11684: [~agoncharuk] I would remove new test if you don't mind. It doesn't add anything new. "Node.js" suite is unstable in master right now. > CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky > > > Key: IGNITE-11684 > URL: https://issues.apache.org/jira/browse/IGNITE-11684 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E] > > Problem occurs when two optimistic transactions are being > executed from the same client with near cache, when one of transaction > removes key and another updates. > In this scenario near node can be removed from "readers" list if "remove" > transaction was completed before "update" transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8578) .NET: Add baseline auto-adjust parameters (definition, run-time change)
[ https://issues.apache.org/jira/browse/IGNITE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-8578: - Summary: .NET: Add baseline auto-adjust parameters (definition, run-time change) (was: .Net Add support baseline auto-adjust parameters (definition, run-time change)) > .NET: Add baseline auto-adjust parameters (definition, run-time change) > --- > > Key: IGNITE-8578 > URL: https://issues.apache.org/jira/browse/IGNITE-8578 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET, IEP-4, Phase-2 > > We would introduce at IGNITE-8571 new parameters. > We need their support in .Net side. > See new methods on IgniteCluster interface IGNITE-11509 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8578) .NET: Add baseline auto-adjust parameters (definition, run-time change)
[ https://issues.apache.org/jira/browse/IGNITE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-8578: - Component/s: platforms > .NET: Add baseline auto-adjust parameters (definition, run-time change) > --- > > Key: IGNITE-8578 > URL: https://issues.apache.org/jira/browse/IGNITE-8578 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Eduard Shangareev >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET, IEP-4, Phase-2 > > We would introduce at IGNITE-8571 new parameters. > We need their support in .Net side. > See new methods on IgniteCluster interface IGNITE-11509 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[
https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810957#comment-16810957
]
Ignite TC Bot commented on IGNITE-11684:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3515874]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3513138buildTypeId=IgniteTests24Java8_RunAll]
> CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
>
>
> Key: IGNITE-11684
> URL: https://issues.apache.org/jira/browse/IGNITE-11684
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E]
>
> Problem occurs when two optimistic transactions are being
> executed from the same client with near cache, when one of transaction
> removes key and another updates.
> In this scenario near node can be removed from "readers" list if "remove"
> transaction was completed before "update" transaction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-11614. --- Resolution: Fixed Merged to master > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11666) C++ : remove internal macro usages in the examples
[
https://issues.apache.org/jira/browse/IGNITE-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-11666:
Assignee: Igor Sapego
> C++ : remove internal macro usages in the examples
> --
>
> Key: IGNITE-11666
> URL: https://issues.apache.org/jira/browse/IGNITE-11666
> Project: Ignite
> Issue Type: Bug
> Components: examples, platforms
>Reporter: Pavel Kuznetsov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++, examples
>
> Currently c++ examples are using internal macros. For example to specify how
> to serialize/deserialize user's c++ structs.
> {code:c++}
> IGNITE_BINARY_TYPE_START(ignite::examples::Person)
> typedef ignite::examples::Person Person;
> IGNITE_BINARY_GET_TYPE_ID_AS_HASH(Person)
> IGNITE_BINARY_GET_TYPE_NAME_AS_IS(Person)
> IGNITE_BINARY_GET_FIELD_ID_AS_HASH
> IGNITE_BINARY_IS_NULL_FALSE(Person)
> IGNITE_BINARY_GET_NULL_DEFAULT_CTOR(Person)
> //...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810938#comment-16810938 ] Alexey Goncharuk commented on IGNITE-11684: --- [~ibessonov], the change looks legit to me, good job on finding this one! Is the TC bot happy with the changes? > CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky > > > Key: IGNITE-11684 > URL: https://issues.apache.org/jira/browse/IGNITE-11684 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E] > > Problem occurs when two optimistic transactions are being > executed from the same client with near cache, when one of transaction > removes key and another updates. > In this scenario near node can be removed from "readers" list if "remove" > transaction was completed before "update" transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810932#comment-16810932
]
Pavel Kuznetsov commented on IGNITE-11588:
--
[~vozerov] done ^
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
[ https://issues.apache.org/jira/browse/IGNITE-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11691: -- Ignite Flags: (was: Docs Required) > IgniteWalSerializerVersionTest fails in master with NoSuchElementException > -- > > Key: IGNITE-11691 > URL: https://issues.apache.org/jira/browse/IGNITE-11691 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails > The issue is caused by an incorrect test: test iterator should pass only > instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11386) Web console: Actualize configuragion for localEventListeners field of IgniteConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11386: -- Fix Version/s: 2.8 > Web console: Actualize configuragion for localEventListeners field of > IgniteConfiguration > - > > Key: IGNITE-11386 > URL: https://issues.apache.org/jira/browse/IGNITE-11386 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Missed field in configurator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
[ https://issues.apache.org/jira/browse/IGNITE-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-11691: - Assignee: Alexey Goncharuk > IgniteWalSerializerVersionTest fails in master with NoSuchElementException > -- > > Key: IGNITE-11691 > URL: https://issues.apache.org/jira/browse/IGNITE-11691 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails > The issue is caused by an incorrect test: test iterator should pass only > instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
[ https://issues.apache.org/jira/browse/IGNITE-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11691: -- Fix Version/s: 2.8 > IgniteWalSerializerVersionTest fails in master with NoSuchElementException > -- > > Key: IGNITE-11691 > URL: https://issues.apache.org/jira/browse/IGNITE-11691 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails > The issue is caused by an incorrect test: test iterator should pass only > instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11525) .NET: Deprecate SqlQuery API
[ https://issues.apache.org/jira/browse/IGNITE-11525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-11525: Description: This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Also please remove hidden columns _key, _val from examples. All of this includes: * Thin client and examples * .NET Core examples * LINQPad examples Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 was: This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Also please remove hidden columns _key, _val from examples. All of this includes Thin Client as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 > .NET: Deprecate SqlQuery API > > > Key: IGNITE-11525 > URL: https://issues.apache.org/jira/browse/IGNITE-11525 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Reporter: Taras Ledkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Also please remove hidden columns _key, _val from examples. > All of this includes: > * Thin client and examples > * .NET Core examples > * LINQPad examples > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11525) .NET: Deprecate SqlQuery API
[ https://issues.apache.org/jira/browse/IGNITE-11525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-11525: Summary: .NET: Deprecate SqlQuery API (was: SQL: Deprecate SqlQuery for .NET platform) > .NET: Deprecate SqlQuery API > > > Key: IGNITE-11525 > URL: https://issues.apache.org/jira/browse/IGNITE-11525 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Reporter: Taras Ledkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Also please remove hidden columns _key, _val from examples. > All of this includes Thin Client as well. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11525) SQL: Deprecate SqlQuery for .NET platform
[ https://issues.apache.org/jira/browse/IGNITE-11525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-11525: Labels: .NET (was: ) > SQL: Deprecate SqlQuery for .NET platform > - > > Key: IGNITE-11525 > URL: https://issues.apache.org/jira/browse/IGNITE-11525 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Reporter: Taras Ledkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.8 > > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Also please remove hidden columns _key, _val from examples. > All of this includes Thin Client as well. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11683) DistributedMetaStoragePersistentTest#testClientReconnect hangs sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-11683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11683:
---
Fix Version/s: 2.8
> DistributedMetaStoragePersistentTest#testClientReconnect hangs sometimes.
> -
>
> Key: IGNITE-11683
> URL: https://issues.apache.org/jira/browse/IGNITE-11683
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem occurs right after this line:
> {code:java}
> assertTrue(GridTestUtils.waitForCondition(() ->
> metastorage(1).getUpdatesCount() == expUpdatesCnt, 15_000));
> {code}
> Client node might not be fully reconnected yet. Adding following line
> resolves the problem in the particular test:
> {code:java}
> grid(1).cluster().clientReconnectFuture().get();
> {code}
> I don't consider this a proper fix. Stopping the client that hasn't finished
> its reconnect shouldn't result in deadlock. Client node should be stopped
> successfully.
> Stack traces of hanging client node:
> {code:java}
> Thread
> [name="test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%",
> id=823, state=WAITING, blockCnt=60, waitCnt=200]
> Lock [object=java.lang.Object@2a2d45ba, ownerName=null, ownerId=-1]
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at o.a.i.i.util.worker.GridWorker.join(GridWorker.java:243)
> at o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4831)
> at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:815)
> at
> o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1183)
> at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2321)
> at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2269)
> at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2574)
> - locked o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55
> at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537)
> at o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330)
> at o.a.i.Ignition.stop(Ignition.java:223)
> at
> o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1153)
> at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1193)
> at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1174)
> at
> o.a.i.i.processors.metastorage.DistributedMetaStorageTest.after(DistributedMetaStorageTest.java:85)
> at
> o.a.i.i.processors.metastorage.DistributedMetaStoragePersistentTest.after(DistributedMetaStoragePersistentTest.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> {code:java}
> Thread
> [name="exchange-worker-#893%metastorage.DistributedMetaStoragePersistentTest1%",
> id=1088, state=BLOCKED, blockCnt=2, waitCnt=2] Lock
> [object=o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55,
> ownerName=test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%,
> ownerId=823] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545) at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537) at
> o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330) at
> o.a.i.Ignition.stop(Ignition.java:223) at
> o.a.i.i.IgniteKernal.close(IgniteKernal.java:3626) at
> o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4086) at
> o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4066) at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
[jira] [Updated] (IGNITE-11385) Web console: Actualize configuragion for failureHandler field of IgniteConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11385: -- Fix Version/s: 2.8 > Web console: Actualize configuragion for failureHandler field of > IgniteConfiguration > > > Key: IGNITE-11385 > URL: https://issues.apache.org/jira/browse/IGNITE-11385 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Missed in configurator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11387) Web console: Actualize configuragion for encryptionSpi field of IgniteConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11387: -- Fix Version/s: 2.8 > Web console: Actualize configuragion for encryptionSpi field of > IgniteConfiguration > --- > > Key: IGNITE-11387 > URL: https://issues.apache.org/jira/browse/IGNITE-11387 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png > > > Missed in configurator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
Alexey Goncharuk created IGNITE-11691: - Summary: IgniteWalSerializerVersionTest fails in master with NoSuchElementException Key: IGNITE-11691 URL: https://issues.apache.org/jira/browse/IGNITE-11691 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails The issue is caused by an incorrect test: test iterator should pass only instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11439) MVCC: Error in transaction mode validation.
[
https://issues.apache.org/jira/browse/IGNITE-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810835#comment-16810835
]
Ignite TC Bot commented on IGNITE-11439:
{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=3506829buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Error in transaction mode validation.
> ---
>
> Key: IGNITE-11439
> URL: https://issues.apache.org/jira/browse/IGNITE-11439
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.8
>
> Attachments: Reproducer
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently MVCC transaction mode is validated within {{MvccUtils#tx()}}
> method. If this method is called during execution of {{OPTIMISTIC}}
> transaction over non-mvcc cache it can cause {{UnsupportedTxModeException}}
> in the case when at least one mvcc cache is also started in the cluster. This
> happens due to improper use of {{MvccUtils#mvccEnabled}} method which returns
> {{true}} if at least one mvcc cache is started. This is a global
> {{mvccEnabled}} flag, but not a per-cache one.
> A very common pattern of using the combination of these two methods is
> completely wrong:
> {code:java}
> if (MvccUtils.mvccEnabled(kernalCtx)) <- global check of enabled mvcc
> tx = MvccUtils#tx(kernalCtx) <- an attempt to get a transaction with
> wrong assumption of enabled mvcc. Exception is thrown here.
> {code}
> We need to revise mvcc transaction mode validation and using these methods in
> the project. All possible scenarios should be covered by tests.
> See reproducer in attachment. Error stacktrace is below:
> {noformat}
> class
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils$UnsupportedTxModeException:
> Only pessimistic transactions are supported when MVCC is enabled.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.tx(MvccUtils.java:717)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.tx(MvccUtils.java:696)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:488)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:1102)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iter(QueryCursorImpl.java:102)
> at
> org.apache.ignite.internal.processors.cache.query.RegisteredQueryCursor.iter(RegisteredQueryCursor.java:64)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:121)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccSqlTxModesTest.testConsequentMvccNonMvccOperations(CacheMvccSqlTxModesTest.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2049)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading
Alexandr Shapkin created IGNITE-11690:
-
Summary: .NET: Cache iteration hangs with enabled
peerAssemblyLoading
Key: IGNITE-11690
URL: https://issues.apache.org/jira/browse/IGNITE-11690
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
Solution to reproduce:
[https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0]
Given:
* 2 server .NET nodes with PeerAssembly = enabled
* Simple custom type cache with a few records
{code:java}
ignite.GetOrCreateCache(new CacheConfiguration(Hotel.Cache, new
QueryEntity(typeof(Guid), typeof(Hotel;
{code}
* 1 Client node that spawn computation task and performs a simple iteration
over cache
{code:java}
class HelloAction : IComputeAction
{
[InstanceResource]
private IIgnite _ignite;
public void Invoke()
{
var hotels = _ignite.GetCache("SomeName").ToList()
}
}
{code}
Problem:
One of the server nodes successfully performs the computation, but the other
getting locked inside the
{code:java}
AssemblyRequestResult ComputeApplySafe(ICompute compute, GetAssemblyFunc func,
AssemblyRequest req)
{code}
When I disable PeerAssembly then all is getting back to normal
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11689) Additional log info about initiator node in case of RingMessageWorker#processNodeFailedMessage.
Stanilovsky Evgeny created IGNITE-11689:
---
Summary: Additional log info about initiator node in case of
RingMessageWorker#processNodeFailedMessage.
Key: IGNITE-11689
URL: https://issues.apache.org/jira/browse/IGNITE-11689
Project: Ignite
Issue Type: Bug
Components: messaging
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
Need to have opportunity to get
{code:java}
TcpDiscoveryNodeFailedMessage{code}
message initiator node info.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11687:
--
Ignite Flags: (was: Docs Required)
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11687:
--
Fix Version/s: 2.8
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11687:
--
Priority: Critical (was: Major)
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11683) DistributedMetaStoragePersistentTest#testClientReconnect hangs sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-11683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11683:
---
Description:
The problem occurs right after this line:
{code:java}
assertTrue(GridTestUtils.waitForCondition(() ->
metastorage(1).getUpdatesCount() == expUpdatesCnt, 15_000));
{code}
Client node might not be fully reconnected yet. Adding following line resolves
the problem in the particular test:
{code:java}
grid(1).cluster().clientReconnectFuture().get();
{code}
I don't consider this a proper fix. Stopping the client that hasn't finished
its reconnect shouldn't result in deadlock. Client node should be stopped
successfully.
Stack traces of hanging client node:
{code:java}
Thread
[name="test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%",
id=823, state=WAITING, blockCnt=60, waitCnt=200]
Lock [object=java.lang.Object@2a2d45ba, ownerName=null, ownerId=-1]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at o.a.i.i.util.worker.GridWorker.join(GridWorker.java:243)
at o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4831)
at
o.a.i.i.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:815)
at
o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
at
o.a.i.i.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1183)
at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2321)
at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2269)
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2574)
- locked o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537)
at o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330)
at o.a.i.Ignition.stop(Ignition.java:223)
at
o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1153)
at
o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1193)
at
o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1174)
at
o.a.i.i.processors.metastorage.DistributedMetaStorageTest.after(DistributedMetaStorageTest.java:85)
at
o.a.i.i.processors.metastorage.DistributedMetaStoragePersistentTest.after(DistributedMetaStoragePersistentTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
Thread
[name="exchange-worker-#893%metastorage.DistributedMetaStoragePersistentTest1%",
id=1088, state=BLOCKED, blockCnt=2, waitCnt=2] Lock
[object=o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55,
ownerName=test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%,
ownerId=823] at
o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545) at
o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537) at
o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330) at
o.a.i.Ignition.stop(Ignition.java:223) at
o.a.i.i.IgniteKernal.close(IgniteKernal.java:3626) at
o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4086) at
o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4066) at
o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478) at
o.a.i.i.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:125) at
o.a.i.i.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45) at
o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478) at
[jira] [Updated] (IGNITE-11683) DistributedMetaStoragePersistentTest#testClientReconnect hangs sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-11683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11683:
---
Description:
The problem occurs right after this line:
{code:java}
assertTrue(GridTestUtils.waitForCondition(() ->
metastorage(1).getUpdatesCount() == expUpdatesCnt, 15_000));
{code}
Client node might not be fully reconnected yet. Adding following line resolves
the problem in the particular test:
{code:java}
grid(1).cluster().clientReconnectFuture().get();
{code}
I don't consider this a proper fix. Stopping the client that hasn't finished
its reconnect shouldn't result in deadlock. Client node should be stopped
successfully.
Stack traces of hanging client node:
{code:java}
Thread
[name="test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%",
id=823, state=WAITING, blockCnt=60, waitCnt=200]
Lock [object=java.lang.Object@2a2d45ba, ownerName=null, ownerId=-1]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at o.a.i.i.util.worker.GridWorker.join(GridWorker.java:243)
at o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4831)
at
o.a.i.i.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:815)
at
o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
at
o.a.i.i.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1183)
at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2321)
at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2269)
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2574)
- locked o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537)
at o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330)
at o.a.i.Ignition.stop(Ignition.java:223)
at
o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1153)
at
o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1193)
at
o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1174)
at
o.a.i.i.processors.metastorage.DistributedMetaStorageTest.after(DistributedMetaStorageTest.java:85)
at
o.a.i.i.processors.metastorage.DistributedMetaStoragePersistentTest.after(DistributedMetaStoragePersistentTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
Thread
[name="exchange-worker-#893%metastorage.DistributedMetaStoragePersistentTest1%",
id=1088, state=BLOCKED, blockCnt=2, waitCnt=2] Lock
[object=o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55,
ownerName=test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%,
ownerId=823] at
o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545) at
o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537) at
o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330) at
o.a.i.Ignition.stop(Ignition.java:223) at
o.a.i.i.IgniteKernal.close(IgniteKernal.java:3626) at
o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4086) at
o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4066) at
o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478) at
o.a.i.i.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:125) at
o.a.i.i.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45) at
o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478) at
[jira] [Updated] (IGNITE-11683) DistributedMetaStoragePersistentTest#testClientReconnect hangs sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-11683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11683:
---
Description:
The problem occurs right after this line:
{code:java}
assertTrue(GridTestUtils.waitForCondition(() ->
metastorage(1).getUpdatesCount() == expUpdatesCnt, 15_000));
{code}
Client node might not be fully reconnected yet. Adding following line resolves
the problem in the particular test:
{code:java}
grid(1).cluster().clientReconnectFuture().get();
{code}
I don't consider this a proper fix. Stopping the client that hasn't finished
its reconnect shouldn't result in deadlock. Client node should be stopped
successfully.
Stack traces of hanging client node:
{code:java}
Thread
[name="test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%",
id=823, state=WAITING, blockCnt=60, waitCnt=200]
Lock [object=java.lang.Object@2a2d45ba, ownerName=null, ownerId=-1]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at o.a.i.i.util.worker.GridWorker.join(GridWorker.java:243)
at o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4831)
at
o.a.i.i.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:815)
at
o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
at
o.a.i.i.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1183)
at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2321)
at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2269)
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2574)
- locked o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537)
at o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330)
at o.a.i.Ignition.stop(Ignition.java:223)
at
o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1153)
at
o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1193)
at
o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1174)
at
o.a.i.i.processors.metastorage.DistributedMetaStorageTest.after(DistributedMetaStorageTest.java:85)
at
o.a.i.i.processors.metastorage.DistributedMetaStoragePersistentTest.after(DistributedMetaStoragePersistentTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
Thread
[name="exchange-worker-#893%metastorage.DistributedMetaStoragePersistentTest1%",
id=1088, state=BLOCKED, blockCnt=2, waitCnt=2] Lock
[object=o.a.i.i.IgnitionEx$IgniteNamedInstance@69d9c55,
ownerName=test-runner-#673%metastorage.DistributedMetaStoragePersistentTest%,
ownerId=823] at
o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545) at
o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537) at
o.a.i.i.IgnitionEx.stop(IgnitionEx.java:330) at
o.a.i.Ignition.stop(Ignition.java:223) at
o.a.i.i.IgniteKernal.close(IgniteKernal.java:3626) at
o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4086) at
o.a.i.i.IgniteKernal$5.apply(IgniteKernal.java:4066) at
o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478) at
o.a.i.i.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:125) at
o.a.i.i.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45) at
o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490) at
o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478) at
[jira] [Commented] (IGNITE-8856) Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard for type names
[
https://issues.apache.org/jira/browse/IGNITE-8856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810781#comment-16810781
]
Vyacheslav Koptilin commented on IGNITE-8856:
-
TC looks good to me. {{IgniteBasicTestSuite:
StopNodeOrHaltFailureHandlerTest.testJvmHalted}} failure is not caused by the
proposed change.
> Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard for
> type names
>
>
> Key: IGNITE-8856
> URL: https://issues.apache.org/jira/browse/IGNITE-8856
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following BinaryConfiguration:
> {code:java}
>
>
> ...
>
>
> class="org.apache.ignite.binary.BinaryTypeConfiguration">
> value="org.apache.ignite.examples.*"/>
>
> class="org.apache.ignite.binary.BinaryBasicNameMapper">
> value="false"/>
>
>
>
>
>
>
>
> {code}
> My intention is using custom BinaryBasicMapper for all classes in the
> specified package and its sub packages,
> but BinaryContext implementation matches only classes that reside in the
> "org.apache.ignite.examples" package.
> Classes from sub-packages are not matched, and therefore do not use the
> specified BinaryBasicNameMapper.
> *UPD:*
> Well, it seems that the current behavior is not an error and was implemented
> in this way intentionally.
> On the other hand, I think it would be good to have the ability to specify
> sub-packages as well.
> For example, it can be achieved through the '**' pattern as follows:
> ||example||defenition||priority||
> |org.apache.ignite.examples.TestClass|matches exactly the one class|the
> highest priority|
> |org.apache.ignite.examples.*|matches all classes in the given package|medium|
> |org.apache.ignite.examples.**|matches all classes in the given package and
> its sub-packages|low|
> The proposed enhancement does not break the current behavior and allows to
> specify a filter for sub-packages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8856) Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard for type names
[
https://issues.apache.org/jira/browse/IGNITE-8856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-8856:
Description:
Let's consider the following BinaryConfiguration:
{code:java}
...
{code}
My intention is using custom BinaryBasicMapper for all classes in the specified
package and its sub packages,
but BinaryContext implementation matches only classes that reside in the
"org.apache.ignite.examples" package.
Classes from sub-packages are not matched, and therefore do not use the
specified BinaryBasicNameMapper.
*UPD:*
Well, it seems that the current behavior is not an error and was implemented in
this way intentionally.
On the other hand, I think it would be good to have the ability to specify
sub-packages as well.
For example, it can be achieved through the '**' pattern as follows:
||example||defenition||priority||
|org.apache.ignite.examples.TestClass|matches exactly the one class|the highest
priority|
|org.apache.ignite.examples.*|matches all classes in the given package|medium|
|org.apache.ignite.examples.**|matches all classes in the given package and its
sub-packages|low|
The proposed enhancement does not break the current behavior and allows to
specify a filter for sub-packages.
was:
Let's consider the following BinaryConfiguration:
{code:java}
...
{code}
My intention is using custom BinaryBasicMapper for all classes in the specified
package and its sub packages,
but BinaryContext implementation matches only classes that reside in the
"org.apache.ignite.examples" package.
Classes from subpackages are not matched, and therefore do not use the
specified BinaryBasicNameMapper.
> Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard for
> type names
>
>
> Key: IGNITE-8856
> URL: https://issues.apache.org/jira/browse/IGNITE-8856
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following BinaryConfiguration:
> {code:java}
>
>
> ...
>
>
> class="org.apache.ignite.binary.BinaryTypeConfiguration">
> value="org.apache.ignite.examples.*"/>
>
> class="org.apache.ignite.binary.BinaryBasicNameMapper">
> value="false"/>
>
>
>
>
>
>
>
> {code}
> My intention is using custom BinaryBasicMapper for all classes in the
> specified package and its sub packages,
> but BinaryContext implementation matches only classes that reside in the
> "org.apache.ignite.examples" package.
> Classes from sub-packages are not matched, and therefore do not use the
> specified BinaryBasicNameMapper.
> *UPD:*
> Well, it seems that the current behavior is not an error and was implemented
> in this way intentionally.
> On the other hand, I think it would be good to have the ability to specify
> sub-packages as well.
> For example, it can be achieved through the '**' pattern as follows:
> ||example||defenition||priority||
> |org.apache.ignite.examples.TestClass|matches exactly the one class|the
> highest priority|
> |org.apache.ignite.examples.*|matches all classes in the given package|medium|
> |org.apache.ignite.examples.**|matches all classes in the given package and
> its sub-packages|low|
> The proposed enhancement does not break the current behavior and allows to
> specify a filter for sub-packages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11361) Web console: Actualize grid configurator IgniteConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11361: -- Fix Version/s: 2.8 > Web console: Actualize grid configurator IgniteConfiguration > > > Key: IGNITE-11361 > URL: https://issues.apache.org/jira/browse/IGNITE-11361 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: image-2019-03-21-13-10-03-170.png, screenshot-1.png > > > Result for class: org.apache.ignite.configuration.IgniteConfiguration > Missed > failureHandler IGNITE-11385 > authenticationEnabled > autoActivationEnabled > sqlQueryHistorySize > lifecycleBeans > sqlSchemas > igniteInstanceName > addressResolver > igniteHome > localEventListeners IGNITE-11386 > mBeanServer > networkCompressionLevel > communicationFailureResolver > systemWorkerBlockedTimeout > platformConfiguration > includeProperties > cacheStoreSessionListenerFactories > encryptionSpi IGNITE-11387 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810768#comment-16810768
]
Ignite TC Bot commented on IGNITE-11588:
{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=3505716buildTypeId=IgniteTests24Java8_RunAll]
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11688) [TC Bot] Add more configuration options for VISA
[ https://issues.apache.org/jira/browse/IGNITE-11688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11688: Ignite Flags: (was: Docs Required) > [TC Bot] Add more configuration options for VISA > > > Key: IGNITE-11688 > URL: https://issues.apache.org/jira/browse/IGNITE-11688 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Minor > > - project > - default tracked branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11688) [TC Bot] Add more configuration options for VISA
Dmitriy Pavlov created IGNITE-11688: --- Summary: [TC Bot] Add more configuration options for VISA Key: IGNITE-11688 URL: https://issues.apache.org/jira/browse/IGNITE-11688 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov - project - default tracked branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11687:
--
Description:
The cause is the way {{end}} is calculated for WAL iterator:
{code}
if (hnd != null)
end = hnd.position();
{code}
{code}
@Override public FileWALPointer position() {
lock.lock();
try {
return new FileWALPointer(getSegmentId(), (int)written, 0);
}
finally {
lock.unlock();
}
}
{code}
Consider a partially written entry. In this case, {{written}} has been already
updated, concurrent WAL replay will attempt to read the incompletely written
record and since {{end}} is not null, iterator will fail with CRC error.
The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
was:
The cause is the way {{end}} is calculated for WAL iterator:
{code}
if (hnd != null)
end = hnd.position();
{code}
{code}
@Override public FileWALPointer position() {
lock.lock();
try {
return new FileWALPointer(getSegmentId(), (int)written, 0);
}
finally {
lock.unlock();
}
}
{code}
Consider a partially written entry. In this case, {{written}} has been already
updated, concurrent WAL replay will attempt to read the incompletely written
record and since {{end}} is not null, iterator will fail with CRC error.
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810748#comment-16810748
]
Alexey Goncharuk commented on IGNITE-11687:
---
I believe this was broken long ago when {{SegmentedRingByteBuffer}} was
introduced. In WAL manager we have the following code:
{code}
hdl.written += hdl.fileIO.writeFully(buf);
{code}
which appears to write a fully serialized batch of records, however, this may
be not the case when ring byte buffer returns a list of buffers to write.
At the first glance, it should be enough to update {{written}} field after all
buffers polled from the ring are written in {{WALWriter}}. [~agura], what do
you think?
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
Alexey Goncharuk created IGNITE-11687:
-
Summary: Concurrent WAL replay & log may fail with CRC error on
read
Key: IGNITE-11687
URL: https://issues.apache.org/jira/browse/IGNITE-11687
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
The cause is the way {{end}} is calculated for WAL iterator:
{code}
if (hnd != null)
end = hnd.position();
{code}
{code}
@Override public FileWALPointer position() {
lock.lock();
try {
return new FileWALPointer(getSegmentId(), (int)written, 0);
}
finally {
lock.unlock();
}
}
{code}
Consider a partially written entry. In this case, {{written}} has been already
updated, concurrent WAL replay will attempt to read the incompletely written
record and since {{end}} is not null, iterator will fail with CRC error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, atomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11354: -- Component/s: wizards > Web console: Actualize grid configurator discovery, store, atomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: image-2019-03-20-13-15-22-387.png > > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, atomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11354: -- Fix Version/s: 2.8 > Web console: Actualize grid configurator discovery, store, atomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: image-2019-03-20-13-15-22-387.png > > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-5221) Investigate possibility of integrating with dl4j
[ https://issues.apache.org/jira/browse/IGNITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Malykh reopened IGNITE-5221: -- Assignee: Artem Malykh (was: Yury Babak) I suggest I continue my investigation for developers wanting to use Deep Learning on JVM. > Investigate possibility of integrating with dl4j > > > Key: IGNITE-5221 > URL: https://issues.apache.org/jira/browse/IGNITE-5221 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.1 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.7 > > > Investigate if there is an easy possibility for integration of apache ignite > with dl4j. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11283) Web console: Actualize grid configuration. Check deprecated fields
[ https://issues.apache.org/jira/browse/IGNITE-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11283: -- Fix Version/s: 2.8 > Web console: Actualize grid configuration. Check deprecated fields > -- > > Key: IGNITE-11283 > URL: https://issues.apache.org/jira/browse/IGNITE-11283 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png > > > Result for class: > org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction > Deprecated > backupFilter > Result for class: org.apache.ignite.configuration.PersistentStoreConfiguration > Deprecated > walBufferSize > writeThrottlingEnabled > checkpointWriteOrder > fileIOFactory > walMode > walAutoArchiveAfterInactivity > Result for class: org.apache.ignite.configuration.TransactionConfiguration > Missed > deadlockTimeout > useJtaSynchronization > txTimeoutOnPartitionMapExchange > Deprecated > txSerializableEnabled > txManagerLookupClassName > Result for class: org.apache.ignite.configuration.ConnectorConfiguration > Deprecated > sslContextFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810663#comment-16810663 ] Alexey Goncharuk commented on IGNITE-11614: --- Scala failure seems not to be related to this change. > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[
https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810661#comment-16810661
]
Ignite TC Bot commented on IGNITE-11614:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3514598]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3504059buildTypeId=IgniteTests24Java8_RunAll]
> Transaction with timeout on cache hangs after cache store failure
> -
>
> Key: IGNITE-11614
> URL: https://issues.apache.org/jira/browse/IGNITE-11614
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Anton Kurbanov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: CacheStoreTxPutAllMultiNodeTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If CacheStore fails before/during transaction commit, transaction with set
> timeout remains active.
> Setting cfg.setTransactionConfiguration(new
> TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes
> the issue in test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11686) MVCC: Create separate test for vacuum checks.
Andrew Mashenkov created IGNITE-11686: - Summary: MVCC: Create separate test for vacuum checks. Key: IGNITE-11686 URL: https://issues.apache.org/jira/browse/IGNITE-11686 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Most of tests (inherited from CacheMvccAbstractTest) run vacuum synchronously on afterTest() method and check if vacuum is ok. This hits performance, can cause false negative results and vacuum issues can be hidden if afterTest method will overriden at once. For now we have CacheMvccVacuumTest that just check vacuum workers state, but there is no check if vacuum really cleans all old versions correctly. I'd expect to find it in this class. So, let's mode vacuum verification from afterTest method into CacheMvccVacuumTest as a new separate test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810608#comment-16810608
]
Ignite TC Bot commented on IGNITE-10344:
{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=3506186buildTypeId=IgniteTests24Java8_RunAll]
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11489) merge IO message listener for GridTopic.TOPIC_QUERY into single listener
[
https://issues.apache.org/jira/browse/IGNITE-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810607#comment-16810607
]
Ignite TC Bot commented on IGNITE-11489:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3506441]]
* ZookeeperDiscoverySpiTestSuite2:
GridCachePartitionedNodeRestartTest.testRestartWithPutEightNodesTwoBackups -
0,0% fails in last 325 master runs.
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3507434]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3505297buildTypeId=IgniteTests24Java8_RunAll]
> merge IO message listener for GridTopic.TOPIC_QUERY into single listener
>
>
> Key: IGNITE-11489
> URL: https://issues.apache.org/jira/browse/IGNITE-11489
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now we have few IO listeners for GridTopic.TOPIC_QUERY. It lead to
> spread of logic and we can't check that no any not expected messages received.
> Need to merge it to single listeners or have different topics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810602#comment-16810602
]
Ignite TC Bot commented on IGNITE-11588:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3505627]]
* GridServiceInjectionSpringResourceTest.testDeployServiceWithSpring (last
started)
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3505642]]
{color:#d04437}PDS 4{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3505685]]
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCachesInDifferentCacheGroupsFirstGroup
- 0,0% fails in last 334 master runs.
* IgnitePdsTestSuite4: ResetLostPartitionTest.testResetLostPartitions - 0,0%
fails in last 334 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3505716buildTypeId=IgniteTests24Java8_RunAll]
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-5714: - Assignee: Aleksey Plekhanov (was: Nikolay Izhikov) > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Aleksey Plekhanov >Priority: Major > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
Aleksey Plekhanov created IGNITE-11685:
--
Summary: Java thin client: Handle multiple async requests in
parallel
Key: IGNITE-11685
URL: https://issues.apache.org/jira/browse/IGNITE-11685
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Aleksey Plekhanov
In the current implementation {{ReliableChannel}} uses an exclusive lock to
send a request and waits for response synchronously. In this implementation,
there are no benefits of using multiple threads. To improve throughput and
latency we can implement async request/response processing on the client side,
since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810568#comment-16810568
]
Vladimir Ozerov commented on IGNITE-11434:
--
[~tledkov-gridgain], I don't know. If we fail to get it right, then let's not
implement this column at all.
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_NAME | string | Column name |
> | ORDINAL_POSITION | int | Column ordinal. Starts with 1 |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | DATA_TYPE | string | SQL data type |
> | CHARACTER_LENGTH | int | Size for char CAHR and VARCHAR types |
> | NUMERIC_PRECISION | int | Precision for numeric types |
> | NUMERIC_SCALE | int | Scale for numeric types |
> | IS_AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> | IS_HIDDEN | boolean | {{true}} for hidden _ley nad _val columns. {{false}}
> for all columns available by asterisk mask |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11397) Binary mode for Ignite Set
[
https://issues.apache.org/jira/browse/IGNITE-11397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806530#comment-16806530
]
Ivan Bessonov edited comment on IGNITE-11397 at 4/5/19 6:56 AM:
Hello [~uday], thank you for the contribution! I'd like to discuss few things
here.
First of all, these tests failures look very suspicious, at least in "Data
Structures" suite. Please take a look at them.
Now more specific. In modified abstract test you have this line:
{code:java}
private static final boolean BINARY_SET_MODE =
IgniteSystemProperties.getBoolean(BINARY_SET, true);{code}
You set "true" as a default value and you also set "true" in suite. I can't
find a place where you would use "false" as a value for this property, please
correct that.
{code:java}
public IgniteSet withKeepBinary();{code}
I understand where this type of method signature is coming from, but I'd like
to be sure that it's correct. There are two implementations of this method and
they have following lines in them:
{code:java}
return new GridCacheSetProxy<>(ctx, (GridCacheSetImpl)this);{code}
{code:java}
return new GridCacheSetProxy<>(cctx, (GridCacheSetImpl)delegate);{code}
Both "this" and "delegate" are instances of "IgniteSet" so why do we need a
new type "V1" that is not even bound with anything? Looks problematic to say
the least. On the other hand, actual type when operating these sets is most
likely a "BinaryObject". If it is then we could reflect this fact in method
signature so it won't be overly complicated.
Finally, you mishandled "CacheOperationContext". Please take a look at
"GatewayProtectedCacheProxy" class and usages of "operationContextPerCall"
method. What you actually need is to have "opCtx" field in "GridCacheSetProxy"
and pass it into the gate. Please don't forget to restore previous values on
leaving the gate, like, for example, in
"GatewayProtectedCacheProxy.CacheOperationGate" class usages.
Here is the simple reproducer for the problem. It doesn't cover all the aspects
but is enough for the start:
{code:java}
@Test
public void testGet() throws Exception {
IgniteEx ignite = grid(0);
IgniteQueue queue = ignite.queue("q0", 10,
config(false)).withKeepBinary();
queue.add(sameHashBinObj(ignite, 0));
queue.add(sameHashBinObj(ignite, 1));
BinaryObject o0 = queue.poll(); // Ok.
BinaryObject o1 =
GridTestUtils.runAsync((Callable)queue::poll).get(); // Fails.
}
private static BinaryObject sameHashBinObj(Ignite ignite, int i) {
return ignite.binary().toBinary(new SameHashItem(Integer.toString(i)));
}
{code}
You probably noticed that this test operates with "IgniteQueue". It has all the
same issues so they can be reproduced in master. I would appreciate if you
created another issue to fix these bugs in "IgniteQueue" after we finish
"IgniteSet" improvements.
Please feel free asking me more questions if you have some. Thank you!
EDIT:
I feel like I didn't explain that last problem detailed enough so I'll do it
just in case.
"operationContextPerCall" is a thread-local entity used for cache operations.
It is set before any specific cache operation (get / put / ...) and cleared
after. This way cache has the ability to read all specific settings and work as
desired. More specifically - it allows having both "keepBinary" and "not
keepBinary" data structures on the same cache in the same thread.
In current implementation of queue and suggested implementation of set you
don't use "operationContextPerCall" in the expected way (try/finally around
specific operations) but rather just set it in the moment of creation. All
queues and sets become "keepBinary" structures in current thread but remain
"not keepBinary" in other (unless those threads are not broken like the current
one). This is the exact scenario that I provided in my test (loosely based on
your test from [this
comment|https://issues.apache.org/jira/browse/IGNITE-9532?focusedCommentId=16618631=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16618631]).
was (Author: ibessonov):
Hello [~uday], thank you for the contribution! I'd like to discuss few things
here.
First of all, these tests failures look very suspicious, at least in "Data
Structures" suite. Please take a look at them.
Now more specific. In modified abstract test you have this line:
{code:java}
private static final boolean BINARY_SET_MODE =
IgniteSystemProperties.getBoolean(BINARY_SET, true);{code}
You set "true" as a default value and you also set "true" in suite. I can't
find a place where you would use "false" as a value for this property, please
correct that.
{code:java}
public IgniteSet withKeepBinary();{code}
I understand where this type of method signature is coming from, but I'd like
to be sure that it's correct. There are two implementations of this method and
they have following
[jira] [Updated] (IGNITE-11182) Web console: Actualize grid configurator
[ https://issues.apache.org/jira/browse/IGNITE-11182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11182: -- Fix Version/s: 2.8 > Web console: Actualize grid configurator > > > Key: IGNITE-11182 > URL: https://issues.apache.org/jira/browse/IGNITE-11182 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > WebConsoleConfigurationSelfTest has found the next difference: > Result for class: org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory > Missed > userNameMapper > Result for class: org.apache.ignite.ssl.SslContextFactory > Missed > cipherSuites > protocols > Result for class: org.apache.ignite.configuration.CacheConfiguration > Missed > cacheWriterFactory > expiryPolicyFactory > storeConcurrentLoadAllThreshold > sqlIndexMaxInlineSize > sqlOnheapCacheEnabled > interceptor > invalidate > diskPageCompression > storeByValue > sqlOnheapCacheMaxSize > eagerTtl > evictionPolicyFactory > encryptionEnabled > eventsDisabled > cacheLoaderFactory > keyConfiguration > cacheStoreSessionListenerFactories > diskPageCompressionLevel > maxQueryIteratorsCount > affinity > Deprecated > rebalanceThreadPoolSize > transactionManagerLookupClassName > Removed > isInvalidate -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11182) Web console: Actualize grid configurator
[ https://issues.apache.org/jira/browse/IGNITE-11182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11182: -- Component/s: wizards > Web console: Actualize grid configurator > > > Key: IGNITE-11182 > URL: https://issues.apache.org/jira/browse/IGNITE-11182 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > WebConsoleConfigurationSelfTest has found the next difference: > Result for class: org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory > Missed > userNameMapper > Result for class: org.apache.ignite.ssl.SslContextFactory > Missed > cipherSuites > protocols > Result for class: org.apache.ignite.configuration.CacheConfiguration > Missed > cacheWriterFactory > expiryPolicyFactory > storeConcurrentLoadAllThreshold > sqlIndexMaxInlineSize > sqlOnheapCacheEnabled > interceptor > invalidate > diskPageCompression > storeByValue > sqlOnheapCacheMaxSize > eagerTtl > evictionPolicyFactory > encryptionEnabled > eventsDisabled > cacheLoaderFactory > keyConfiguration > cacheStoreSessionListenerFactories > diskPageCompressionLevel > maxQueryIteratorsCount > affinity > Deprecated > rebalanceThreadPoolSize > transactionManagerLookupClassName > Removed > isInvalidate -- This message was sent by Atlassian JIRA (v7.6.3#76005)
