[jira] [Commented] (IGNITE-12671) Update of partition's states can stuck when rebalance completed during exchange
[
https://issues.apache.org/jira/browse/IGNITE-12671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036758#comment-17036758
]
Alexey Scherbakov commented on IGNITE-12671:
[~v.pyatkov]
Looks good.
Merged to master cc6f4d7814493aaeb485b39056d6afd44b98919d.
Thank for contribution.
> Update of partition's states can stuck when rebalance completed during
> exchange
> ---
>
> Key: IGNITE-12671
> URL: https://issues.apache.org/jira/browse/IGNITE-12671
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Single message is ignoring during exchange:
> {code:title=GridCachePartitionExchangeManager.java}
> if (exchangeInProgress()) {
> if (log.isInfoEnabled())
> log.info("Ignore single message without exchange id (there is exchange in
> progress) [nodeId=" + node.id() + "]");
>
> return;
> }
> {code}
> By thew reason the message does not be received after exchange. At the result
> waiting ideal assignment stuck until next rebalance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12671) Update of partition's states can stuck when rebalance completed during exchange
[
https://issues.apache.org/jira/browse/IGNITE-12671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036750#comment-17036750
]
Ignite TC Bot commented on IGNITE-12671:
{panel:title=Branch: [pull/7425/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5048515buildTypeId=IgniteTests24Java8_RunAll]
> Update of partition's states can stuck when rebalance completed during
> exchange
> ---
>
> Key: IGNITE-12671
> URL: https://issues.apache.org/jira/browse/IGNITE-12671
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Single message is ignoring during exchange:
> {code:title=GridCachePartitionExchangeManager.java}
> if (exchangeInProgress()) {
> if (log.isInfoEnabled())
> log.info("Ignore single message without exchange id (there is exchange in
> progress) [nodeId=" + node.id() + "]");
>
> return;
> }
> {code}
> By thew reason the message does not be received after exchange. At the result
> waiting ideal assignment stuck until next rebalance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12667) Flaky test FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
[
https://issues.apache.org/jira/browse/IGNITE-12667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12667:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Flaky test
> FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
>
>
> Key: IGNITE-12667
> URL: https://issues.apache.org/jira/browse/IGNITE-12667
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {{FailureProcessorThreadDumpThrottlingTest#testThrottlingPerFailureType}} is
> flaky. On TC agents thread dumps generation takes a lot of time, so current
> throttling timeout is too small for TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12667) Flaky test FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
[
https://issues.apache.org/jira/browse/IGNITE-12667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036596#comment-17036596
]
Andrey N. Gura commented on IGNITE-12667:
-
Failed suite isn't related with change. Just tests were changed in other suite.
> Flaky test
> FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
>
>
> Key: IGNITE-12667
> URL: https://issues.apache.org/jira/browse/IGNITE-12667
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {{FailureProcessorThreadDumpThrottlingTest#testThrottlingPerFailureType}} is
> flaky. On TC agents thread dumps generation takes a lot of time, so current
> throttling timeout is too small for TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12667) Flaky test FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
[
https://issues.apache.org/jira/browse/IGNITE-12667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036595#comment-17036595
]
Ignite TC Bot commented on IGNITE-12667:
{panel:title=Branch: [pull/7415/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5048652]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5044169buildTypeId=IgniteTests24Java8_RunAll]
> Flaky test
> FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
>
>
> Key: IGNITE-12667
> URL: https://issues.apache.org/jira/browse/IGNITE-12667
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {{FailureProcessorThreadDumpThrottlingTest#testThrottlingPerFailureType}} is
> flaky. On TC agents thread dumps generation takes a lot of time, so current
> throttling timeout is too small for TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12646) When DEBUG mode is enabled GridToStringBuilder may throw java.util.ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036569#comment-17036569
]
Andrey N. Gura commented on IGNITE-12646:
-
[~sergey-chugunov]
{quote}
always catch RuntimeExceptions in GridToStringBuilder code but for every
exception of this type caught we include a clear warning message in prepared
String representation that should provide as much information as possible to
find and fix the original problem in code.
{quote}
Agree with you. It could be useful.
> When DEBUG mode is enabled GridToStringBuilder may throw
> java.util.ConcurrentModificationException
> --
>
> Key: IGNITE-12646
> URL: https://issues.apache.org/jira/browse/IGNITE-12646
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.9
>
>
> With DEBUG enabled many components like CommunicationSPI start to log much
> larger chunks of information e.g. communication messages are logged as is.
> When big enough message with non-thread safe collection inside is logged by
> communication thread it is possible that some other thread started processing
> the same message. If processing involves modifying of the collection
> communication thread will get ConcurrentModificationException when in the
> middle of iterating over it.
> GridToStringBuilder should be safe from throwing this exception and
> (optionally) any type of RuntimeException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12638) Classes persisted by DistributedMetaStorage are not IgniteDTO
[ https://issues.apache.org/jira/browse/IGNITE-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036567#comment-17036567 ] Andrey N. Gura commented on IGNITE-12638: - [~ibessonov] LGTM. Merged to master branch. Thanks for your contribution. > Classes persisted by DistributedMetaStorage are not IgniteDTO > - > > Key: IGNITE-12638 > URL: https://issues.apache.org/jira/browse/IGNITE-12638 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > This has to be fixed to simplify future modification of component. > DistributedMetaStorageHistoryItem and DistributedMetaStorageVersion will be > persisted on disc so we need to have a reliable way to read them even when > classes will be updated in the future. IgniteDataTransferObject is the > standard option for such cases - it allows versioning of serialization format. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12668) Extend test coverage for plugin providers configuration
[
https://issues.apache.org/jira/browse/IGNITE-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036554#comment-17036554
]
Ignite TC Bot commented on IGNITE-12668:
{panel:title=Branch: [pull/7417/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5044537buildTypeId=IgniteTests24Java8_RunAll]
> Extend test coverage for plugin providers configuration
> ---
>
> Key: IGNITE-12668
> URL: https://issues.apache.org/jira/browse/IGNITE-12668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tests related with plugin providers configuration change should be added
> (https://issues.apache.org/jira/browse/IGNITE-11744)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12650) Mark MVCC with @IgniteExperimental annotation
[
https://issues.apache.org/jira/browse/IGNITE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036351#comment-17036351
]
Ignite TC Bot commented on IGNITE-12650:
{panel:title=Branch: [pull/7419/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5047241buildTypeId=IgniteTests24Java8_RunAll]
> Mark MVCC with @IgniteExperimental annotation
> -
>
> Key: IGNITE-12650
> URL: https://issues.apache.org/jira/browse/IGNITE-12650
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MVCC should be marked with the @IgniteExperimental annotation.
> * Beta version of Transactional SQL and MVCC
> * In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to
> allow users to experiment and share feedback.
> * This version of Transactional SQL and MVCC should not be considered for
> production.
> [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12646) When DEBUG mode is enabled GridToStringBuilder may throw java.util.ConcurrentModificationException
[ https://issues.apache.org/jira/browse/IGNITE-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036299#comment-17036299 ] Sergey Chugunov commented on IGNITE-12646: -- [~agura], I see your point and partly agree with you that this solution avoids and hides problem instead of highlighting it. At the same time I strongly believe that logging should never throw exceptions like CME, especially debug logging which is used to chase difficult problems down, not to reveal trivial ones. I suggest the following: we remove the flag and always catch RuntimeExceptions in GridToStringBuilder code but for every exception of this type caught we include a clear warning message in prepared String representation that should provide as much information as possible to find and fix the original problem in code. > When DEBUG mode is enabled GridToStringBuilder may throw > java.util.ConcurrentModificationException > -- > > Key: IGNITE-12646 > URL: https://issues.apache.org/jira/browse/IGNITE-12646 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > > With DEBUG enabled many components like CommunicationSPI start to log much > larger chunks of information e.g. communication messages are logged as is. > When big enough message with non-thread safe collection inside is logged by > communication thread it is possible that some other thread started processing > the same message. If processing involves modifying of the collection > communication thread will get ConcurrentModificationException when in the > middle of iterating over it. > GridToStringBuilder should be safe from throwing this exception and > (optionally) any type of RuntimeException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12646) When DEBUG mode is enabled GridToStringBuilder may throw java.util.ConcurrentModificationException
[ https://issues.apache.org/jira/browse/IGNITE-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036292#comment-17036292 ] Andrey N. Gura commented on IGNITE-12646: - [~sergey-chugunov] It seems that solution is too complex while problem is pretty simple. New system property is a bad idea from my point of view. It isn't obvious for end user. Also fix hides the problem but doesn't fix it. I think that better solution is just change order of two lines of code: first log the message and after it put message to processing queue. WDYT? > When DEBUG mode is enabled GridToStringBuilder may throw > java.util.ConcurrentModificationException > -- > > Key: IGNITE-12646 > URL: https://issues.apache.org/jira/browse/IGNITE-12646 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > > With DEBUG enabled many components like CommunicationSPI start to log much > larger chunks of information e.g. communication messages are logged as is. > When big enough message with non-thread safe collection inside is logged by > communication thread it is possible that some other thread started processing > the same message. If processing involves modifying of the collection > communication thread will get ConcurrentModificationException when in the > middle of iterating over it. > GridToStringBuilder should be safe from throwing this exception and > (optionally) any type of RuntimeException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12067) SQL: metrics of executions of user queries
[ https://issues.apache.org/jira/browse/IGNITE-12067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-12067. - Fix Version/s: 2.9 Resolution: Fixed [~amashenkov], thank you for review. I created a ticket for javadocs simplification IGNITE-12679. Merged to master. > SQL: metrics of executions of user queries > -- > > Key: IGNITE-12067 > URL: https://issues.apache.org/jira/browse/IGNITE-12067 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Lets add: > - Counter of success executed user queries. > - Counter of failed executed user queries. > - Counter of cancelled user queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12679) Simplify javadocs in SQL classes
Ivan Pavlukhin created IGNITE-12679: --- Summary: Simplify javadocs in SQL classes Key: IGNITE-12679 URL: https://issues.apache.org/jira/browse/IGNITE-12679 Project: Ignite Issue Type: Bug Components: sql Reporter: Ivan Pavlukhin Fix For: 2.9 Update javadocs according to comments in PR https://github.com/apache/ignite/pull/7412 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12582) It is needed to set used cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036032#comment-17036032 ] Alexey Scherbakov edited comment on IGNITE-12582 at 2/13/20 2:57 PM: - [~schernolyas] [~mstepachev] Looks good. Merged to master 465cc444d0bf69f230a7c6c9e429ff69851cba62. Thank for contribution. was (Author: ascherbakov): [~schernolyas] [~mstepachev] Looks good. Merged to master 465cc444d0bf69f230a7c6c9e429ff69851cba62. Thank for contribution. BTW, I see the same ticket [2], should it be closed as duplicate ? [2] https://issues.apache.org/jira/browse/IGNITE-12643 > It is needed to set used cache for Spring Data dynamically > -- > > Key: IGNITE-12582 > URL: https://issues.apache.org/jira/browse/IGNITE-12582 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.7.6 >Reporter: Sergey Chernolyas >Assignee: Sergey Chernolyas >Priority: Major > Fix For: 2.8.1 > > > Hi! > My project needs to configure used cache by property, like > ""[spring.data|http://spring.data/].mongodb.uri: > mongodb://:@:/" from Spring Data for > MongoDB. Now, I can set cache for particular repository by annotation > "RepositoryConfig" only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12643) Document new feature to set cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov resolved IGNITE-12643. Resolution: Invalid > Document new feature to set cache for Spring Data dynamically > - > > Key: IGNITE-12643 > URL: https://issues.apache.org/jira/browse/IGNITE-12643 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Sergey Chernolyas >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-12643) Document new feature to set cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov reopened IGNITE-12643: > Document new feature to set cache for Spring Data dynamically > - > > Key: IGNITE-12643 > URL: https://issues.apache.org/jira/browse/IGNITE-12643 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Sergey Chernolyas >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads
[ https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12676: Description: Add partition-based AffinityCall and AffinityRun overloads to ICompute.See corresponding methods in Java (IgniteCompute). Additionally, current affinity methods work through PlatformAbstractTask, which does not lock partitions. We should refactor existing AffinityCall and AffinityRun overloads to call corresponding IgniteCompute APIs. was: Add partition-based AffinityCall and AffinityRun overloads to ICompute. See corresponding methods in Java (IgniteCompute). > .NET: Add partition-based AffinityCall and AffinityRun overloads > > > Key: IGNITE-12676 > URL: https://issues.apache.org/jira/browse/IGNITE-12676 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, newbie > > Add partition-based AffinityCall and AffinityRun overloads to ICompute.See > corresponding methods in Java (IgniteCompute). > Additionally, current affinity methods work through PlatformAbstractTask, > which does not lock partitions. We should refactor existing AffinityCall and > AffinityRun overloads to call corresponding IgniteCompute APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036268#comment-17036268
]
Ivan Pavlukhin commented on IGNITE-12610:
-
[~artsiom_panko], thank you for the patch. I will check it by the end of this
week.
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12678) GridLongList fails on add when created with explicit zero size
Konstantin Orlov created IGNITE-12678: - Summary: GridLongList fails on add when created with explicit zero size Key: IGNITE-12678 URL: https://issues.apache.org/jira/browse/IGNITE-12678 Project: Ignite Issue Type: Bug Components: data structures Reporter: Konstantin Orlov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12677) Extend test coverage for GridLongList serialization
Konstantin Orlov created IGNITE-12677: - Summary: Extend test coverage for GridLongList serialization Key: IGNITE-12677 URL: https://issues.apache.org/jira/browse/IGNITE-12677 Project: Ignite Issue Type: Task Components: binary Reporter: Konstantin Orlov Assignee: Konstantin Orlov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12624) Java thin client: Wrong typeId generation for system types
[
https://issues.apache.org/jira/browse/IGNITE-12624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036256#comment-17036256
]
Ivan Pavlukhin commented on IGNITE-12624:
-
[~alex_pl], the patch looks good to me.
> Java thin client: Wrong typeId generation for system types
> --
>
> Key: IGNITE-12624
> URL: https://issues.apache.org/jira/browse/IGNITE-12624
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Thin client generates wrong {{typeId}} for system types. This is caused by
> {{ClientMarshallerContext}} implementation, which always returns {{false}}
> for {{isSystemType}} method. These leads to {{typeId}} duplication for the
> same class and assertions when trying to get object by thick client.
> Reproducer:
> {code:java}
> thinClient.cache(DEFAULT_CACHE_NAME).put(1, CacheAtomicityMode.ATOMIC);
> thickClient.cache(DEFAULT_CACHE_NAME).get(1);
> {code}
> Assertion:
>
> {noformat}
> java.lang.AssertionError: Duplicate typeId [typeId=1984564222, cls=class
> org.apache.ignite.cache.CacheAtomicityMode, desc=BinaryClassDescriptor
> [cls=class org.apache.ignite.cache.CacheAtomicityMode, serializer=null,
> initialSerializer=null, mapper=BinaryInternalMapper
> [nameMapper=BinaryBaseNameMapper [isSimpleName=true],
> idMapper=BinaryBaseIdMapper [isLowerCase=true], checkOnZeroId=false],
> mode=OPTIMIZED, userType=false, typeId=329149470,
> typeName=org.apache.ignite.cache.CacheAtomicityMode, affKeyFieldName=null,
> ctor=null, writeReplacer=null, readResolveMtd=null, stableSchema=null,
> schemaReg=org.apache.ignite.internal.binary.BinarySchemaRegistry@167f45f8,
> registered=true, useOptMarshaller=true, excluded=false,
> stableSchemaPublished=false]]
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:775)
> at
> org.apache.ignite.internal.binary.BinaryUtils.resolveClass(BinaryUtils.java:1669)
> at
> org.apache.ignite.internal.binary.BinaryEnumObjectImpl.deserialize(BinaryEnumObjectImpl.java:178)
> at
> org.apache.ignite.internal.binary.BinaryEnumObjectImpl.value(BinaryEnumObjectImpl.java:284)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:176)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:136)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1814)
> {noformat}
> If we perform "put" operation with value of the same type from thick client
> before "get" operation, there is no assertion anymore, but {{typeId}} is
> still duplicated. And there is another issue: different marshallers can be
> used to marshal the same class for thin and thick clients, wrong class
> descriptor is returned for class name and there is assertion again.
> Reproducer:
> {code:java}
> thickClient.cache(DEFAULT_CACHE_NAME).put(3, Collections.emptyList());
> thinClient.cache(DEFAULT_CACHE_NAME).put(2, Collections.emptyList());
> thickClient.cache(DEFAULT_CACHE_NAME).get(2);
> {code}
> Assertion:
> {noformat}
> java.lang.AssertionError: OptimizedMarshaller should not be used here:
> java.util.Collections$EmptyList
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:865)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:792)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:176)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads
Pavel Tupitsyn created IGNITE-12676: --- Summary: .NET: Add partition-based AffinityCall and AffinityRun overloads Key: IGNITE-12676 URL: https://issues.apache.org/jira/browse/IGNITE-12676 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Add partition-based AffinityCall and AffinityRun overloads to ICompute. See corresponding methods in Java (IgniteCompute). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12673) ML examples logging
[ https://issues.apache.org/jira/browse/IGNITE-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev reassigned IGNITE-12673: Assignee: Alexey Zinoviev > ML examples logging > --- > > Key: IGNITE-12673 > URL: https://issues.apache.org/jira/browse/IGNITE-12673 > Project: Ignite > Issue Type: Bug > Components: examples, ml >Affects Versions: 2.8 >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Major > > Compile of several minor fixes for ML examples: > 1. In TutorialStepByStepExample we running 17 examples > First 12 logging is pretty good and looks like "Tutorial step N: name" -> > model -> accuracy -> "Tutorial step N: completed" > But then starting with 13 this pattern is kind of broke, step start and step > completion is missing > 2. Step_8_CV_with_Param_Grid_and_metrics_and_pipeline is haven't step > completion log > 3. Complete log for Step_9_Scaling_With_Stacking looks like 'Tutorial step 5 > (scaling) example completed' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12067) SQL: metrics of executions of user queries
[
https://issues.apache.org/jira/browse/IGNITE-12067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036241#comment-17036241
]
Ignite TC Bot commented on IGNITE-12067:
{panel:title=Branch: [pull/7412/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5045032buildTypeId=IgniteTests24Java8_RunAll]
> SQL: metrics of executions of user queries
> --
>
> Key: IGNITE-12067
> URL: https://issues.apache.org/jira/browse/IGNITE-12067
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: IEP-35
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Lets add:
> - Counter of success executed user queries.
> - Counter of failed executed user queries.
> - Counter of cancelled user queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12675) Binary types registered in two stages when entry processor is used
Konstantin Orlov created IGNITE-12675: - Summary: Binary types registered in two stages when entry processor is used Key: IGNITE-12675 URL: https://issues.apache.org/jira/browse/IGNITE-12675 Project: Ignite Issue Type: Bug Components: binary Reporter: Konstantin Orlov When you try to add new value with entry processor, binary type registration proceeded in two stages: - class registration - binary metadata registration Perhaps it could be achieved by only one stage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12674) Extend test coverage for binary types registration
Konstantin Orlov created IGNITE-12674: - Summary: Extend test coverage for binary types registration Key: IGNITE-12674 URL: https://issues.apache.org/jira/browse/IGNITE-12674 Project: Ignite Issue Type: Task Components: binary Reporter: Konstantin Orlov Assignee: Konstantin Orlov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12628) Add tests for jmx metrics return types
[
https://issues.apache.org/jira/browse/IGNITE-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036179#comment-17036179
]
Ignite TC Bot commented on IGNITE-12628:
{panel:title=Branch: [pull/7369/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4990139buildTypeId=IgniteTests24Java8_RunAll]
> Add tests for jmx metrics return types
> --
>
> Key: IGNITE-12628
> URL: https://issues.apache.org/jira/browse/IGNITE-12628
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Malinovskiy
>Assignee: Vladimir Malinovskiy
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add tests than check if JMX metrics comply with Oracle best
> practices([https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html])
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12672) Query annotations are not working if statement keywords are in lower case
[ https://issues.apache.org/jira/browse/IGNITE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-12672: - Reviewer: Ilya Kasnacheev > Query annotations are not working if statement keywords are in lower case > - > > Key: IGNITE-12672 > URL: https://issues.apache.org/jira/browse/IGNITE-12672 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > SQL queries defined using > org.apache.ignite.springdata.repository.config.Query annotations are not > working if key words (such as UPDATE or DELETE) are written using lower case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12638) Classes persisted by DistributedMetaStorage are not IgniteDTO
[
https://issues.apache.org/jira/browse/IGNITE-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036161#comment-17036161
]
Ignite TC Bot commented on IGNITE-12638:
{panel:title=Branch: [pull/7383/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5046457buildTypeId=IgniteTests24Java8_RunAll]
> Classes persisted by DistributedMetaStorage are not IgniteDTO
> -
>
> Key: IGNITE-12638
> URL: https://issues.apache.org/jira/browse/IGNITE-12638
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This has to be fixed to simplify future modification of component.
> DistributedMetaStorageHistoryItem and DistributedMetaStorageVersion will be
> persisted on disc so we need to have a reliable way to read them even when
> classes will be updated in the future. IgniteDataTransferObject is the
> standard option for such cases - it allows versioning of serialization format.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12643) Document new feature to set cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chernolyas updated IGNITE-12643: --- Summary: Document new feature to set cache for Spring Data dynamically (was: It is needed to set used cache for Spring Data dynamically) > Document new feature to set cache for Spring Data dynamically > - > > Key: IGNITE-12643 > URL: https://issues.apache.org/jira/browse/IGNITE-12643 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Sergey Chernolyas >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12673) ML examples logging
Stepan Pilschikov created IGNITE-12673: -- Summary: ML examples logging Key: IGNITE-12673 URL: https://issues.apache.org/jira/browse/IGNITE-12673 Project: Ignite Issue Type: Bug Components: examples, ml Affects Versions: 2.8 Reporter: Stepan Pilschikov Compile of several minor fixes for ML examples: 1. In TutorialStepByStepExample we running 17 examples First 12 logging is pretty good and looks like "Tutorial step N: name" -> model -> accuracy -> "Tutorial step N: completed" But then starting with 13 this pattern is kind of broke, step start and step completion is missing 2. Step_8_CV_with_Param_Grid_and_metrics_and_pipeline is haven't step completion log 3. Complete log for Step_9_Scaling_With_Stacking looks like 'Tutorial step 5 (scaling) example completed' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12672) Query annotations are not working if statement keywords are in lower case
Evgeniy Rudenko created IGNITE-12672: Summary: Query annotations are not working if statement keywords are in lower case Key: IGNITE-12672 URL: https://issues.apache.org/jira/browse/IGNITE-12672 Project: Ignite Issue Type: Bug Components: sql Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko Fix For: 2.9 SQL queries defined using org.apache.ignite.springdata.repository.config.Query annotations are not working if key words (such as UPDATE or DELETE) are written using lower case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8571: Labels: IEP-4 Phase-2 important (was: IEP-4 Phase-2) > Baseline auto-adjust feature > > > Key: IGNITE-8571 > URL: https://issues.apache.org/jira/browse/IGNITE-8571 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2, important > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Now we have only one way to change BLAT - manually update it via console.sh > or API. > We need to add the possibility to change it automatically. Adjust to current > topology. > So, I propose 2 new distributed parameters which would be responsible to tune > this feature. > 1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto > adjusting baseline. > 2. autoAdjustTimeout - time which we would wait after the actual topology > change. But it would be reset if new discovery event happened. (node > join/exit). > We need to change API next way: > org.apache.ignite.IgniteCluster: > * isBaselineAutoAdjustEnabled() > * setBaselineAutoAdjustEnabled(boolean enabled); > * setBaselineAutoAdjustTimeout(long timeoutInMs); > Also, we need to ensure that all nodes would have the same > parameters(distributed parameters). > And we should be able to survive coordinator left during parameters changes. > When autoAdjustEnabled is true we should be block ability to manual baseline > change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12507) Implement cache size metric in bytes
[ https://issues.apache.org/jira/browse/IGNITE-12507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036101#comment-17036101 ] Artsiom Panko commented on IGNITE-12507: [~ivan.glukos], can you provide any steps to reproduce "When all data is in RAM [...] the only things that *could be watched* on is number of keys in partition on a specific node and memory usage metrics on the machine." And what is the difference between "... cache size in bytes metric for pure in-memory case." and "... and memory usage metrics on the machine."? > Implement cache size metric in bytes > > > Key: IGNITE-12507 > URL: https://issues.apache.org/jira/browse/IGNITE-12507 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Priority: Major > Labels: newbie > Fix For: 2.9 > > > There is a need to have cache size in bytes metric for pure in-memory case. > When all data is in RAM, it is not obvious to find out exactly how much space > is consumed by cache data on a running node as the only things that could be > watched on is number of keys in partition on a specific node and memory usage > metrics on the machine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12315) In case of using ArrayBlockingQueue as key, cache.get() returns null.
[
https://issues.apache.org/jira/browse/IGNITE-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036095#comment-17036095
]
Artsiom Panko commented on IGNITE-12315:
[~alapin], getting is not cool, but what exactly needs to be done?
Replace all "ArrayBlockingQueue" to "ArrayList or LinkedList"?
Or create a custom method which will enable to get cache value via
ArrayBlockingQueue as key?
> In case of using ArrayBlockingQueue as key, cache.get() returns null.
> -
>
> Key: IGNITE-12315
> URL: https://issues.apache.org/jira/browse/IGNITE-12315
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: newbie
>
> In case of using ArrayBlockingQueue as key, cache.get() returns null. In case
> of using ArrayList or LinkedList everything works as expected.
> {code:java}
> ArrayBlockingQueue queueToCheck = new ArrayBlockingQueue<>(5);
> queueToCheck.addAll(Arrays.asList(1, 2, 3));
> cache.put(queueToCheck, "aaa");
> cache.get(queueToCheck); // returns null
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-8414. Assignee: (was: Eduard Shangareev) Resolution: Duplicate Baseline topology support for in-memory caches was introduced in IGNITE-8571 > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11798) Memory leak on unstable topology caused by partition reservation
[ https://issues.apache.org/jira/browse/IGNITE-11798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036075#comment-17036075 ] Andrey Mashenkov commented on IGNITE-11798: --- LGTM, merged to master. Thanks for contribution! > Memory leak on unstable topology caused by partition reservation > > > Key: IGNITE-11798 > URL: https://issues.apache.org/jira/browse/IGNITE-11798 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Attachments: PartitionReservationReproducer.java > > Time Spent: 20m > Remaining Estimate: 0h > > Executing queries on unstable topology leads to OOM caused by leak of the > partition reservation. > The reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-9325) Add to all command-line utility ability to make sound after complite execution
[ https://issues.apache.org/jira/browse/IGNITE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035353#comment-17035353 ] Artsiom Panko edited comment on IGNITE-9325 at 2/13/20 9:14 AM: [~ARomantsov], is this ticket still actual? If yes: 1) How can i reproduce "clusters over ssh" 2) "I would like to have +same+ functionality in the product" where I can try this functionality? Any example? was (Author: artsiom_panko): [~ARomantsov], is this ticket still actual? If yes: 1) How can i reproduce "clusters over ssh and there are situations" 2) "I would like to have +same+ functionality in the product" where I can try this functionality? Any example? > Add to all command-line utility ability to make sound after complite execution > -- > > Key: IGNITE-9325 > URL: https://issues.apache.org/jira/browse/IGNITE-9325 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Artsiom Panko >Priority: Major > Labels: command-line, newbie > Fix For: 2.9 > > > Often I work simultaneously on several clusters over ssh and there are > situations when I forget to check that the first cluster has completed the > command (for example, activation), while working on the second. > Because of this, I would like to have same functionality in the product -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-9325) Add to all command-line utility ability to make sound after complite execution
[ https://issues.apache.org/jira/browse/IGNITE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035353#comment-17035353 ] Artsiom Panko edited comment on IGNITE-9325 at 2/13/20 9:14 AM: [~ARomantsov], is this ticket still actual? If yes: 1) How can i reproduce "clusters over ssh and there are situations" 2) "I would like to have +same+ functionality in the product" where I can try this functionality? Any example? was (Author: artsiom_panko): [~ARomantsov], this ticket is still actual? If yes: 1) How can i reproduce "clusters over ssh and there are situations" 2) "I would like to have +same+ functionality in the product" where I can try this functionality? Any example? > Add to all command-line utility ability to make sound after complite execution > -- > > Key: IGNITE-9325 > URL: https://issues.apache.org/jira/browse/IGNITE-9325 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Artsiom Panko >Priority: Major > Labels: command-line, newbie > Fix For: 2.9 > > > Often I work simultaneously on several clusters over ssh and there are > situations when I forget to check that the first cluster has completed the > command (for example, activation), while working on the second. > Because of this, I would like to have same functionality in the product -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12664) Failed to dump debug information. Failed to create string representation of binary object.
[
https://issues.apache.org/jira/browse/IGNITE-12664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036053#comment-17036053
]
Yury Gerzhedovich commented on IGNITE-12664:
[~Pavlukhin], LGTM. Let's merge it.
> Failed to dump debug information. Failed to create string representation of
> binary object.
> --
>
> Key: IGNITE-12664
> URL: https://issues.apache.org/jira/browse/IGNITE-12664
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Logging long transactions warning fails:
> {noformat}
> Dec 12, 2019 12:18:09 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to dump debug information: class o.a.i.IgniteException: Failed
> to create string representation of binary object.
> class org.apache.ignite.IgniteException: Failed to create string
> representation of binary object.
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1021)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:761)
>
> Caused by: java.lang.ClassNotFoundException:
> org.springframework.security.core.authority.SimpleGrantedAuthority
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> {noformat}
> We are using replicated cache: Cache sessionsCache
> where MapSession is:
> {code}
> public final class MapSession implements ExpiringSession, Serializable {
> public static final int DEFAULT_MAX_INACTIVE_INTERVAL_SECONDS = 1800;
> private String id;
> private Map sessionAttrs;
> private long creationTime;
> private long lastAccessedTime;
> private int maxInactiveInterval;
> private static final long serialVersionUID = 7160779239673823561L;
> {code}
> and sessionAttrs contains SimpleGrantedAuthority.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12665) SQL: Potential race on MapResult close.
[ https://issues.apache.org/jira/browse/IGNITE-12665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036043#comment-17036043 ] Taras Ledkov commented on IGNITE-12665: --- [~amashenkov], the patch is OK with me. > SQL: Potential race on MapResult close. > --- > > Key: IGNITE-12665 > URL: https://issues.apache.org/jira/browse/IGNITE-12665 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: refactoring > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Seems, a race possible on MapQueryResult*s*.close() as this code can be > called twice. > Let's rewrite it make sure every map result is closed via > MapQueryResult*s*.closeResult(int) method only. > Then allow cleanup once all map results are closed. > Then MapQueryResult*s*.allClosed() can be optimized as we always know number > of map results and all map results are closed via MapQueryResult*s* instance. > Seems, MepQueryExecutor.onQueryRequest0() has dead code. See > "res.openResult(rs)" call when 'null' passed as argument. > > Start point is MapQueryResult.openResult(res). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12589) Remote thin client operations are not authorized correctly.
[ https://issues.apache.org/jira/browse/IGNITE-12589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036044#comment-17036044 ] PetrovMikhail commented on IGNITE-12589: [~VeenaM], As far as I know, there is no workaround now. > Remote thin client operations are not authorized correctly. > --- > > Key: IGNITE-12589 > URL: https://issues.apache.org/jira/browse/IGNITE-12589 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: PetrovMikhail >Priority: Major > > In the current Ignite security approach security subject id is considered to > be a node id (see IgniteSecurityProcessor#withContext()). In the case of thin > clients, this approach doesn't work correctly. If some operation is executed > on behalf of the thin client on a remote node (node that is different from > one to which thin client connection was established), it's impossible in the > same way as for a node to obtain a thin client security subject information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12650) Mark MVCC with @IgniteExperimental annotation
[ https://issues.apache.org/jira/browse/IGNITE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-12650: - Assignee: Alexey Goncharuk > Mark MVCC with @IgniteExperimental annotation > - > > Key: IGNITE-12650 > URL: https://issues.apache.org/jira/browse/IGNITE-12650 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > MVCC should be marked with the @IgniteExperimental annotation. > * Beta version of Transactional SQL and MVCC > * In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to > allow users to experiment and share feedback. > * This version of Transactional SQL and MVCC should not be considered for > production. > [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12376) Change level of "TCP client created ..." log messages to WARN
[
https://issues.apache.org/jira/browse/IGNITE-12376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036038#comment-17036038
]
Ignite TC Bot commented on IGNITE-12376:
{panel:title=Branch: [pull/7090/head] Base: [master] : Possible Blockers
(107)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5046527]]
* IgniteCacheTestSuite6:
GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5046497]]
* ZookeeperDiscoverySpiTestSuite2:
GridCachePartitionedNodeRestartTest.testRestartWithPutEightNodesTwoBackups -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerTest.testReadOnlyEnableDisable - Test has low fail rate in
base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testHelp - Test has low fail rate in base
branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheHelp - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5046526]]
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeWithBackupsAfterKillCrdWithPersistence[TRANSACTIONAL]
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5046528]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5046543]]
* exe: JniThreadDetachTest.TestUseIgniteFromClrThreadsDoesNotLeakJvmThreads -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}JCache TCK 1.1{color} [[tests 90 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5046503]]
* org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingPutIfAbsent -
Test has low fail rate in base branch 0,0% and is not flaky
*
org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadWithNullKeyUsingLoadAll
- Test has low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingGetAndRemove -
Test has low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadDueToIteration - Test
has low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingPutAll - Test
has low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingRemove - Test
has low fail rate in base branch 0,0% and is not flaky
*
org.jsr107.tck.integration.CacheLoaderTest.testLoadAllWithExecptionAndNoCompletionListener
- Test has low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingReplace - Test
has low fail rate in base branch 0,0% and is not flaky
*
org.jsr107.tck.integration.CacheLoaderTest.shouldLoadMultipleExistingEntryUsingLoadAll
- Test has low fail rate in base branch 0,0% and is not flaky
*
org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingGetWithExistingValue
- Test has low fail rate in base branch 0,0% and is not flaky
*
org.jsr107.tck.integration.CacheLoaderTest.shouldPropagateExceptionUsingLoadAll
- Test has low fail rate in base branch 0,0% and is not flaky
... and 79 tests blockers
{color:#d04437}Basic 3{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5046502]]
* IgniteBasicWithPersistenceTestSuite:
GridCommandHandlerClusterByClassTest.testHelp - Test has low fail rate in base
branch 0,0% and is not flaky
* IgniteBasicWithPersistenceTestSuite:
GridCommandHandlerClusterByClassTest.testCacheHelp - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}PDS (Compatibility)*{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5046536]]
* IgniteCompatibilityBasicTestSuite:
MigratingToWalV2SerializerWithCompactionTest.testCompactingOldWalFiles - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Thin client: Node.js{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5046500]]
* scan query test suite : scan query settings - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Continuous Query 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5046468]]
* IgniteCacheQuerySelfTestSuite3:
[jira] [Commented] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036037#comment-17036037 ] Alexey Scherbakov commented on IGNITE-8414: --- [~Pavlukhin] [The proof|https://issues.apache.org/jira/browse/IGNITE-12662?focusedCommentId=17035396=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17035396] > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036033#comment-17036033 ] Ivan Pavlukhin edited comment on IGNITE-8414 at 2/13/20 8:42 AM: - [~ascherbakov], [~akalashnikov], [~irakov], can you confirm that features described in this ticket are already implemented? Could you please resolve this ticket as a duplicate of one where it was already implemented? was (Author: pavlukhin): [~ascherbakov], [~akalashnikov], [~irakov], can confirm that features described in this ticket are already implemented? Could you please resolve this ticket as a duplicate of one where it was already implemented? > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036033#comment-17036033 ] Ivan Pavlukhin commented on IGNITE-8414: [~ascherbakov], [~akalashnikov], [~irakov], can confirm that features described in this ticket are already implemented? Could you please resolve this ticket as a duplicate of one where it was already implemented? > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12451) Introduce deadlock detection for cache entry reentrant locks
[ https://issues.apache.org/jira/browse/IGNITE-12451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-12451: Assignee: Mirza Aliev > Introduce deadlock detection for cache entry reentrant locks > > > Key: IGNITE-12451 > URL: https://issues.apache.org/jira/browse/IGNITE-12451 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Ivan Rakov >Assignee: Mirza Aliev >Priority: Major > Fix For: 2.9 > > > Aside from IGNITE-12365, we still have possible threat of cache-entry-level > deadlock in case of careless usage of JCache mass operations (putAll, > removeAll): > 1. If two different user threads will perform putAll on the same two keys in > reverse order (primary node for which is the same), there's a chance that > sys-stripe threads will be deadlocked. > 2. Even without direct contract violation from user side, HashMap can be > passed as argument for putAll. Even if user threads have called mass > operations with two keys in the same order, HashMap iteration order is not > strictly defined, which may cause the same deadlock. > Local deadlock detection should mitigate this issue. We can create a wrapper > for ReentrantLock with logic that performs cycle detection in wait-for graph > in case we are waiting for lock acquisition for too long. Exception will be > thrown from one of the threads in such case, failing user operation, but > letting the system make progress. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12582) It is needed to set used cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036032#comment-17036032 ] Alexey Scherbakov commented on IGNITE-12582: [~schernolyas] [~mstepachev] Looks good. Merged to master 465cc444d0bf69f230a7c6c9e429ff69851cba62. Thank for contribution. BTW, I see the same ticket [2], should it be closed as duplicate ? [2] https://issues.apache.org/jira/browse/IGNITE-12643 > It is needed to set used cache for Spring Data dynamically > -- > > Key: IGNITE-12582 > URL: https://issues.apache.org/jira/browse/IGNITE-12582 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.7.6 >Reporter: Sergey Chernolyas >Assignee: Sergey Chernolyas >Priority: Major > Fix For: 2.8.1 > > > Hi! > My project needs to configure used cache by property, like > ""[spring.data|http://spring.data/].mongodb.uri: > mongodb://:@:/" from Spring Data for > MongoDB. Now, I can set cache for particular repository by annotation > "RepositoryConfig" only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12669) Remove not used rebalanceDelay from production code
[
https://issues.apache.org/jira/browse/IGNITE-12669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov resolved IGNITE-12669.
Resolution: Invalid
> Remove not used rebalanceDelay from production code
> ---
>
> Key: IGNITE-12669
> URL: https://issues.apache.org/jira/browse/IGNITE-12669
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Currently, we've got rebalanceDelay property which is not used (in tests too)
> and persists in production code.
> Must be removed.
> {code:title=GridCachePartitionExchangeManager.java:288}
> /** Delay before rebalancing code is start executing after exchange
> completion. For tests only. */
> private volatile long rebalanceDelay;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12665) SQL: Potential race on MapResult close.
[ https://issues.apache.org/jira/browse/IGNITE-12665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036026#comment-17036026 ] Andrey Mashenkov commented on IGNITE-12665: --- [~tledkov-gridgain], please review. > SQL: Potential race on MapResult close. > --- > > Key: IGNITE-12665 > URL: https://issues.apache.org/jira/browse/IGNITE-12665 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: refactoring > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Seems, a race possible on MapQueryResult*s*.close() as this code can be > called twice. > Let's rewrite it make sure every map result is closed via > MapQueryResult*s*.closeResult(int) method only. > Then allow cleanup once all map results are closed. > Then MapQueryResult*s*.allClosed() can be optimized as we always know number > of map results and all map results are closed via MapQueryResult*s* instance. > Seems, MepQueryExecutor.onQueryRequest0() has dead code. See > "res.openResult(rs)" call when 'null' passed as argument. > > Start point is MapQueryResult.openResult(res). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12665) SQL: Potential race on MapResult close.
[
https://issues.apache.org/jira/browse/IGNITE-12665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036025#comment-17036025
]
Ignite TC Bot commented on IGNITE-12665:
{panel:title=Branch: [pull/7414/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5044053buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Potential race on MapResult close.
> ---
>
> Key: IGNITE-12665
> URL: https://issues.apache.org/jira/browse/IGNITE-12665
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: refactoring
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Seems, a race possible on MapQueryResult*s*.close() as this code can be
> called twice.
> Let's rewrite it make sure every map result is closed via
> MapQueryResult*s*.closeResult(int) method only.
> Then allow cleanup once all map results are closed.
> Then MapQueryResult*s*.allClosed() can be optimized as we always know number
> of map results and all map results are closed via MapQueryResult*s* instance.
> Seems, MepQueryExecutor.onQueryRequest0() has dead code. See
> "res.openResult(rs)" call when 'null' passed as argument.
>
> Start point is MapQueryResult.openResult(res).
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12669) Remove not used rebalanceDelay from production code
[
https://issues.apache.org/jira/browse/IGNITE-12669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036012#comment-17036012
]
Alexey Scherbakov commented on IGNITE-12669:
[~mmuzaf]
This property is used in tests [1], you should not remove it.
[1]
org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyTest#doTestConsistencyAfterBaselineNodeStopAndRemoval
> Remove not used rebalanceDelay from production code
> ---
>
> Key: IGNITE-12669
> URL: https://issues.apache.org/jira/browse/IGNITE-12669
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Currently, we've got rebalanceDelay property which is not used (in tests too)
> and persists in production code.
> Must be removed.
> {code:title=GridCachePartitionExchangeManager.java:288}
> /** Delay before rebalancing code is start executing after exchange
> completion. For tests only. */
> private volatile long rebalanceDelay;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
