[jira] [Updated] (IGNITE-12533) Remote security context tests refactoring.
[ https://issues.apache.org/jira/browse/IGNITE-12533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-12533: -- Fix Version/s: 2.9 > Remote security context tests refactoring. > -- > > Key: IGNITE-12533 > URL: https://issues.apache.org/jira/browse/IGNITE-12533 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > To make tests more readable and robust, we should use the > _AbstractRemoteSecurityContextCheckTest.Verifier#register(String)_ method in > all related tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021255#comment-17021255
]
Andrey N. Gura commented on IGNITE-12568:
-
[~ibessonov] Good point about extensions. I need additional time to think about
it.
About performance... Also good idea. But we should measure all three solution
in order to choose the best of them.
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
> start node and print error message.
> *Proposed implementation:*
> Instead of {{switch-case}} block new array of size 2^16 should be created.
> Each array cell should contain message default constructor reference or
> lambda which is responsible for message instance creation. So during message
> unmarshaling system just lookup ctor-ref or lambda from array by index and
> invoke it in order to create proper message instance.
> All message factory extensions and custom message should be registered at the
> same array before communication SPI will be started.
> If we try to register message with direct type for which already exists
> registered message then node start process must be terminated (directly, with
> out any failure handlers).
> If we get message with unknown direct type (there is now registered message
> for this direct type) then failure handler be invoked.
> It could affect perfromance so we should run microbenchmark for this change.
> Additional benefit of this change is improving code readability. At present
> we have the following code:
> {code:java}
> @Override public Message create(short type) {
> Message msg = null;
> switch (type) {
> case -61:
> msg = new IgniteDiagnosticMessage();
> break;
> case -53:
> msg = new SchemaOperationStatusMessage();
> break;
> // etc.
> }
> {code}
> After refactoring it will looks like:
> {code:java}
> private Supplier[] msgCtrs;
> public GridIoMessageFactory(MessageFactory[] ext) {
> this.ext = ext;
>registerMessage(-61, IgniteDiagnosticMessage::new)
>registerMessage(-53, SchemaOperationStatusMessage::new)
> }
> @Override public Message create(short type) {
> return msgCtros[type].get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-12549: --- Assignee: Sergey Kosarev > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6804:
Comment: was deleted
(was: {panel:title=Branch: [pull/6976/head] Base: [master] : Possible Blockers
(109)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4947291]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
105|https://ci.ignite.apache.org/viewLog.html?buildId=4947261]]
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testPutxIfAbsentAsync - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testRemoveAllSkipStore - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testNoReadThroughTx - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testPutIfAbsent - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testRemoveAllDuplicatesTx - Test
has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testGetAndPutObject - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testContainsKeyTx - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testLoadAll - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testGetAndPutIfAbsent - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCacheReplicatedMultiNodeFullApiSelfTest.testTransformAllWithNulls - Test
has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerTest.testBaselineAutoAdjustmentAutoRemoveNode - Test has low
fail rate in base branch 0,0% and is not flaky
... and 94 tests blockers
{color:#d04437}Cache 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=4947287]]
* IgniteCacheTestSuite2:
GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticRepeatableReadRollback
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite2:
GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticReadCommittedCommit
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4947306]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4947337buildTypeId=IgniteTests24Java8_RunAll])
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap,
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element.
> However, we should make sure that we only print that warning once and not
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021237#comment-17021237
]
Ignite TC Bot commented on IGNITE-6804:
---
{panel:title=Branch: [pull/6976/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=4947337buildTypeId=IgniteTests24Java8_RunAll]
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap,
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element.
> However, we should make sure that we only print that warning once and not
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021208#comment-17021208
]
Ivan Bessonov edited comment on IGNITE-12568 at 1/22/20 3:56 PM:
-
[~agura] I believe that we'll face an issue with encapsulation.
>From what I can tell, you mean "GridIoMessageFactory" here and we should
>inline extension message factories inside of it. But it's not clear how it can
>be done - those extension factories may not have the same array and there's no
>way of getting the required information from them rather than brute force. Is
>that acceptable?
Another concern - what will happen with performance? I can't predict anything,
but I propose 3rd way of creating messages - storing prototype objects for each
message type and cloning them when needed. Might be a good solution considering
that extension factories won't give us their lambdas to create messages. What
do you think?
was (Author: ibessonov):
[~agura] I believe that we'll face an issue with encapsulation.
>From what I can tell, you mean "GridIoMessageFactory" here and we should
>inline extension message factories inside of it. But it's not clear how it can
>be done - those extension factories may not have the same array and there's no
>way of getting the required information from them rather then brute force. Is
>that acceptable?
Another concern - what will happen with performance? I can't predict anything,
but I propose 3rd way of creating messages - storing prototype objects for each
message type and cloning them when needed. Might be a good solution considering
that extension factories won't give us their lambdas to create messages. What
do you think?
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
> start node and print error message.
> *Proposed implementation:*
> Instead of {{switch-case}} block new array of size 2^16 should be created.
> Each array cell should contain message default constructor reference or
> lambda which is responsible for message instance creation. So during message
> unmarshaling system just lookup ctor-ref or lambda from array by index and
> invoke it in order to create proper message instance.
> All message factory extensions and custom message should be registered at the
> same array before communication SPI will be started.
> If we try to register message with direct type for which already exists
> registered message then node start process must be terminated (directly, with
> out any failure handlers).
> If we get message with unknown direct type (there is now registered message
> for this direct type) then failure handler be invoked.
> It could affect perfromance so we should run microbenchmark for this change.
> Additional benefit of this change is improving code readability. At present
> we have the following code:
> {code:java}
> @Override public Message create(short type) {
> Message msg = null;
> switch (type) {
> case -61:
> msg = new IgniteDiagnosticMessage();
> break;
> case -53:
> msg = new SchemaOperationStatusMessage();
> break;
> // etc.
> }
> {code}
> After refactoring it will looks like:
> {code:java}
> private Supplier[] msgCtrs;
> public GridIoMessageFactory(MessageFactory[] ext) {
> this.ext = ext;
>registerMessage(-61, IgniteDiagnosticMessage::new)
>registerMessage(-53, SchemaOperationStatusMessage::new)
> }
> @Override public Message create(short type) {
> return msgCtros[type].get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021208#comment-17021208
]
Ivan Bessonov commented on IGNITE-12568:
[~agura] I believe that we'll face an issue with encapsulation.
>From what I can tell, you mean "GridIoMessageFactory" here and we should
>inline extension message factories inside of it. But it's not clear how it can
>be done - those extension factories may not have the same array and there's no
>way of getting the required information from them rather then brute force. Is
>that acceptable?
Another concern - what will happen with performance? I can't predict anything,
but I propose 3rd way of creating messages - storing prototype objects for each
message type and cloning them when needed. Might be a good solution considering
that extension factories won't give us their lambdas to create messages. What
do you think?
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
> start node and print error message.
> *Proposed implementation:*
> Instead of {{switch-case}} block new array of size 2^16 should be created.
> Each array cell should contain message default constructor reference or
> lambda which is responsible for message instance creation. So during message
> unmarshaling system just lookup ctor-ref or lambda from array by index and
> invoke it in order to create proper message instance.
> All message factory extensions and custom message should be registered at the
> same array before communication SPI will be started.
> If we try to register message with direct type for which already exists
> registered message then node start process must be terminated (directly, with
> out any failure handlers).
> If we get message with unknown direct type (there is now registered message
> for this direct type) then failure handler be invoked.
> It could affect perfromance so we should run microbenchmark for this change.
> Additional benefit of this change is improving code readability. At present
> we have the following code:
> {code:java}
> @Override public Message create(short type) {
> Message msg = null;
> switch (type) {
> case -61:
> msg = new IgniteDiagnosticMessage();
> break;
> case -53:
> msg = new SchemaOperationStatusMessage();
> break;
> // etc.
> }
> {code}
> After refactoring it will looks like:
> {code:java}
> private Supplier[] msgCtrs;
> public GridIoMessageFactory(MessageFactory[] ext) {
> this.ext = ext;
>registerMessage(-61, IgniteDiagnosticMessage::new)
>registerMessage(-53, SchemaOperationStatusMessage::new)
> }
> @Override public Message create(short type) {
> return msgCtros[type].get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12569) Can't set serialized enum to a BinaryObject's field
[
https://issues.apache.org/jira/browse/IGNITE-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021180#comment-17021180
]
Ivan Pavlukhin commented on IGNITE-12569:
-
[~korlov], LGTM. I will merge it once visa is ready.
> Can't set serialized enum to a BinaryObject's field
> ---
>
> Key: IGNITE-12569
> URL: https://issues.apache.org/jira/browse/IGNITE-12569
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The deserialization of the BinaryObject fails since a serialized
> representation of the enum was set to a field instead of the enum itself.
> Because of this issue there is no way to work with enums without a
> corresponding class.
> Error message thrown during the deserialization:
> {noformat}[18:03:06,159][ERROR][main][BinaryContext] Failed to deserialize
> object [typeName=binary.BinaryEnumExample$TestClass]
> org.apache.ignite.binary.BinaryObjectException: Failed to read field
> [name=theEnum]
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:191)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> [classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> [classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> [classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> [classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:636)
> [classes/:?]
> at binary.BinaryEnumExample.main(BinaryEnumExample.java:20) [classes/:?]
> Caused by: org.apache.ignite.binary.BinaryObjectException: Unexpected field
> type [pos=24, expected=Enum, actual=Enum]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1677)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1403)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1387)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:885)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> ~[classes/:?]
> ... 6 more
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Failed to deserialize object
> [typeName=binary.BinaryEnumExample$TestClass]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:926)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:636)
> at binary.BinaryEnumExample.main(BinaryEnumExample.java:20)
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> read field [name=theEnum]
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:191)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> ... 5 more
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Unexpected
> field type [pos=24, expected=Enum, actual=Enum]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1677)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1403)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1387)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:885)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> ... 6
[jira] [Updated] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12568:
Description:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
If we try to register message with direct type for which already exists
registered message then node start process must be terminated (directly, with
out any failure handlers).
If we get message with unknown direct type (there is now registered message for
this direct type) then failure handler be invoked.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].get();
}
{code}
was:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].get();
}
{code}
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to
[jira] [Commented] (IGNITE-11927) [IEP-35] Add ability to enable\disable subset of metrics
[
https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021169#comment-17021169
]
Andrey N. Gura commented on IGNITE-11927:
-
Just note: current implementation of metrics
{{communication.sentMessagesByType.}} and
{{communication.receivedMessagesByType.}} don fit into new metrics
registry design due to metric registry immutability. From other hand we can't
create one metric registry for all message types becase there is no any
information about known message types in the system (except of {{Message}}
interface). IGNITE-12568 should solve this problem.
> [IEP-35] Add ability to enable\disable subset of metrics
>
>
> Key: IGNITE-11927
> URL: https://issues.apache.org/jira/browse/IGNITE-11927
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: IEP-35
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite should be able to:
> * Enable or disable an arbitrary subset of the metrics. User should be able
> to do it in runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12568:
Description:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].get();
}
{code}
was:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].apply();
}
{code}
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
>
[jira] [Updated] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12568:
Description:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].apply();
}
{code}
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
> start node and print error message.
> *Proposed implementation:*
> Instead of {{switch-case}} block new array of size 2^16 should be created.
> Each array cell should contain message default constructor reference or
> lambda which is responsible for message instance creation. So during message
> unmarshaling system just lookup ctor-ref or lambda from array by index and
> invoke it in order to create proper message instance.
> All message factory extensions and custom message should be registered at the
> same array before communication SPI will be started.
> It could affect perfromance so we should run microbenchmark for this change.
> Additional benefit of this change is improving code readability. At present
> we have the following code:
> {code:java}
> @Override public Message create(short type) {
> Message msg = null;
> switch (type) {
> case -61:
> msg = new IgniteDiagnosticMessage();
> break;
> case -53:
> msg = new SchemaOperationStatusMessage();
> break;
> // etc.
> }
> {code}
> After refactoring it will looks like:
> {code:java}
> private Supplier[] msgCtrs;
> public GridIoMessageFactory(MessageFactory[] ext) {
> this.ext = ext;
>registerMessage(-61, IgniteDiagnosticMessage::new)
>registerMessage(-53, SchemaOperationStatusMessage::new)
> }
> @Override public Message create(short type) {
> return msgCtros[type].apply();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12569) Can't set serialized enum to a BinaryObject's field
Konstantin Orlov created IGNITE-12569:
-
Summary: Can't set serialized enum to a BinaryObject's field
Key: IGNITE-12569
URL: https://issues.apache.org/jira/browse/IGNITE-12569
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov
The deserialization of the BinaryObject fails since a serialized representation
of the enum was set to a field instead of the enum itself. Because of this
issue there is no way to work with enums without a corresponding class.
Error message thrown during the deserialization:
{noformat}[18:03:06,159][ERROR][main][BinaryContext] Failed to deserialize
object [typeName=binary.BinaryEnumExample$TestClass]
org.apache.ignite.binary.BinaryObjectException: Failed to read field
[name=theEnum]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:191)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
[classes/:?]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
[classes/:?]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
[classes/:?]
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
[classes/:?]
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:636)
[classes/:?]
at binary.BinaryEnumExample.main(BinaryEnumExample.java:20) [classes/:?]
Caused by: org.apache.ignite.binary.BinaryObjectException: Unexpected field
type [pos=24, expected=Enum, actual=Enum]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1677)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1403)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1387)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:885)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
~[classes/:?]
... 6 more
Exception in thread "main" class
org.apache.ignite.binary.BinaryObjectException: Failed to deserialize object
[typeName=binary.BinaryEnumExample$TestClass]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:926)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:636)
at binary.BinaryEnumExample.main(BinaryEnumExample.java:20)
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to read
field [name=theEnum]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:191)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
... 5 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Unexpected
field type [pos=24, expected=Enum, actual=Enum]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1677)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1403)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1387)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:885)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
... 6 more{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12568) MessageFactory implementations refactoring
[ https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-12568: Ignite Flags: (was: Docs Required,Release Notes Required) > MessageFactory implementations refactoring > -- > > Key: IGNITE-12568 > URL: https://issues.apache.org/jira/browse/IGNITE-12568 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12568) MessageFactory implementations refactoring
Andrey N. Gura created IGNITE-12568: --- Summary: MessageFactory implementations refactoring Key: IGNITE-12568 URL: https://issues.apache.org/jira/browse/IGNITE-12568 Project: Ignite Issue Type: Improvement Reporter: Andrey N. Gura Assignee: Andrey N. Gura -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12567) H2Tree goes into illegal state when non-indexed columns are dropped
[
https://issues.apache.org/jira/browse/IGNITE-12567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021102#comment-17021102
]
Ivan Pavlukhin edited comment on IGNITE-12567 at 1/22/20 2:21 PM:
--
[~korlov], LGTM. I will merge it once visa is ready.
was (Author: pavlukhin):
[~korlov], LGTM. I will merged it once visa is ready.
> H2Tree goes into illegal state when non-indexed columns are dropped
> ---
>
> Key: IGNITE-12567
> URL: https://issues.apache.org/jira/browse/IGNITE-12567
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *How to reproduce:*
> * {{CREATE TABLE tbl (f0 INT, f1 INT, f2 INT, f3 INT, f4 INT, PRIMARY KEY
> (f3, f4))}}
> * populate table with some data
> * {{ALTER TABLE tbl DROP COLUMN f1, f2}}
> * try to execute query which will use pk index: {{SELECT * FROM tbl WHERE f3
> = 1 AND f4 = 1}}
> *Expected*:
> * Query returns result set
> *Actual*:
> * Query fails with {{General error:
> "java.lang.ArrayIndexOutOfBoundsException: 5";}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12567) H2Tree goes into illegal state when non-indexed columns are dropped
[
https://issues.apache.org/jira/browse/IGNITE-12567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021102#comment-17021102
]
Ivan Pavlukhin commented on IGNITE-12567:
-
[~korlov], LGTM. I will merged it once visa is ready.
> H2Tree goes into illegal state when non-indexed columns are dropped
> ---
>
> Key: IGNITE-12567
> URL: https://issues.apache.org/jira/browse/IGNITE-12567
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *How to reproduce:*
> * {{CREATE TABLE tbl (f0 INT, f1 INT, f2 INT, f3 INT, f4 INT, PRIMARY KEY
> (f3, f4))}}
> * populate table with some data
> * {{ALTER TABLE tbl DROP COLUMN f1, f2}}
> * try to execute query which will use pk index: {{SELECT * FROM tbl WHERE f3
> = 1 AND f4 = 1}}
> *Expected*:
> * Query returns result set
> *Actual*:
> * Query fails with {{General error:
> "java.lang.ArrayIndexOutOfBoundsException: 5";}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
[ https://issues.apache.org/jira/browse/IGNITE-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021101#comment-17021101 ] Konstantin Orlov commented on IGNITE-12565: --- Now the patch looks good to me. Let's wait for visa. > Extend test coverage [IGNITE-9279] Support custom default SQL schema name > - > > Key: IGNITE-12565 > URL: https://issues.apache.org/jira/browse/IGNITE-12565 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
[ https://issues.apache.org/jira/browse/IGNITE-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021097#comment-17021097 ] Ivan Pavlukhin commented on IGNITE-12565: - [~korlov], I removed tests ignored with malformed links. > Extend test coverage [IGNITE-9279] Support custom default SQL schema name > - > > Key: IGNITE-12565 > URL: https://issues.apache.org/jira/browse/IGNITE-12565 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12567) H2Tree goes into illegal state when non-indexed columns are dropped
[
https://issues.apache.org/jira/browse/IGNITE-12567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021096#comment-17021096
]
Konstantin Orlov commented on IGNITE-12567:
---
[~ipavlukhin], please review the patch. TC visa is in progress.
> H2Tree goes into illegal state when non-indexed columns are dropped
> ---
>
> Key: IGNITE-12567
> URL: https://issues.apache.org/jira/browse/IGNITE-12567
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *How to reproduce:*
> * {{CREATE TABLE tbl (f0 INT, f1 INT, f2 INT, f3 INT, f4 INT, PRIMARY KEY
> (f3, f4))}}
> * populate table with some data
> * {{ALTER TABLE tbl DROP COLUMN f1, f2}}
> * try to execute query which will use pk index: {{SELECT * FROM tbl WHERE f3
> = 1 AND f4 = 1}}
> *Expected*:
> * Query returns result set
> *Actual*:
> * Query fails with {{General error:
> "java.lang.ArrayIndexOutOfBoundsException: 5";}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021095#comment-17021095 ] Sergey Kosarev commented on IGNITE-12549: - [~Pavlukhin], thanks. Please check my reply there. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12567) H2Tree goes into illegal state when non-indexed columns are dropped
[
https://issues.apache.org/jira/browse/IGNITE-12567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021094#comment-17021094
]
Konstantin Orlov commented on IGNITE-12567:
---
The problem with in-memory state, so possible work around is a rebooting the
node.
> H2Tree goes into illegal state when non-indexed columns are dropped
> ---
>
> Key: IGNITE-12567
> URL: https://issues.apache.org/jira/browse/IGNITE-12567
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>
> *How to reproduce:*
> * {{CREATE TABLE tbl (f0 INT, f1 INT, f2 INT, f3 INT, f4 INT, PRIMARY KEY
> (f3, f4))}}
> * populate table with some data
> * {{ALTER TABLE tbl DROP COLUMN f1, f2}}
> * try to execute query which will use pk index: {{SELECT * FROM tbl WHERE f3
> = 1 AND f4 = 1}}
> *Expected*:
> * Query returns result set
> *Actual*:
> * Query fails with {{General error:
> "java.lang.ArrayIndexOutOfBoundsException: 5";}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6804:
Comment: was deleted
(was: {panel:title=Branch: [pull/6976/head] Base: [master] : Possible Blockers
(49)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Start Nodes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4936485]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testCustomScript - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
42|https://ci.ignite.apache.org/viewLog.html?buildId=4936546]]
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedTransactionalSnapshotColumnConstraintTest.testPutLongStringKeyField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedTransactionalSnapshotColumnConstraintTest.testPutValidDecimalKeyAndValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedTransactionalSnapshotColumnConstraintTest.testPutLongStringValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedTransactionalSnapshotColumnConstraintTest.testPutValidDecimalKeyAndValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedTransactionalSnapshotColumnConstraintTest.testPutLongStringKeyField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedTransactionalSnapshotColumnConstraintTest.testPutLongStringValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutValidDecimalKeyAndValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutTooLongStringKeyFieldFail
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutLongStringKeyField -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutTooLongStringValueFieldFail
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutTooLongDecimalValueFieldScaleFail
- Test has low fail rate in base branch 0,0% and is not flaky
... and 31 tests blockers
{color:#d04437}Data Structures{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=4936531]]
* IgniteCacheDataStructuresSelfTestSuite:
SingleBackupImplicitTransactionalReadRepairTest.test[getEntry=false,
async=false] - Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
SingleBackupImplicitTransactionalReadRepairTest.test[getEntry=false,
async=true] - Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
SingleBackupImplicitTransactionalReadRepairTest.test[getEntry=true,
async=false] - Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
SingleBackupImplicitTransactionalReadRepairTest.test[getEntry=true, async=true]
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4936527]]
* IgniteCacheTestSuite9:
TxPartitionCounterStateOnePrimaryTwoBackupsTest.testPartialPrepare_3TX_6_1 -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4936558]]
* IgniteCacheMvccTestSuite5:
GridCacheHashMapPutAllWarningsTest.testHashMapPutAllExplicitOptimistic -
History for base branch is absent.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4936570buildTypeId=IgniteTests24Java8_RunAll])
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap.
[jira] [Commented] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
[ https://issues.apache.org/jira/browse/IGNITE-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021083#comment-17021083 ] Konstantin Orlov commented on IGNITE-12565: --- But what about links to private Jira? Should we create separate issue into apache's Jira for ignored tests? > Extend test coverage [IGNITE-9279] Support custom default SQL schema name > - > > Key: IGNITE-12565 > URL: https://issues.apache.org/jira/browse/IGNITE-12565 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6804:
Comment: was deleted
(was: {panel:title=Branch: [pull/6976/head] Base: [master] : Possible Blockers
(47)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4755357]]
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4755178]]
* IgniteCacheTestSuite5: ClientDelayedJoinTest.testClientJoinAndCacheStop -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
42|https://ci.ignite.apache.org/viewLog.html?buildId=4755201]]
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedTransactionalSnapshotColumnConstraintTest.testPutLongStringKeyField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedTransactionalSnapshotColumnConstraintTest.testPutValidDecimalKeyAndValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedTransactionalSnapshotColumnConstraintTest.testPutLongStringValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedTransactionalSnapshotColumnConstraintTest.testPutValidDecimalKeyAndValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedTransactionalSnapshotColumnConstraintTest.testPutLongStringKeyField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedTransactionalSnapshotColumnConstraintTest.testPutLongStringValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutValidDecimalKeyAndValueField
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutTooLongStringKeyFieldFail
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutLongStringKeyField -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutTooLongStringValueFieldFail
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedAtomicColumnConstraintsTest.testPutTooLongDecimalValueFieldScaleFail
- Test has low fail rate in base branch 0,0% and is not flaky
... and 31 tests blockers
{color:#d04437}MVCC Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4755213]]
* IgniteCacheMvccTestSuite5:
GridCacheHashMapPutAllWarningsTest.testHashMapPutAllExplicitOptimistic -
History for base branch is absent.
{color:#d04437}PDS 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4755193]]
* IgnitePdsTestSuite3:
IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_8000_8000_8_1 - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4755197]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4755225buildTypeId=IgniteTests24Java8_RunAll])
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap,
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element.
> However, we should make sure that we only print that warning once and not
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12567) H2Tree goes into illegal state when non-indexed columns are dropped
Konstantin Orlov created IGNITE-12567:
-
Summary: H2Tree goes into illegal state when non-indexed columns
are dropped
Key: IGNITE-12567
URL: https://issues.apache.org/jira/browse/IGNITE-12567
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov
*How to reproduce:*
* {{CREATE TABLE tbl (f0 INT, f1 INT, f2 INT, f3 INT, f4 INT, PRIMARY KEY (f3,
f4))}}
* populate table with some data
* {{ALTER TABLE tbl DROP COLUMN f1, f2}}
* try to execute query which will use pk index: {{SELECT * FROM tbl WHERE f3 =
1 AND f4 = 1}}
*Expected*:
* Query returns result set
*Actual*:
* Query fails with {{General error: "java.lang.ArrayIndexOutOfBoundsException:
5";}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
[ https://issues.apache.org/jira/browse/IGNITE-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021052#comment-17021052 ] Ivan Pavlukhin commented on IGNITE-12565: - [~korlov], I changed PR according to your comments. Could you please take a look again? > Extend test coverage [IGNITE-9279] Support custom default SQL schema name > - > > Key: IGNITE-12565 > URL: https://issues.apache.org/jira/browse/IGNITE-12565 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021047#comment-17021047 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], please check my comment on [GitHub|https://github.com/apache/ignite/pull/7277]. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-1666) Fallback for full scan query does not work
[
https://issues.apache.org/jira/browse/IGNITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021044#comment-17021044
]
Andrey N. Gura edited comment on IGNITE-1666 at 1/22/20 1:20 PM:
-
As I can see from code partition will be reserved only if scan query created
for scan of one particular partition. For common case with scan of all
partitions there is no logic for partitions reservation. So, despite we can't
reproduce the problem, it is still actual. Issue is reopened.
was (Author: agura):
As I can see from code partition will be reserved only if scan query created
for scan of one particular partition. For common case with scan of all
partitions there is no logic for partitions reservation. So, despite we can't
reproduce the problem, it is still actual.
> Fallback for full scan query does not work
> --
>
> Key: IGNITE-1666
> URL: https://issues.apache.org/jira/browse/IGNITE-1666
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Andrey N. Gura
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Fallback for full scan query doesn't work.
> Steps to reproduce (all in one thread):
> 1. Start N nodes, create cache and populate some entries to cache.
> 2. Stop some node.
> 3. Get iterator on the cache and fetch all entries one by one.
> 4. Repeat from step 2.
> On some iteration scan query fails with exception:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> Caused by: class org.apache.ignite.IgniteCheckedException: Query execution
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
>
[jira] [Reopened] (IGNITE-1666) Fallback for full scan query does not work
[
https://issues.apache.org/jira/browse/IGNITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura reopened IGNITE-1666:
Assignee: (was: Diana Iakovleva)
> Fallback for full scan query does not work
> --
>
> Key: IGNITE-1666
> URL: https://issues.apache.org/jira/browse/IGNITE-1666
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Andrey N. Gura
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Fallback for full scan query doesn't work.
> Steps to reproduce (all in one thread):
> 1. Start N nodes, create cache and populate some entries to cache.
> 2. Stop some node.
> 3. Get iterator on the cache and fetch all entries one by one.
> 4. Repeat from step 2.
> On some iteration scan query fails with exception:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> Caused by: class org.apache.ignite.IgniteCheckedException: Query execution
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
> ... 14 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null], nodeId=203d0a36-8587-4a32-aa51-3332d126d002]
> at
>
[jira] [Comment Edited] (IGNITE-1666) Fallback for full scan query does not work
[
https://issues.apache.org/jira/browse/IGNITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021044#comment-17021044
]
Andrey N. Gura edited comment on IGNITE-1666 at 1/22/20 1:19 PM:
-
As I can see from code partition will be reserved only if scan query created
for scan of one particular partition. For common case with scan of all
partitions there is no logic for partitions reservation. So, despite we can't
reproduce the problem, it is still actual.
was (Author: agura):
As I can see from code partition will be reserved only if scan query created
for scan of one particular partition. For common case with scan of all
partitions there si no logic for partitions reservation. So, despite we can't
reproduce the problem, it is still actual.
> Fallback for full scan query does not work
> --
>
> Key: IGNITE-1666
> URL: https://issues.apache.org/jira/browse/IGNITE-1666
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Andrey N. Gura
>Assignee: Diana Iakovleva
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Fallback for full scan query doesn't work.
> Steps to reproduce (all in one thread):
> 1. Start N nodes, create cache and populate some entries to cache.
> 2. Stop some node.
> 3. Get iterator on the cache and fetch all entries one by one.
> 4. Repeat from step 2.
> On some iteration scan query fails with exception:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> Caused by: class org.apache.ignite.IgniteCheckedException: Query execution
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
> at
>
[jira] [Commented] (IGNITE-1666) Fallback for full scan query does not work
[
https://issues.apache.org/jira/browse/IGNITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021044#comment-17021044
]
Andrey N. Gura commented on IGNITE-1666:
As I can see from code partition will be reserved only if scan query created
for scan of one particular partition. For common case with scan of all
partitions there si no logic for partitions reservation. So, despite we can't
reproduce the problem, it is still actual.
> Fallback for full scan query does not work
> --
>
> Key: IGNITE-1666
> URL: https://issues.apache.org/jira/browse/IGNITE-1666
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Andrey N. Gura
>Assignee: Diana Iakovleva
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Fallback for full scan query doesn't work.
> Steps to reproduce (all in one thread):
> 1. Start N nodes, create cache and populate some entries to cache.
> 2. Stop some node.
> 3. Get iterator on the cache and fetch all entries one by one.
> 4. Repeat from step 2.
> On some iteration scan query fails with exception:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> Caused by: class org.apache.ignite.IgniteCheckedException: Query execution
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
> ... 14 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
>
[jira] [Commented] (IGNITE-8641) SpringDataExample should use example-ignite.xml config
[
https://issues.apache.org/jira/browse/IGNITE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021040#comment-17021040
]
Maxim Muzafarov commented on IGNITE-8641:
-
Merged to the master branch, cherry-picked to 2.8
> SpringDataExample should use example-ignite.xml config
> --
>
> Key: IGNITE-8641
> URL: https://issues.apache.org/jira/browse/IGNITE-8641
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{SpringDataExample}} uses
> {{org.apache.ignite.examples.springdata.SpringAppCfg}} as Spring
> configuration while all other examples use {{example-ignite.xml}}
> configuration file.
> It leads to inconsistent examples behaviour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11906) Scalar examples fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021032#comment-17021032 ] Ilya Kasnacheev commented on IGNITE-11906: -- [~nizhikov] please review proposed fix. > Scalar examples fails on TC > --- > > Key: IGNITE-11906 > URL: https://issues.apache.org/jira/browse/IGNITE-11906 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Scalar examples tests fails in master. > https://ci.ignite.apache.org/viewLog.html?buildId=4085544=buildResultsDiv=IgniteTests24Java8_ScalaExamples -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-11906) Scalar examples fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-11906:
-
Comment: was deleted
(was: {panel:title=Branch: [pull/7284/head] Base: [master] : Possible Blockers
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4947740]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testStartNoServers_FailOnTimeout - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Queries{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=4947751]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccSqlLockTimeoutTest.testConcurrentForReplicatedCache - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccSqlLockTimeoutTest.testConcurrentForPartitionedCache - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 5{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=4947770]]
* IgniteCacheTestSuite5:
CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClientsNodeRestart
- Test has low fail rate in base branch 1,0% and is not flaky
* IgniteCacheTestSuite5:
CacheSerializableTransactionsTest.testConflictResolution - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite5:
CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockNodeRestart -
Test has low fail rate in base branch 1,0% and is not flaky
* IgniteCacheTestSuite5:
CacheSerializableTransactionsTest.testNoOptimisticExceptionOnChangingTopology -
Test has low fail rate in base branch 1,0% and is not flaky
* IgniteCacheTestSuite5:
CacheSerializableTransactionsTest.testIncrementTxRestart - Test has low fail
rate in base branch 1,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4947796]]
* ZookeeperDiscoverySpiTestSuite4:
DistributedMetaStoragePersistentTest.testClientReconnect - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Service Grid{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=4947799]]
* IgniteServiceGridTestSuite:
GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteServiceGridTestSuite:
GridServiceProcessorBatchDeploySelfTest.testClashingNames - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4947817buildTypeId=IgniteTests24Java8_RunAll])
> Scalar examples fails on TC
> ---
>
> Key: IGNITE-11906
> URL: https://issues.apache.org/jira/browse/IGNITE-11906
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scalar examples tests fails in master.
> https://ci.ignite.apache.org/viewLog.html?buildId=4085544=buildResultsDiv=IgniteTests24Java8_ScalaExamples
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11906) Scalar examples fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11906: - Component/s: examples > Scalar examples fails on TC > --- > > Key: IGNITE-11906 > URL: https://issues.apache.org/jira/browse/IGNITE-11906 > Project: Ignite > Issue Type: Improvement > Components: examples >Reporter: Nikolay Izhikov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: scala > Time Spent: 10m > Remaining Estimate: 0h > > Scalar examples tests fails in master. > https://ci.ignite.apache.org/viewLog.html?buildId=4085544=buildResultsDiv=IgniteTests24Java8_ScalaExamples -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11906) Scalar examples fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11906: - Labels: scala (was: ) > Scalar examples fails on TC > --- > > Key: IGNITE-11906 > URL: https://issues.apache.org/jira/browse/IGNITE-11906 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: scala > Time Spent: 10m > Remaining Estimate: 0h > > Scalar examples tests fails in master. > https://ci.ignite.apache.org/viewLog.html?buildId=4085544=buildResultsDiv=IgniteTests24Java8_ScalaExamples -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11906) Scalar examples fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11906: - Issue Type: Bug (was: Improvement) > Scalar examples fails on TC > --- > > Key: IGNITE-11906 > URL: https://issues.apache.org/jira/browse/IGNITE-11906 > Project: Ignite > Issue Type: Bug > Components: examples >Reporter: Nikolay Izhikov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: scala > Time Spent: 10m > Remaining Estimate: 0h > > Scalar examples tests fails in master. > https://ci.ignite.apache.org/viewLog.html?buildId=4085544=buildResultsDiv=IgniteTests24Java8_ScalaExamples -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11906) Scalar examples fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021030#comment-17021030
]
Ignite TC Bot commented on IGNITE-11906:
{panel:title=Branch: [pull/7284/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=4947817buildTypeId=IgniteTests24Java8_RunAll]
> Scalar examples fails on TC
> ---
>
> Key: IGNITE-11906
> URL: https://issues.apache.org/jira/browse/IGNITE-11906
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scalar examples tests fails in master.
> https://ci.ignite.apache.org/viewLog.html?buildId=4085544=buildResultsDiv=IgniteTests24Java8_ScalaExamples
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8641) SpringDataExample should use example-ignite.xml config
[
https://issues.apache.org/jira/browse/IGNITE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021027#comment-17021027
]
Andrey N. Gura commented on IGNITE-8641:
[~mmuzaf] LGTM. Please proceed with merge.
> SpringDataExample should use example-ignite.xml config
> --
>
> Key: IGNITE-8641
> URL: https://issues.apache.org/jira/browse/IGNITE-8641
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{SpringDataExample}} uses
> {{org.apache.ignite.examples.springdata.SpringAppCfg}} as Spring
> configuration while all other examples use {{example-ignite.xml}}
> configuration file.
> It leads to inconsistent examples behaviour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
[ https://issues.apache.org/jira/browse/IGNITE-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021025#comment-17021025 ] Konstantin Orlov commented on IGNITE-12565: --- [~Pavlukhin], I left some comments in the PR, please check it. > Extend test coverage [IGNITE-9279] Support custom default SQL schema name > - > > Key: IGNITE-12565 > URL: https://issues.apache.org/jira/browse/IGNITE-12565 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12474) Fix boost compatibility for cpp thin-client-test.
[ https://issues.apache.org/jira/browse/IGNITE-12474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021023#comment-17021023 ] Igor Sapego commented on IGNITE-12474: -- Looks good to me. Merging to master. > Fix boost compatibility for cpp thin-client-test. > - > > Key: IGNITE-12474 > URL: https://issues.apache.org/jira/browse/IGNITE-12474 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Current teamcity_boost implementation leads to errors like: > "src/teamcity/teamcity_boost.cpp:22:10: fatal error: > boost/test/unit_test_suite_impl.hpp: No such file or catalog. > #include " > dev list discussion [1] > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/Can-t-run-CPP-tests-locally-on-linux-machine-td29597.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
[ https://issues.apache.org/jira/browse/IGNITE-12565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020992#comment-17020992 ] Ivan Pavlukhin commented on IGNITE-12565: - [~korlov], please review the patch. TC visa is in progress. > Extend test coverage [IGNITE-9279] Support custom default SQL schema name > - > > Key: IGNITE-12565 > URL: https://issues.apache.org/jira/browse/IGNITE-12565 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12566) Calcite integration. Expressions evaluation.
Igor Seliverstov created IGNITE-12566: - Summary: Calcite integration. Expressions evaluation. Key: IGNITE-12566 URL: https://issues.apache.org/jira/browse/IGNITE-12566 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently we use a part of Calcite "Bindables" to evaluate expressions at the execution time. Using it we * lose a control on how expressions are evaluated * cannot implement several important optimizations, like "keepBinary" * can use only Object[] as a row, which causes a lot of array copy operations and unnecessary allocations at the execution time * suffer from delays, which go from expressions compilation process when it's more efficient to start from interpretation and compile an expression on repeatable execution only We need to implement expressions interpreter and our own expression compiler taking Ignite specifics in consideration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12540) Update versions of vulnerable dependencies
[ https://issues.apache.org/jira/browse/IGNITE-12540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12540: - Ignite Flags: (was: Docs Required,Release Notes Required) > Update versions of vulnerable dependencies > -- > > Key: IGNITE-12540 > URL: https://issues.apache.org/jira/browse/IGNITE-12540 > Project: Ignite > Issue Type: Improvement > Components: general, hibernate, rest, spring >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Let's bump some crucial dependencies to their latest minor versions and try > to include it in 2.8 also. > spring 4 and 5, spring data, hibernate, jetty, jackson-databind. > Lesser-used packages, notable Zk discovery, are not affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8641) SpringDataExample should use example-ignite.xml config
[
https://issues.apache.org/jira/browse/IGNITE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020986#comment-17020986
]
Maxim Muzafarov commented on IGNITE-8641:
-
[~agura]
Can you, please, review my changes?
> SpringDataExample should use example-ignite.xml config
> --
>
> Key: IGNITE-8641
> URL: https://issues.apache.org/jira/browse/IGNITE-8641
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{SpringDataExample}} uses
> {{org.apache.ignite.examples.springdata.SpringAppCfg}} as Spring
> configuration while all other examples use {{example-ignite.xml}}
> configuration file.
> It leads to inconsistent examples behaviour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8641) SpringDataExample should use example-ignite.xml config
[
https://issues.apache.org/jira/browse/IGNITE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020985#comment-17020985
]
Maxim Muzafarov commented on IGNITE-8641:
-
Re-run Examples suite.
https://ci.ignite.apache.org/viewLog.html?buildId=4947351=IgniteTests24Java8_Examples
> SpringDataExample should use example-ignite.xml config
> --
>
> Key: IGNITE-8641
> URL: https://issues.apache.org/jira/browse/IGNITE-8641
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{SpringDataExample}} uses
> {{org.apache.ignite.examples.springdata.SpringAppCfg}} as Spring
> configuration while all other examples use {{example-ignite.xml}}
> configuration file.
> It leads to inconsistent examples behaviour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8641) SpringDataExample should use example-ignite.xml config
[
https://issues.apache.org/jira/browse/IGNITE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020984#comment-17020984
]
Ignite TC Bot commented on IGNITE-8641:
---
{panel:title=Branch: [pull/7280/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=4947585buildTypeId=IgniteTests24Java8_RunAll]
> SpringDataExample should use example-ignite.xml config
> --
>
> Key: IGNITE-8641
> URL: https://issues.apache.org/jira/browse/IGNITE-8641
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{SpringDataExample}} uses
> {{org.apache.ignite.examples.springdata.SpringAppCfg}} as Spring
> configuration while all other examples use {{example-ignite.xml}}
> configuration file.
> It leads to inconsistent examples behaviour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12565) Extend test coverage [IGNITE-9279] Support custom default SQL schema name
Ivan Pavlukhin created IGNITE-12565: --- Summary: Extend test coverage [IGNITE-9279] Support custom default SQL schema name Key: IGNITE-12565 URL: https://issues.apache.org/jira/browse/IGNITE-12565 Project: Ignite Issue Type: Task Components: sql Reporter: Ivan Pavlukhin Assignee: Ivan Pavlukhin Fix For: 2.9 Add more tests to cover schemas support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12564) Calcite integration. Exceptions handling.
Igor Seliverstov created IGNITE-12564: - Summary: Calcite integration. Exceptions handling. Key: IGNITE-12564 URL: https://issues.apache.org/jira/browse/IGNITE-12564 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov There are several exceptions types that may be thrown at * parsing and validation time * planning time * mapping time * execution time All of them should be handled properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12563) Calcite integration. Reset and remap queries on topology change.
Igor Seliverstov created IGNITE-12563: - Summary: Calcite integration. Reset and remap queries on topology change. Key: IGNITE-12563 URL: https://issues.apache.org/jira/browse/IGNITE-12563 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov A query should: * be silently remapped in case an actual topology version at query plan materialization time differs from a topology version at the time locations was calculated * be cancelled with appropriate exception in case one of responsible nodes left a cluster after execution is started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12552) [IEP-35] Expose MetricRegistry to the public API
[
https://issues.apache.org/jira/browse/IGNITE-12552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020949#comment-17020949
]
Ignite TC Bot commented on IGNITE-12552:
{panel:title=Branch: [pull/7269/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=4947701buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-35] Expose MetricRegistry to the public API
>
>
> Key: IGNITE-12552
> URL: https://issues.apache.org/jira/browse/IGNITE-12552
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> MetricRegistry is not a part of public API, but used in MetricExporter which
> is the part of public API.
> We should export MetricRegistry to the public API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12448) Calcite integration. Communication protocol.
[
https://issues.apache.org/jira/browse/IGNITE-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020946#comment-17020946
]
Alexey Goncharuk commented on IGNITE-12448:
---
[~gvvinblade], I have one suggestion wrt to code organization based on general
ideas from [~akalashnikov]:
Right now it looks like that {{CalciteQueryProcessor}} is becoming both a
wiring component which connects various pieces together, and also executes some
important logic. This makes it impossible to test the logic without having an
IgniteKernal instance.
I would separate it the following way:
* Move {{locals}} and {{remotes}} maps to either exchange service or messaging
service. These maps are a part of communication subsystem, so the processor
should not be aware of it and should not manage it
* Separate all execution-related logic from CalciteQueryProcessor to a
separate class which does not depend on {{KernalContext}} and accepts only
interfaces. This way you can test this logic by mocking both all remote nodes
or by simulating remote nodes without actual Ignite start
* The {{CalciteQueryProcessor}} will just wire components that it pulls from
contexts, setup listeners, etc.
> Calcite integration. Communication protocol.
>
>
> Key: IGNITE-12448
> URL: https://issues.apache.org/jira/browse/IGNITE-12448
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We need to introduce a communication protocol between query fragments in
> scope of query execution.
> * Protocol should have Push semantics with back pressure ability
> * Protocol have to provide ordering guaranties - the data batches processed
> in same order they sent to remote node.
> * Protocol have to provide delivery guaranties.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12497) PartitionsEvictManager should log all partitions which will be evicted
[ https://issues.apache.org/jira/browse/IGNITE-12497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020916#comment-17020916 ] Ivan Rakov commented on IGNITE-12497: - [~ktkale...@gridgain.com] Looks good, thanks, merged. > PartitionsEvictManager should log all partitions which will be evicted > -- > > Key: IGNITE-12497 > URL: https://issues.apache.org/jira/browse/IGNITE-12497 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.9 > > > Now we print information about eviction only if it longer then threshold > (i.e. progress). And we can't detect in logs, that partition was evicted due > to different reasons (rebalance, wrong configuration custom affinity). > I think we could print information on info level about each evicted partition > before start of eviction. Information about partitions could be aggregated, > compacted and printed by timer, but *all evicted partitions must be printed > to log anyway.* > I would have the following information about each partition: > * partitionId > * groupId > * groupName > * reason (eviction, clearing) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-12549: - Assignee: (was: Peter Ivanov) > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-12549: - Assignee: Peter Ivanov > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Peter Ivanov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-12549: - Assignee: (was: Peter Ivanov) > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-12549: - Assignee: Peter Ivanov > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Peter Ivanov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12562) FreeListCachingTest.testPageListCacheLimit failing in Disk Page Compressions suite
[ https://issues.apache.org/jira/browse/IGNITE-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12562: --- Ignite Flags: (was: Docs Required,Release Notes Required) > FreeListCachingTest.testPageListCacheLimit failing in Disk Page Compressions > suite > -- > > Key: IGNITE-12562 > URL: https://issues.apache.org/jira/browse/IGNITE-12562 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Test failing with IgniteOutOfMemory exception because Disk Page Compressions > changes default page size to 8192, we need at least 2*1024 pages to store > freelist metadata and there is no such amount of not dirty pages after > checkpoint is triggered by "too many dirty page" reason. > Explicitly defined data region max size should take into account page size to > avoid such errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12562) FreeListCachingTest.testPageListCacheLimit failing in Disk Page Compressions suite
Aleksey Plekhanov created IGNITE-12562: -- Summary: FreeListCachingTest.testPageListCacheLimit failing in Disk Page Compressions suite Key: IGNITE-12562 URL: https://issues.apache.org/jira/browse/IGNITE-12562 Project: Ignite Issue Type: Bug Components: persistence Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Test failing with IgniteOutOfMemory exception because Disk Page Compressions changes default page size to 8192, we need at least 2*1024 pages to store freelist metadata and there is no such amount of not dirty pages after checkpoint is triggered by "too many dirty page" reason. Explicitly defined data region max size should take into account page size to avoid such errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12555) .NET: Thin Client: deserializing DateTime fields causes BinaryTypeGet request for every value
[
https://issues.apache.org/jira/browse/IGNITE-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12555:
Release Note: Improve serialization performance for DateTime and other
ISerializable types
> .NET: Thin Client: deserializing DateTime fields causes BinaryTypeGet request
> for every value
> -
>
> Key: IGNITE-12555
> URL: https://issues.apache.org/jira/browse/IGNITE-12555
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4, 2.5, 2.6, 2.7, 2.8, 2.7.5, 2.7.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Actual: The following code causes 10 BinaryProcessorClient.GetBinaryType
> calls (2 fields, 5 Foo instances). Every call is a server request.
> Expected: 0 calls. Binary metadata should be cached after PutAll call.
> {code}
> public class CacheDateTimeMetaTest : ClientTestBase
> {
> [Test]
> public void TestDateTimeMeta()
> {
> var data = Enumerable.Range(1, 5)
> .Select(x => new Foo
> {
> Id = x,
> StartDate = DateTime.Now.AddHours(x),
> EndDate = DateTime.Now.AddDays(x)
> });
> var cache = Client.GetOrCreateCache("foo");
> cache.PutAll(data.Select(x => new KeyValuePair(x.Id,
> x)));
> var res = cache.Query(new ScanQuery()).GetAll();
> Assert.AreEqual(cache.GetSize(), res.Count);
> }
> public class Foo
> {
> public int Id { get; set; }
> public DateTime? StartDate { get; set; }
> public DateTime? EndDate { get; set; }
> }
> }
> {code}
> This causes huge performance issues.
> *Workaround*
> * Force Timestamp format for all DateTime values
> User list discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Getting-all-data-from-cache-via-scan-query-is-taking-lot-of-time-td30949.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
