[jira] [Commented] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314024#comment-17314024 ] Denis A. Magda commented on IGNITE-14398: - [~PetrovMikhail] we can say that "replace the ignite-spring-data-ext.version parameter with a version of the extension that corresponds to your version of Ignite. The version is "1.0.0" for Ignite 2.10.0 and earlier versions. See this table for a complete matching of the versions". The table that matches the versions can be under a separate section on this page or we can point out to some page on the Maven Central website. [~nsafonov] please share your inputs as well. > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314004#comment-17314004 ] Mikhail Petrov commented on IGNITE-14398: - [~dmagda] ^ > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314003#comment-17314003 ] Mikhail Petrov commented on IGNITE-14398: - Yes, it's the first time we are releasing this extension and it has not been released yet. And nothing has changed with backward compatibility of the Spring Data module compare to one included in 2.9. So is it enough to just replace ignite-spring-data-ext.version with 1.0.0? > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14398) Document thin client support for spring-data integration.
[
https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313973#comment-17313973
]
Denis A. Magda commented on IGNITE-14398:
-
[~PetrovMikhail] [~nsafonov]
Check the pull request and see that we're suggesting replacing the following
occurrence ${ignite-spring-data-ext.version} with an actual version. Where the
reader can find the actual version? There needs to be some section that matches
an Ignite version to a compatible version of the extensions.
> Document thin client support for spring-data integration.
> -
>
> Key: IGNITE-14398
> URL: https://issues.apache.org/jira/browse/IGNITE-14398
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> It's needed to document thin client support for spring-data integration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14402) Java Thin: Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-14402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313956#comment-17313956 ] Pavel Tupitsyn commented on IGNITE-14402: - [~alex_pl] please see my comments on GitHub > Java Thin: Continuous Query > --- > > Key: IGNITE-14402 > URL: https://issues.apache.org/jira/browse/IGNITE-14402 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-50 > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement Continuous Query API in Java Thin Client. > See .NET Thin Client as a reference: IGNITE-13148 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14460) Implement RAFT server stub
[ https://issues.apache.org/jira/browse/IGNITE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14460: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Implement RAFT server stub > -- > > Key: IGNITE-14460 > URL: https://issues.apache.org/jira/browse/IGNITE-14460 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > We need a raft server implementation stub to unlock further development of > dependent services. > In the simplest approach we will have a single node raft groups, so no > consensus is required. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14402) Java Thin: Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-14402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-14402: --- Assignee: Aleksey Plekhanov (was: Pavel Tupitsyn) > Java Thin: Continuous Query > --- > > Key: IGNITE-14402 > URL: https://issues.apache.org/jira/browse/IGNITE-14402 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-50 > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement Continuous Query API in Java Thin Client. > See .NET Thin Client as a reference: IGNITE-13148 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14439) NPE when accessing clustername before first exchange finished
[ https://issues.apache.org/jira/browse/IGNITE-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-14439: - Release Note: Fixed potential NullPointerException on client node startup > NPE when accessing clustername before first exchange finished > - > > Key: IGNITE-14439 > URL: https://issues.apache.org/jira/browse/IGNITE-14439 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not > been fixed properly for two reasons. The first is one is that > _GridCacheProcessor.utilityCache_ could be accessed before the first exchange > finished. The second is that it doesn't resolve the original issue, because > _GridServiceProcessor.onKernelStop_ is followed by > _GridCacheProcessor.onKernelStop_, so caches should be already initialized. > Thus that fix should be reverted. > Revering this fix induces the issue related to accessing the utility cache by > getting cluster name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14439) NPE when accessing clustername before first exchange finished
[ https://issues.apache.org/jira/browse/IGNITE-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-14439: - Ignite Flags: (was: Docs Required,Release Notes Required) > NPE when accessing clustername before first exchange finished > - > > Key: IGNITE-14439 > URL: https://issues.apache.org/jira/browse/IGNITE-14439 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not > been fixed properly for two reasons. The first is one is that > _GridCacheProcessor.utilityCache_ could be accessed before the first exchange > finished. The second is that it doesn't resolve the original issue, because > _GridServiceProcessor.onKernelStop_ is followed by > _GridCacheProcessor.onKernelStop_, so caches should be already initialized. > Thus that fix should be reverted. > Revering this fix induces the issue related to accessing the utility cache by > getting cluster name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13970) [Ducktape: Thin client] Cache API Test
[ https://issues.apache.org/jira/browse/IGNITE-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniya Vdovets updated IGNITE-13970: -- Description: Need to check put/get (atomic, tx) and other cache API works while the user uses TC. +jinja2 based spring configuration. --- Task: create new thin client compatibility test using Ducktape framework Guess thin client interaction is already implemented in Ducktape Input params: Thin client version Server version Test plan: 1. Start the server 2. Start the client 3. Create new cache 4. Main cache operations: put, get, remove was: Need to check put/get (atomic, tx) and other cache API works while the user uses TC. +jinja2 based spring configuration. > [Ducktape: Thin client] Cache API Test > -- > > Key: IGNITE-13970 > URL: https://issues.apache.org/jira/browse/IGNITE-13970 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Evgeniya Vdovets >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Need to check put/get (atomic, tx) and other cache API works while the user > uses TC. > +jinja2 based spring configuration. > --- > Task: create new thin client compatibility test using Ducktape framework > Guess thin client interaction is already implemented in Ducktape > > Input params: > Thin client version > Server version > > Test plan: > 1. Start the server > 2. Start the client > 3. Create new cache > 4. Main cache operations: put, get, remove -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14465) Add the ability to activate the cluster via the Python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313908#comment-17313908 ] Igor Sapego commented on IGNITE-14465: -- [~ivandasch] I've fixed everything you've found. TC pass: https://ci.ignite.apache.org/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/5948839 Please, take another look. > Add the ability to activate the cluster via the Python thin client > -- > > Key: IGNITE-14465 > URL: https://issues.apache.org/jira/browse/IGNITE-14465 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > This feature will be extremely useful when working with clusters that have > the "persistenceEnabled" option. Since they require activation to get > started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14372) Fix REST json configuration update requests
[ https://issues.apache.org/jira/browse/IGNITE-14372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-14372: -- Assignee: Ivan Bessonov > Fix REST json configuration update requests > --- > > Key: IGNITE-14372 > URL: https://issues.apache.org/jira/browse/IGNITE-14372 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14283) Create the Sanity Checks job on TC
[ https://issues.apache.org/jira/browse/IGNITE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313903#comment-17313903 ] Maksim Timonin commented on IGNITE-14283: - [~vveider] hi! thanks for this effort, it is actually what we need. > Create the Sanity Checks job on TC > -- > > Key: IGNITE-14283 > URL: https://issues.apache.org/jira/browse/IGNITE-14283 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Peter Ivanov >Priority: Major > > 1. The [Build] job runs without any checks. > 2. There will be a new job [Sanity Checks], that runs all checks - > checkstyle, licenses, javadoc, check-suites. > 3. [Sanity Checks] runs in parallel with [Build]. > 4. All TC jobs with tests depend on a result of the [Sanity Checks] job. If > the check job fails then a test job won't be started. > 5. Users can disable the [Sanity Checks] job with a selector on the > Parameters tab of custom TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14283) Create the Sanity Checks job on TC
[ https://issues.apache.org/jira/browse/IGNITE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313893#comment-17313893 ] Peter Ivanov commented on IGNITE-14283: --- Added *[Missing Tests]* to *> Build*. Check this build please: https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Build/5948836 > Create the Sanity Checks job on TC > -- > > Key: IGNITE-14283 > URL: https://issues.apache.org/jira/browse/IGNITE-14283 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Peter Ivanov >Priority: Major > > 1. The [Build] job runs without any checks. > 2. There will be a new job [Sanity Checks], that runs all checks - > checkstyle, licenses, javadoc, check-suites. > 3. [Sanity Checks] runs in parallel with [Build]. > 4. All TC jobs with tests depend on a result of the [Sanity Checks] job. If > the check job fails then a test job won't be started. > 5. Users can disable the [Sanity Checks] job with a selector on the > Parameters tab of custom TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13000) Connection.prepareStatement(String,int) always throws UnsupportedException ignoring 'autoGeneratedKeys' parameter
[
https://issues.apache.org/jira/browse/IGNITE-13000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Vinokurov reassigned IGNITE-13000:
Assignee: (was: Pavel Vinokurov)
> Connection.prepareStatement(String,int) always throws UnsupportedException
> ignoring 'autoGeneratedKeys' parameter
> ---
>
> Key: IGNITE-13000
> URL: https://issues.apache.org/jira/browse/IGNITE-13000
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Pavel Vinokurov
>Priority: Major
>
> Below the method call throwing Exception.
> {code:java}
> conn.prepareStatement(query, Statement.NO_GENERATED_KEYS)
> {code}
> But there is should be the same result as for:
> {code:java}
> conn.prepareStatement(query)
> {code}
> The possible fix:
> {code:java}
> @Override
> public PreparedStatement prepareStatement(String sql, int autoGeneratedKeys)
> throws SQLException {
> ensureNotClosed();
> if(autoGeneratedKeys == Statement.RETURN_GENERATED_KEYS)
> throw new SQLFeatureNotSupportedException("Auto generated keys are
> not supported.");
> return prepareStatement(sql);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14301) Authentication processor can hang all user management operation after server node reconnect
[ https://issues.apache.org/jira/browse/IGNITE-14301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313867#comment-17313867 ] Mikhail Petrov commented on IGNITE-14301: - It seems that the https://issues.apache.org/jira/browse/IGNITE-14375 fixes this issue. > Authentication processor can hang all user management operation after server > node reconnect > --- > > Key: IGNITE-14301 > URL: https://issues.apache.org/jira/browse/IGNITE-14301 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > > First for all look at the test - > AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer > which is flaky - [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] > The first problem with this test is that user management > operations(add/update/remove) create too many discovery messages. So > discovery custom message history size is not enough to properly skip > duplicated custom messages that can be sent across the ring during server > node reconnect. It leads to mentioned test failures due to duplication of > user management operations (see GridDiscoveryManager#discoCacheHist, > IGNITE_DISCOVERY_HISTORY_SIZE system property, and > ServerImpl.RingMessageWorker#sendMessageAcrossRing). > If the discovery history size will be increased significantly, the test stops > failing and starts hanging. The steps that lead to this: > 1. Client node sent UserProposedMessage across the ring while one node is > offline due to reconnect. > 2. Alive server nodes update their local user lists and finish the > operation. > 3. Reconnected node joins the ring and receives an updated user list from > the coordinator. > 4. Reconnected node receives duplicated UserProposedMessage that has been > already handled by all nodes, handles it, and sents > UserManagementOperationFinishedMessage to the coordinator and start to wait > for the UserAcceptedMessage from it. But the coordinator has already finished > this operation. So the thread that responsible for user management operation > on the reconnected node becomes blocked (see > IgniteAuthenticationProcessor.UserOperationWorker#body). > 5. Client node starts the next operation that needs all alive nodes to > respond with UserManagementOperationFinishedMessage. But reconnected node > authentication thread is blocked. So this operation can't be completed at all. > This issue causes all tests in the AuthenticationProcessorNodeRestartTest > test class to be flaky. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14439) NPE when accessing clustername before first exchange finished
[ https://issues.apache.org/jira/browse/IGNITE-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313863#comment-17313863 ] Ilya Kasnacheev commented on IGNITE-14439: -- LGTM > NPE when accessing clustername before first exchange finished > - > > Key: IGNITE-14439 > URL: https://issues.apache.org/jira/browse/IGNITE-14439 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not > been fixed properly for two reasons. The first is one is that > _GridCacheProcessor.utilityCache_ could be accessed before the first exchange > finished. The second is that it doesn't resolve the original issue, because > _GridServiceProcessor.onKernelStop_ is followed by > _GridCacheProcessor.onKernelStop_, so caches should be already initialized. > Thus that fix should be reverted. > Revering this fix induces the issue related to accessing the utility cache by > getting cluster name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14439) NPE when accessing clustername before first exchange finished
[ https://issues.apache.org/jira/browse/IGNITE-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Vinokurov reassigned IGNITE-14439: Assignee: Pavel Vinokurov > NPE when accessing clustername before first exchange finished > - > > Key: IGNITE-14439 > URL: https://issues.apache.org/jira/browse/IGNITE-14439 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not > been fixed properly for two reasons. The first is one is that > _GridCacheProcessor.utilityCache_ could be accessed before the first exchange > finished. The second is that it doesn't resolve the original issue, because > _GridServiceProcessor.onKernelStop_ is followed by > _GridCacheProcessor.onKernelStop_, so caches should be already initialized. > Thus that fix should be reverted. > Revering this fix induces the issue related to accessing the utility cache by > getting cluster name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14283) Create the Sanity Checks job on TC
[ https://issues.apache.org/jira/browse/IGNITE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313849#comment-17313849 ] Peter Ivanov commented on IGNITE-14283: --- [~timonin.maksim] — check this setup, please: https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Test/5948806 > Create the Sanity Checks job on TC > -- > > Key: IGNITE-14283 > URL: https://issues.apache.org/jira/browse/IGNITE-14283 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Peter Ivanov >Priority: Major > > 1. The [Build] job runs without any checks. > 2. There will be a new job [Sanity Checks], that runs all checks - > checkstyle, licenses, javadoc, check-suites. > 3. [Sanity Checks] runs in parallel with [Build]. > 4. All TC jobs with tests depend on a result of the [Sanity Checks] job. If > the check job fails then a test job won't be started. > 5. Users can disable the [Sanity Checks] job with a selector on the > Parameters tab of custom TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14472) Performance drop on primitive operations.
[ https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14472: - Assignee: Ivan Daschinskiy > Performance drop on primitive operations. > - > > Key: IGNITE-14472 > URL: https://issues.apache.org/jira/browse/IGNITE-14472 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python, thin > > Reason of performance drop: header struct of Response is not cached (now it > is instance variable, earlier it will be class variable) > Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14472) Performance drop on primitive operations.
Ivan Daschinskiy created IGNITE-14472: - Summary: Performance drop on primitive operations. Key: IGNITE-14472 URL: https://issues.apache.org/jira/browse/IGNITE-14472 Project: Ignite Issue Type: Bug Components: python, thin client Affects Versions: python-0.4.0 Reporter: Ivan Daschinskiy Reason of performance drop: header struct of Response is not cached (now it is instance variable, earlier it will be class variable) Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13258) Improve control.sh --cache list command to show cache sizes
[
https://issues.apache.org/jira/browse/IGNITE-13258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313838#comment-17313838
]
Ignite TC Bot commented on IGNITE-13258:
{panel:title=Branch: [pull/8040/head] Base: [master] : Possible Blockers
(29)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5948175]]
* IgniteControlUtilityTestSuite: GridCommandHandlerClusterByClassTest.testHelp
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testCacheHelp - Test has low fail rate in
base branch 0,0% and is not flaky
* IgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassWithSSLTest.testHelp - Test has low fail rate
in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5948138]]
{color:#d04437}PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5948153]]
* IgnitePdsTestSuite2:
IgnitePdsPartitionFilesDestroyTest.testPartitionFileDestroyAfterCheckpoint -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite2:
LocalWalModeChangeDuringRebalancingSelfTest.testDataClearedAfterRestartWithDisabledWal
- History for base branch is absent.
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5948093]]
* IgniteExamplesSelfTestSuite: TutorialStepByStepExampleSelfTest.testExample -
New test duration 186s is more that 1 minute
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5948142]]
{color:#d04437}Control Utility (Zookeeper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5948176]]
* ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testHelp - Test has low fail rate in base
branch 0,0% and is not flaky
* ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testCacheHelp - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5948160]]
* exe: ExamplesTest.TestRemoteNodes(SqlExample) - New test duration 66s is more
that 1 minute
{color:#d04437}Platform .NET (Core Linux){color} [[tests 3 TC_SERVICE_MESSAGE
|https://ci.ignite.apache.org/viewLog.html?buildId=5948157]]
* dll: IgnitionStartTest.TestIgniteStartsFromSpringXml - History for base
branch is absent.
* dll: IgniteConfigurationTest.TestSpringXml - Test has low fail rate in base
branch 0,0% and is not flaky
* dll: MessagingTest.TestLocalListenMultithreaded - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5948162]]
* IgniteBinaryCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.checkLostPartition[ATOMIC
READ_ONLY_ALL 0 true 3 false] - Test has low fail rate in base branch 0,0% and
is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQueryWithAffinityKeyEscapeAll -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5948155]]
* IgnitePdsTestSuite4: SharedPageLockTrackerTest.testTakeDumpByCount - New test
duration 104s is more that 1 minute
{color:#d04437}PDS 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5948152]]
* IgnitePdsTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateWithReadOnlyFailover3
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite: PagesWriteThrottleSmokeTest.testThrottle - Test has low
fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite:
CpTriggeredWalDeltaConsistencyTest.testPutRemoveCacheDestroy - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0 Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=5948177]]
{color:#d04437}Cache (Expiry Policy){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5948127]]
* IgniteCacheExpiryPolicyTestSuite:
IgniteCacheTxWithStoreExpiryPolicyTest.testNearAccess - Test has low fail rate
in base branch 0,0% and is not flaky
{color:#d04437}[Missing Tests]{color} [[tests 3 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5948181]]
* org.apache.ignite.startup.servlet.GridServletLoaderTest.testLoader - History
for base branch is absent.
*
[jira] [Commented] (IGNITE-14402) Java Thin: Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-14402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313833#comment-17313833 ] Aleksey Plekhanov commented on IGNITE-14402: [~ptupitsyn] can you please review the patch? > Java Thin: Continuous Query > --- > > Key: IGNITE-14402 > URL: https://issues.apache.org/jira/browse/IGNITE-14402 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-50 > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement Continuous Query API in Java Thin Client. > See .NET Thin Client as a reference: IGNITE-13148 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14402) Java Thin: Continuous Query
[
https://issues.apache.org/jira/browse/IGNITE-14402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313831#comment-17313831
]
Ignite TC Bot commented on IGNITE-14402:
{panel:title=Branch: [pull/8960/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8960/head] Base: [master] : New Tests
(21)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
13|https://ci.ignite.apache.org/viewLog.html?buildId=5946893]]
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testJCacheListenersExpiredEntries - PASSED{color}
* {color:#013220}ClientTestSuite: CacheEntryListenersTest.testListenersClose -
PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testListenersUnsupportedParameters - PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testDisconnectListeners - PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testContinuousQueriesWithIncludeExpired - PASSED{color}
* {color:#013220}ClientTestSuite: CacheEntryListenersTest.testContinuousQueries
- PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testContinuousQueriesWithTimeInterval - PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testListenersWithRemoteFilter - PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testListenersWithKeepBinary - PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testContinuousQueriesWithPageSize - PASSED{color}
* {color:#013220}ClientTestSuite:
CacheEntryListenersTest.testContinuousQueriesWithInitialQuery - PASSED{color}
... and 2 new tests
{color:#8b}PDS (Compatibility)*{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=5946403]]
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JavaThinCompatibilityTest.testCurrentClientToOldServer[Version 2.10.0] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JdbcThinCompatibilityTest.testCurrentClientToOldServer[Version 2.10.0] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JavaThinCompatibilityTest.testOldClientToCurrentServer[Version 2.10.0] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JavaThinCompatibilityTest.testOldClientToCurrentServer[Version 2.9.1] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JavaThinCompatibilityTest.testCurrentClientToOldServer[Version 2.9.1] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JdbcThinCompatibilityTest.testOldClientToCurrentServer[Version 2.9.1] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JdbcThinCompatibilityTest.testCurrentClientToOldServer[Version 2.9.1] -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
JdbcThinCompatibilityTest.testOldClientToCurrentServer[Version 2.10.0] -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5945933buildTypeId=IgniteTests24Java8_RunAll]
> Java Thin: Continuous Query
> ---
>
> Key: IGNITE-14402
> URL: https://issues.apache.org/jira/browse/IGNITE-14402
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: iep-50
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement Continuous Query API in Java Thin Client.
> See .NET Thin Client as a reference: IGNITE-13148
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13399) CpuLoad metric reports -1 under Java 11 in embedded mode
[
https://issues.apache.org/jira/browse/IGNITE-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313826#comment-17313826
]
Mirza Aliev commented on IGNITE-13399:
--
Hi [~dmekhanikov], changes look good to me, LGTM
> CpuLoad metric reports -1 under Java 11 in embedded mode
>
>
> Key: IGNITE-13399
> URL: https://issues.apache.org/jira/browse/IGNITE-13399
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When running a node in embedded mode under Java 11, the CpuLoad metric
> reports -1. The process needs to be started with the following option:
> {{--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> We need to get rid of this requirement to run Java with additional flags to
> get proper values for the CpuLoad metric.
> Some investigation was done under the following issue:
> https://issues.apache.org/jira/browse/IGNITE-13306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14465) Add the ability to activate the cluster via the Python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313816#comment-17313816 ] Ivan Daschinskiy commented on IGNITE-14465: --- [~isapego] Ok, suggested some changes in personal conversation. > Add the ability to activate the cluster via the Python thin client > -- > > Key: IGNITE-14465 > URL: https://issues.apache.org/jira/browse/IGNITE-14465 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This feature will be extremely useful when working with clusters that have > the "persistenceEnabled" option. Since they require activation to get > started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14471) JDBCv2: query cursors leak when node to execute queries is specified
Taras Ledkov created IGNITE-14471: - Summary: JDBCv2: query cursors leak when node to execute queries is specified Key: IGNITE-14471 URL: https://issues.apache.org/jira/browse/IGNITE-14471 Project: Ignite Issue Type: Improvement Components: sql Reporter: Taras Ledkov Assignee: Taras Ledkov Query cursors leak when node to execute queries is specified. In this case the query tasks are executed on the remote node instead of client node launched by the JDBC v2 client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14465) Add the ability to activate the cluster via the Python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313523#comment-17313523 ] Igor Sapego edited comment on IGNITE-14465 at 4/2/21, 10:38 AM: TC pass: https://ci.ignite.apache.org/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/5948620 [~ivandasch], can you please review? was (Author: isapego): TC pass: https://ggtc.gridgain.com/buildConfiguration/Tests_GridGainCeEeUe_Latest_CE_ThinClientPython/5599288 [~ivandasch], can you please review? > Add the ability to activate the cluster via the Python thin client > -- > > Key: IGNITE-14465 > URL: https://issues.apache.org/jira/browse/IGNITE-14465 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This feature will be extremely useful when working with clusters that have > the "persistenceEnabled" option. Since they require activation to get > started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13508) Test scenario of two-phased rebalance (PDS reduce)
[
https://issues.apache.org/jira/browse/IGNITE-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-13508:
--
Sprint: Ducktape Sprint 5, Ducktape Sprint 6, Ducktape Sprint 7 (was:
Ducktape Sprint 5, Ducktape Sprint 6)
> Test scenario of two-phased rebalance (PDS reduce)
> --
>
> Key: IGNITE-13508
> URL: https://issues.apache.org/jira/browse/IGNITE-13508
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Daschinskiy
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> Let us assume a cluster of 8 affinity nodes.
> Lets divide cluster in 2 equal cells:
> Each node in cell has the same node attribute {{CELL=CELL_}}
> Caches, that will be started on nodes, should have affinity function with
> this backup filter:
> {code:java}
> public class CellularAffinityBackupFilter implements
> IgniteBiPredicate> {
> private static final long serialVersionUID = 1L;
> private final String attrName;
> public CellularAffinityBackupFilter(String attrName) {
> this.attrName = attrName;
> }
> @Override public boolean apply(ClusterNode candidate, List
> previouslySelected) {
> for (ClusterNode node : previouslySelected)
> return Objects.equals(candidate.attribute(attrName),
> node.attribute(attrName));
> return true;
> }
> }
> {code}
> Also, caches should be partitioned and have 3 backups.
> Steps:
> * Preparations.
> 1. Start all 2 cells.
> 2. Load data to cache with the mentioned above affinity function and fix PDS
> size on all nodes.
> 3. Delete 80% of data and fix PDS size on all nodes.
> * Phase 1
> 1. Stop two nodes in each cell, total a half of all nodes and clean PDS.
> 2. Start cleaned node with preservance of consistent id and cell attributes.
> 3. Wait for rebalance finished.
> * Phase 2
> Run steps 1-3 of Phase 2 on the other half of the cluster.
> * Verifications
> 1. Check that PDS size reduced (compare to step 3)
> 2. Check data consistency (idle_verify --dump)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14137) Detect and fix failures reasons (nightly runs fails)
[ https://issues.apache.org/jira/browse/IGNITE-14137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14137: -- Sprint: Ducktape Sprint 3, Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6, Ducktape Sprint 7 (was: Ducktape Sprint 3, Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6) > Detect and fix failures reasons (nightly runs fails) > > > Key: IGNITE-14137 > URL: https://issues.apache.org/jira/browse/IGNITE-14137 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Blocker > > Jenkins runs fails, 1-4 ... 60 tests affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13969) Thin client test [umbrella]
[ https://issues.apache.org/jira/browse/IGNITE-13969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13969: -- Sprint: Ducktape Sprint 1, Ducktape Sprint 2, Ducktape Sprint 3, Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6, Ducktape Sprint 7 (was: Ducktape Sprint 1, Ducktape Sprint 2, Ducktape Sprint 3, Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6) > Thin client test [umbrella] > --- > > Key: IGNITE-13969 > URL: https://issues.apache.org/jira/browse/IGNITE-13969 > Project: Ignite > Issue Type: Wish >Reporter: Anton Vinogradov >Assignee: Evgeniya Vdovets >Priority: Major > > Ensure Thin client works. > Check the whole TC API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14258) Ducktests code de-duplication and simplification
[ https://issues.apache.org/jira/browse/IGNITE-14258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14258: -- Sprint: Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6, Ducktape Sprint 7 (was: Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6) > Ducktests code de-duplication and simplification > > > Key: IGNITE-14258 > URL: https://issues.apache.org/jira/browse/IGNITE-14258 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > The goal is to perform pre-merge review of the whole ducktests code and > refactor it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14259) Ducktests pre-merge presentation
[ https://issues.apache.org/jira/browse/IGNITE-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14259: -- Sprint: Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6, Ducktape Sprint 7 (was: Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6) > Ducktests pre-merge presentation > > > Key: IGNITE-14259 > URL: https://issues.apache.org/jira/browse/IGNITE-14259 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > A webinar-like presentation is required to discuss what we got before the > merge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[
https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-14226:
--
Sprint: Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6, Ducktape
Sprint 7 (was: Ducktape Sprint 4, Ducktape Sprint 5, Ducktape Sprint 6)
> Ducktape tests of rebalance
> ---
>
> Key: IGNITE-14226
> URL: https://issues.apache.org/jira/browse/IGNITE-14226
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> There should be tests of rebalance for both in-memory caches and persistent
> caches.
> In case of persistent caches, the tests also should check both modes of
> rebalance: full and historical (asserts is needed that the proper mode of
> rebalance was worked).
> Basic scenario:
> Testing of rebalance triggered by two event types: node join and node left
> the topology (baseline change in persistent mode).
> Extended scenario:
> Node join or left during rebalance process.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that greater value makes rebalance faster on large data or
> [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
> enabled (rebalanceThrottling > 0).
> # Rebalance throttle - the value for
> {{IgniteConfiguration#rebalanceThrottle}} property (see [rebalance message
> throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
> [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> 0 - throttling disabled, greater value makes rebalance slower.
> Test result: time taken to rebalance process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14470) Thin client application service
[ https://issues.apache.org/jira/browse/IGNITE-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14470: -- Sprint: Ducktape Sprint 6 > Thin client application service > --- > > Key: IGNITE-14470 > URL: https://issues.apache.org/jira/browse/IGNITE-14470 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > Allow starting thin client within the java application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14470) Thin client application service
[ https://issues.apache.org/jira/browse/IGNITE-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14470: -- Sprint: Ducktape Sprint 6, Ducktape Sprint 7 (was: Ducktape Sprint 6) > Thin client application service > --- > > Key: IGNITE-14470 > URL: https://issues.apache.org/jira/browse/IGNITE-14470 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > Allow starting thin client within the java application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14470) Thin client application service
Anton Vinogradov created IGNITE-14470: - Summary: Thin client application service Key: IGNITE-14470 URL: https://issues.apache.org/jira/browse/IGNITE-14470 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Allow starting thin client within the java application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14319) Multithreaded data generation for rebalance tests
[
https://issues.apache.org/jira/browse/IGNITE-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin resolved IGNITE-14319.
--
Resolution: Won't Fix
> Multithreaded data generation for rebalance tests
> -
>
> Key: IGNITE-14319
> URL: https://issues.apache.org/jira/browse/IGNITE-14319
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
>
> At the moment, {{DataGenerationApplication}} generates data in the single
> thread. We should make that routine multithreaded.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14180) Configuration notification API
[ https://issues.apache.org/jira/browse/IGNITE-14180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313770#comment-17313770 ] Semyon Danilov commented on IGNITE-14180: - LGTM > Configuration notification API > -- > > Key: IGNITE-14180 > URL: https://issues.apache.org/jira/browse/IGNITE-14180 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 6h 20m > Remaining Estimate: 0h > > Local (and in the future global) Storage should support notification > mechanism: all interested components should be able to subscribe to > notifications about stored keys (add, remove, update). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Skip writing null-map and varlen table when possible
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13670: -- Description: h3. Motivation. The nullmap is currently always written to the tuple layout for all columns even if there are no nullable columns described in the schema. The same is true and can be done for varlen table. Seems, we can extend this idea to every single tuple and still have the ability to compare key/value content fast as byte arrays. Apparently, this will work for rows of same schema version, but we shouldn't bother about the schema version, because anyway, old row will be upgraded to the newer version before comparison according to the live-schema concept. h3. Description. Let's skip an empty nullmap and write just a flag instead. Let's skip an empty varlen table and write just a flag instead. was: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). Also, need to add support for skipping writing nullmaps (use the flags bit). > Skip writing null-map and varlen table when possible > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > h3. Motivation. > The nullmap is currently always written to the tuple layout for all columns > even if there are no nullable columns described in the schema. > The same is true and can be done for varlen table. > Seems, we can extend this idea to every single tuple and still have the > ability to compare key/value content fast as byte arrays. > Apparently, this will work for rows of same schema version, but we shouldn't > bother about the schema version, > because anyway, old row will be upgraded to the newer version before > comparison according to the live-schema concept. > h3. Description. > Let's skip an empty nullmap and write just a flag instead. > Let's skip an empty varlen table and write just a flag instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14469) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
[ https://issues.apache.org/jira/browse/IGNITE-14469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-14469: - Component/s: sql control.sh > Adding a list of caches that will not be forced to rebuild indexes to the > control.sh --cache indexes_force_rebuild > -- > > Key: IGNITE-14469 > URL: https://issues.apache.org/jira/browse/IGNITE-14469 > Project: Ignite > Issue Type: Improvement > Components: control.sh, sql >Reporter: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > > After the IGNITE-14321 is implemented, it will be necessary to add to the > command *control.sh --cache indexes_force_rebuild* the ability to display to > the user that the forced rebuilding of the indexes is impossible, since they > are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14468) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
[ https://issues.apache.org/jira/browse/IGNITE-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-14468. -- Resolution: Duplicate > Adding a list of caches that will not be forced to rebuild indexes to the > control.sh --cache indexes_force_rebuild > -- > > Key: IGNITE-14468 > URL: https://issues.apache.org/jira/browse/IGNITE-14468 > Project: Ignite > Issue Type: Improvement > Components: control.sh, sql >Reporter: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > > After the IGNITE-14321 is implemented, it will be necessary to add to the > command the ability to display to the user that the forced rebuilding of the > indexes is impossible, since they are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14469) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
Kirill Tkalenko created IGNITE-14469: Summary: Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild Key: IGNITE-14469 URL: https://issues.apache.org/jira/browse/IGNITE-14469 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 2.11 After the IGNITE-14321 is implemented, it will be necessary to add to the command *control.sh --cache indexes_force_rebuild* the ability to display to the user that the forced rebuilding of the indexes is impossible, since they are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14468) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
Kirill Tkalenko created IGNITE-14468: Summary: Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild Key: IGNITE-14468 URL: https://issues.apache.org/jira/browse/IGNITE-14468 Project: Ignite Issue Type: Improvement Components: control.sh, sql Reporter: Kirill Tkalenko Fix For: 2.11 After the IGNITE-14321 is implemented, it will be necessary to add to the command the ability to display to the user that the forced rebuilding of the indexes is impossible, since they are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14388) Add affinity key support.
[ https://issues.apache.org/jira/browse/IGNITE-14388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14388: -- Description: For now, we calculate Row hash for a whole key chunk represented with byte[]. Let's calculate Row hash for affinity columns only. was: For now, we calculate key hash for a whole key chunk represented with byte[]. Let's calculate key hash for affinity columns only. > Add affinity key support. > - > > Key: IGNITE-14388 > URL: https://issues.apache.org/jira/browse/IGNITE-14388 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > For now, we calculate Row hash for a whole key chunk represented with byte[]. > Let's calculate Row hash for affinity columns only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14236) Provide a new version of cache API
[
https://issues.apache.org/jira/browse/IGNITE-14236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313741#comment-17313741
]
Andrey Mashenkov commented on IGNITE-14236:
---
[~slava.koptilin], would you please clarify the motivation.
We already have a task [1] done for table public API, where we are not limited
with just key-value case.
In next [2] task I try to elaborate criteria for internal table API and think
we will operate with binary row representation instead of key-value pairs.
Why you use the term "cache" here?
Do you mean a public Cache API over Tables, or some 3-rd party storage? or
internal API for tables?
[1] https://issues.apache.org/jira/browse/IGNITE-14035
[2] https://issues.apache.org/jira/browse/IGNITE-14330
> Provide a new version of cache API
> --
>
> Key: IGNITE-14236
> URL: https://issues.apache.org/jira/browse/IGNITE-14236
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Need to provide a minimal cache API that includes at least the following
> methods:
> - reading a value for a given key
> - writing a new value for a given key
> - remove a value for a given key
> - method that determines if the cache contains an entry for the specified
> key.
> - a way to iterate all key/value pairs
> - cache/table size (this method is questionable)
> Additionally, it can be considered adding a way to execute the user's code
> for the specified key - something like {{Cache#invoke()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14283) Create the Sanity Checks job on TC
[ https://issues.apache.org/jira/browse/IGNITE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313738#comment-17313738 ] Peter Ivanov commented on IGNITE-14283: --- Agreed with [~timonin.maksim] to include Sanity Check steps to Build build configuration. > Create the Sanity Checks job on TC > -- > > Key: IGNITE-14283 > URL: https://issues.apache.org/jira/browse/IGNITE-14283 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Peter Ivanov >Priority: Major > > 1. The [Build] job runs without any checks. > 2. There will be a new job [Sanity Checks], that runs all checks - > checkstyle, licenses, javadoc, check-suites. > 3. [Sanity Checks] runs in parallel with [Build]. > 4. All TC jobs with tests depend on a result of the [Sanity Checks] job. If > the check job fails then a test job won't be started. > 5. Users can disable the [Sanity Checks] job with a selector on the > Parameters tab of custom TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14467) Ignite Compute service.
Andrey Mashenkov created IGNITE-14467: - Summary: Ignite Compute service. Key: IGNITE-14467 URL: https://issues.apache.org/jira/browse/IGNITE-14467 Project: Ignite Issue Type: New Feature Reporter: Andrey Mashenkov Port IgniteCompute component from 2.0 to 3.0. Rework ComputeTask/ComputeJob interfaces to make them compliant with JDK CompletableStage API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14466) Changing cache configuration once cache is created confuses PME on node join
Ilya Kasnacheev created IGNITE-14466:
Summary: Changing cache configuration once cache is created
confuses PME on node join
Key: IGNITE-14466
URL: https://issues.apache.org/jira/browse/IGNITE-14466
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: Ilya Kasnacheev
The following code triggers the issue:
{code:java}
inputCache = ignite.cache(inputCacheName);
CacheConfiguration configuration =
inputCache.getConfiguration(CacheConfiguration.class);
outputCache = ignite.getOrCreateCache(configuration.setName("cache_" +
ctx.name()));
{code}
It is possible for user code to accidentally reuse the same cache configuration
instance when creating caches (see linked example). This causes the following
hard to debug NPE:
{code:java}
Mar 30, 2021 11:53:25 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Exception in discovery notyfier worker thread.
java.lang.NullPointerException
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.addClientNode(GridDiscoveryManager.java:445)
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.processCacheChangeRequests(ClusterCachesInfo.java:596)
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.onCacheChangeRequested(ClusterCachesInfo.java:430)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onCustomEvent(GridCacheProcessor.java:3827)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:697)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:604)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2667)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2705)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
We should, maybe, clone a cache configuration before putting it to our internal
data structures? Or better, serialize-deserialize as all of the remaining nodes
in the cluster do.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14464) Remove released version of Ignite from regular ducktests
[ https://issues.apache.org/jira/browse/IGNITE-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313721#comment-17313721 ] Nikolay Izhikov commented on IGNITE-14464: -- [~av] Ok, let's cancel it. > Remove released version of Ignite from regular ducktests > > > Key: IGNITE-14464 > URL: https://issues.apache.org/jira/browse/IGNITE-14464 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-56 > Time Spent: 10m > Remaining Estimate: 0h > > No need to tests the released ignite version regularly. > We can remove the 2.10.0 version from the source test matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14452) Add checking of the iptables settings applied.
[ https://issues.apache.org/jira/browse/IGNITE-14452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313717#comment-17313717 ] Anton Vinogradov commented on IGNITE-14452: --- Merged into ignite-ducktape. Thanks for your contribution. > Add checking of the iptables settings applied. > -- > > Key: IGNITE-14452 > URL: https://issues.apache.org/jira/browse/IGNITE-14452 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Sometimes, we lack settings of iptables for unknows reason. Let's monitor > this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13873) Milti-cell transaction changes may be not visible (during some time) after the Cellular switch [Sync-free switch]
[
https://issues.apache.org/jira/browse/IGNITE-13873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313713#comment-17313713
]
Anton Vinogradov commented on IGNITE-13873:
---
Merged into master.
> Milti-cell transaction changes may be not visible (during some time) after
> the Cellular switch [Sync-free switch]
> -
>
> Key: IGNITE-13873
> URL: https://issues.apache.org/jira/browse/IGNITE-13873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: iep-45
> Fix For: 2.11
>
> Attachments: master (as 2.9) vs improved (as dev) .png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Transactions over some cells may be recovered after the stale data read.
> For example:
> We have 2 cells, the first contains partitions for k1, second for k2.
> Tx with put(k1,v1) and put(k2,v2) started and prepared.
> Then node from the first cell, which is the primary for k1, failed.
> Currently, the second cell (with key2) may finish the cellular switch before
> tx recovered and stale data read is possible.
> Primaries from the {{tx.transactionNodes()}} should be taken into account
> instead of the current logic that awaits for all transactions located on
> nodes who are backups to the failed primary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14457) Update Ignite 3 binary build structure
[
https://issues.apache.org/jira/browse/IGNITE-14457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313708#comment-17313708
]
Peter Ivanov commented on IGNITE-14457:
---
Fixed tests.
BTW — is it ok to push empty README and NOTICE currently, or should I add there
some text?
> Update Ignite 3 binary build structure
> --
>
> Key: IGNITE-14457
> URL: https://issues.apache.org/jira/browse/IGNITE-14457
> Project: Ignite
> Issue Type: Task
> Components: build
>Affects Versions: 3.0.0-alpha1
>Reporter: Valentin Kulichenko
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the first alpha release, we provided binaries as separate single-file
> downloads for Unix and Windows. This approach doesn't work for two reasons:
> # Website download for the Unix binary doesn't work properly, because the
> file doesn't have an extension. This doesn't seem to have a reasonable
> solution.
> # Binaries that are downloaded from the website are required to include
> {{NOTICE}} and {{LICENSE}} files.
> See IGNITE-13978 and INFRA-21332 for more details.
> As a solution, let's switch to a ZIP file containing the following:
> * {{ignite}} (Unix CLI tool)
> * {{ignite.exe}} (Windows CLI tool)
> * {{NOTICE}}
> * {{LICENSE}}
> * {{README}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13546) Calcite integration. Hash index spool
[ https://issues.apache.org/jira/browse/IGNITE-13546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313704#comment-17313704 ] Stanilovsky Evgeny commented on IGNITE-13546: - plz check my comments. > Calcite integration. Hash index spool > - > > Key: IGNITE-13546 > URL: https://issues.apache.org/jira/browse/IGNITE-13546 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Critical > Original Estimate: 80h > Time Spent: 2h 10m > Remaining Estimate: 77h 50m > > To have a performance boost need to implement hash index spools. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313700#comment-17313700
]
Alexey Goncharuk commented on IGNITE-14459:
---
[~agura][~ascherbakov] can you take a look at the fix?
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14375) Pending discovery messages can be erroneously send.
[ https://issues.apache.org/jira/browse/IGNITE-14375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14375: --- Reviewer: Ivan Bessonov > Pending discovery messages can be erroneously send. > --- > > Key: IGNITE-14375 > URL: https://issues.apache.org/jira/browse/IGNITE-14375 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Due to pending messages logic implementation its possible to process already > outdated _DynamicCacheChangeBatch_ message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14458) Fix flaky IgniteLocalWalSizeTest
[ https://issues.apache.org/jira/browse/IGNITE-14458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313689#comment-17313689 ] Ivan Bessonov commented on IGNITE-14458: [~ktkale...@gridgain.com] thank you for the change! I'll merge it now > Fix flaky IgniteLocalWalSizeTest > > > Key: IGNITE-14458 > URL: https://issues.apache.org/jira/browse/IGNITE-14458 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix the flaky *IgniteLocalWalSizeTest* tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14375) Pending discovery messages can be erroneously send.
[ https://issues.apache.org/jira/browse/IGNITE-14375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313673#comment-17313673 ] Ivan Bessonov commented on IGNITE-14375: [~zstan] thank you for the fix, looks good to me, I think you can merge it now. > Pending discovery messages can be erroneously send. > --- > > Key: IGNITE-14375 > URL: https://issues.apache.org/jira/browse/IGNITE-14375 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Due to pending messages logic implementation its possible to process already > outdated _DynamicCacheChangeBatch_ message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14464) Remove released version of Ignite from regular ducktests
[ https://issues.apache.org/jira/browse/IGNITE-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313663#comment-17313663 ] Anton Vinogradov commented on IGNITE-14464: --- [~nizhikov] we never have 2.10.0 as a default target, we use the latest instead. Currently, 2.10 is the latest release and we have to have it default in addition to dev. > Remove released version of Ignite from regular ducktests > > > Key: IGNITE-14464 > URL: https://issues.apache.org/jira/browse/IGNITE-14464 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-56 > Time Spent: 10m > Remaining Estimate: 0h > > No need to tests the released ignite version regularly. > We can remove the 2.10.0 version from the source test matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14391) Multi-node cache data preloading
[
https://issues.apache.org/jira/browse/IGNITE-14391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14391:
-
Labels: IEP-56 (was: )
> Multi-node cache data preloading
>
>
> Key: IGNITE-14391
> URL: https://issues.apache.org/jira/browse/IGNITE-14391
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Need to add the test parameter {{preloaders}} and use it as {{num_nodes}}
> parameter on creation {{IgniteApplicationService}} instance used for data
> preloading.
> The keys of preloading data entries should be distributed between client
> nodes as equal sized ranges.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14390) Add rebalance statistic to test result data
[ https://issues.apache.org/jira/browse/IGNITE-14390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-14390: - Labels: IEP-56 (was: ) > Add rebalance statistic to test result data > --- > > Key: IGNITE-14390 > URL: https://issues.apache.org/jira/browse/IGNITE-14390 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Labels: IEP-56 > Time Spent: 20m > Remaining Estimate: 0h > > Need to add to test result data the rebalance statistic data derived from > node rebalance metrics: > start_time [min, max] > end_time [min, max] > duration [min, max, sum] > received_bytes [min, max, sum] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14395) Shorter test results directory name
[
https://issues.apache.org/jira/browse/IGNITE-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14395:
-
Labels: IEP-56 (was: )
> Shorter test results directory name
> ---
>
> Key: IGNITE-14395
> URL: https://issues.apache.org/jira/browse/IGNITE-14395
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The large number of parameters and their long names cause the too long test
> results directory name, so it is reason to split the test into two methods
> (it removes the {{trigger_event}} parameter), and cut off the prefix
> {{rebalance_}} from rebalance parameters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14300) Rebalance speed as part of test result data
[
https://issues.apache.org/jira/browse/IGNITE-14300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14300:
-
Labels: IEP-56 (was: )
> Rebalance speed as part of test result data
> ---
>
> Key: IGNITE-14300
> URL: https://issues.apache.org/jira/browse/IGNITE-14300
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Need to add properly calculated rebalance speed value to the test result data.
> To do that, we need to reset the metrics before rebalance start, and get the
> values of cache group metrics {{RebalancingReceivedBytes}},
> {{RebalancingStartTime}} and {{RebalancingEndTime}} for each test cache on
> each node where rebalancing routine has been started, after rebalance end. We
> should sum all {{RebalancingReceivedBytes}} values, and divide that by sum of
> all differences between {{RebalancingEndTime}} and {{RebalancingStartTime}}
> for getting the real rebalance speed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14319) Multithreaded data generation for rebalance tests
[
https://issues.apache.org/jira/browse/IGNITE-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14319:
-
Labels: IEP-56 (was: )
> Multithreaded data generation for rebalance tests
> -
>
> Key: IGNITE-14319
> URL: https://issues.apache.org/jira/browse/IGNITE-14319
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
>
> At the moment, {{DataGenerationApplication}} generates data in the single
> thread. We should make that routine multithreaded.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14228:
-
Labels: IEP-56 (was: )
> Ducktape test of rebalance for in-memory mode
> -
>
> Key: IGNITE-14228
> URL: https://issues.apache.org/jira/browse/IGNITE-14228
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> This test should check the rebalance on in-memory caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology.
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that greater value makes rebalance faster on large data or
> [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
> enabled (rebalanceThrottling > 0).
> # Rebalance throttle - the value for
> {{IgniteConfiguration#rebalanceThrottle}} property (see [rebalance message
> throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
> [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> 0 - throttling disabled, greater value makes rebalance slower.
> Test result: time taken to rebalance process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
