[jira] [Updated] (IGNITE-7538) Update several maven plugins version for Java 9 compilation
[ https://issues.apache.org/jira/browse/IGNITE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7538: --- Fix Version/s: 2.8 > Update several maven plugins version for Java 9 compilation > --- > > Key: IGNITE-7538 > URL: https://issues.apache.org/jira/browse/IGNITE-7538 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > * rat plugin > * flat plugin > * java plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11739) Refactoring of cache lifecycle and cache configuration management code
[ https://issues.apache.org/jira/browse/IGNITE-11739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-11739: - Issue Type: Improvement (was: Task) > Refactoring of cache lifecycle and cache configuration management code > -- > > Key: IGNITE-11739 > URL: https://issues.apache.org/jira/browse/IGNITE-11739 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Sergey Chugunov >Priority: Major > > h2. Problem > Currently code responsible for cache lifecycle and configuration management > is spread across different entities (e.g. GridCacheProcessor, > GridCacheAffinityManager, ClusterCachesInfo and so on). > Cache configuration data is duplicated multiple times and presented in > different forms from StoredCacheData to CacheGroupDescriptor to > DynamicCacheDescriptor to ClusterCachesInfo. > Altogether there is no entity nor abstraction which contains most of the > logic of managing cache state and config and provides a clean API for this > purpose. > All this makes it hard to maintain the code, fix bugs and make improvements > so need for refactoring and benefits from it are obvious. > h2. Approaches > # Build state machine manipulating immutable state objects to reflect > transitions between states. > # Concentrate all cache-related info into a new (abstraction like cache > container) or existing (e.g. cache context) mutable entity and manipulate > that entity to reflect evolution of cache. > # Some mix of these two approaches. > There are already plenty of entities like CacheInfo or CacheDescriptor with > names suggesting they contain information about cache. > The problem though is that each of these entities manages only some part of > information. > Regardless of which approach is used clear and well documented API should be > provided for managing lifecycle and configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[ https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816414#comment-16816414 ] Ivan Bessonov commented on IGNITE-11188: [~akalashnikov] please take a look at my last commit and make it look better. There's also a very likely bug somewhere in "GridAffinityAssignmentCache" class after merge with IGNITE-10799, but I'm not sure. Affinity calculation looks broken, we need to at least test it. Thank you in advance! > Optimize baseline autoadjustment for in-memory clusters with zero timeout > - > > Key: IGNITE-11188 > URL: https://issues.apache.org/jira/browse/IGNITE-11188 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > In current implementation (IGNITE-8571) zero-timeout case initiates two > partition map exchanges on join/leave node events. This could be improved so > that baseline is updated at the same time as join/leave event processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[ https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-11188: -- Assignee: Anton Kalashnikov (was: Ivan Bessonov) > Optimize baseline autoadjustment for in-memory clusters with zero timeout > - > > Key: IGNITE-11188 > URL: https://issues.apache.org/jira/browse/IGNITE-11188 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > In current implementation (IGNITE-8571) zero-timeout case initiates two > partition map exchanges on join/leave node events. This could be improved so > that baseline is updated at the same time as join/leave event processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11739) Refactoring of cache lifecycle and cache configuration management code
Sergey Chugunov created IGNITE-11739: Summary: Refactoring of cache lifecycle and cache configuration management code Key: IGNITE-11739 URL: https://issues.apache.org/jira/browse/IGNITE-11739 Project: Ignite Issue Type: Task Components: cache Reporter: Sergey Chugunov h2. Problem Currently code responsible for cache lifecycle and configuration management is spread across different entities (e.g. GridCacheProcessor, GridCacheAffinityManager, ClusterCachesInfo and so on). Cache configuration data is duplicated multiple times and presented in different forms from StoredCacheData to CacheGroupDescriptor to DynamicCacheDescriptor to ClusterCachesInfo. Altogether there is no entity nor abstraction which contains most of the logic of managing cache state and config and provides a clean API for this purpose. All this makes it hard to maintain the code, fix bugs and make improvements so need for refactoring and benefits from it are obvious. h2. Approaches # Build state machine manipulating immutable state objects to reflect transitions between states. # Concentrate all cache-related info into a new (abstraction like cache container) or existing (e.g. cache context) mutable entity and manipulate that entity to reflect evolution of cache. # Some mix of these two approaches. There are already plenty of entities like CacheInfo or CacheDescriptor with names suggesting they contain information about cache. The problem though is that each of these entities manages only some part of information. Regardless of which approach is used clear and well documented API should be provided for managing lifecycle and configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11732) Multi-merged partitions exchange future may hang if node left event is received last
[
https://issues.apache.org/jira/browse/IGNITE-11732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816374#comment-16816374
]
Pavel Kovalenko commented on IGNITE-11732:
--
[~agoncharuk] Looks good to me. Please proceed with merge.
> Multi-merged partitions exchange future may hang if node left event is
> received last
>
>
> Key: IGNITE-11732
> URL: https://issues.apache.org/jira/browse/IGNITE-11732
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The scenario is similar to IGNITE-11204, but several exchanges should be
> merged. If in this case a merged-exchange node is left and all other nodes
> messages are already received, the exchange will not be completed because
> {{F.isEmpty(mergedJoinExchMsgs)}} is {{false}}.
> Looks like we should decrement the {{awaitMergedMsgs}} and check this field
> for {{0}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11703) CPP: Add default BinaryType methods implementations where possible
[
https://issues.apache.org/jira/browse/IGNITE-11703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816373#comment-16816373
]
Igor Sapego commented on IGNITE-11703:
--
[~Pavlukhin], can you take a look at PR?
> CPP: Add default BinaryType methods implementations where possible
> --
>
> Key: IGNITE-11703
> URL: https://issues.apache.org/jira/browse/IGNITE-11703
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: cpp
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, most of specifications of {{BinaryType}} template have the same
> default implementations of certain methods, which may be implemented by
> default. Here is the list:
> * {{GetTypeId()}}
> * {{GetFieldId()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11738:
Description:
CacheMetricsSnapshot.readExternal
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
Here we have 6 long variables but not an 11.
was:
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
Here we have 6 long variables but not an 11.
> Incorrect check ObjectInput.available() in CacheMetricsSnapshot
>
>
> Key: IGNITE-11738
> URL: https://issues.apache.org/jira/browse/IGNITE-11738
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> CacheMetricsSnapshot.readExternal
> {code}
> // 11 long and 5 float values give 108 bytes in total.
> if (in.available() >= 108) {
> entryProcessorPuts = in.readLong();
> entryProcessorAverageInvocationTime = in.readFloat();
> entryProcessorInvocations = in.readLong();
> entryProcessorMaxInvocationTime = in.readFloat();
> entryProcessorMinInvocationTime = in.readFloat();
> entryProcessorReadOnlyInvocations = in.readLong();
> entryProcessorHitPercentage = in.readFloat();
> entryProcessorHits = in.readLong();
> entryProcessorMisses = in.readLong();
> entryProcessorMissPercentage = in.readFloat();
> entryProcessorRemovals = in.readLong();
> }
> {code}
> Here we have 6 long variables but not an 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11703) CPP: Add default BinaryType methods implementations where possible
[
https://issues.apache.org/jira/browse/IGNITE-11703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11703:
-
Description:
Currently, most of specifications of {{BinaryType}} template have the same
default implementations of certain methods, which may be implemented by
default. Here is the list:
* {{GetTypeId()}}
* {{GetFieldId()}}
was:
Currently, most of specifications of {{BinaryType}} template have the same
default implementations of certain methods, which may be implemented by
default. Here is the list:
* {{GetTypeId}}
* {{GetFieldId}}
> CPP: Add default BinaryType methods implementations where possible
> --
>
> Key: IGNITE-11703
> URL: https://issues.apache.org/jira/browse/IGNITE-11703
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: cpp
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, most of specifications of {{BinaryType}} template have the same
> default implementations of certain methods, which may be implemented by
> default. Here is the list:
> * {{GetTypeId()}}
> * {{GetFieldId()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11738:
Description:
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
Here we have 6 long variables but not an 11.
was:
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
Here we have 6 long but not an 11.
> Incorrect check ObjectInput.available() in CacheMetricsSnapshot
>
>
> Key: IGNITE-11738
> URL: https://issues.apache.org/jira/browse/IGNITE-11738
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> // 11 long and 5 float values give 108 bytes in total.
> if (in.available() >= 108) {
> entryProcessorPuts = in.readLong();
> entryProcessorAverageInvocationTime = in.readFloat();
> entryProcessorInvocations = in.readLong();
> entryProcessorMaxInvocationTime = in.readFloat();
> entryProcessorMinInvocationTime = in.readFloat();
> entryProcessorReadOnlyInvocations = in.readLong();
> entryProcessorHitPercentage = in.readFloat();
> entryProcessorHits = in.readLong();
> entryProcessorMisses = in.readLong();
> entryProcessorMissPercentage = in.readFloat();
> entryProcessorRemovals = in.readLong();
> }
> {code}
> Here we have 6 long variables but not an 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin reassigned IGNITE-11738:
---
Assignee: Dmitriy Govorukhin
> Incorrect check ObjectInput.available() in CacheMetricsSnapshot
>
>
> Key: IGNITE-11738
> URL: https://issues.apache.org/jira/browse/IGNITE-11738
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> // 11 long and 5 float values give 108 bytes in total.
> if (in.available() >= 108) {
> entryProcessorPuts = in.readLong();
> entryProcessorAverageInvocationTime = in.readFloat();
> entryProcessorInvocations = in.readLong();
> entryProcessorMaxInvocationTime = in.readFloat();
> entryProcessorMinInvocationTime = in.readFloat();
> entryProcessorReadOnlyInvocations = in.readLong();
> entryProcessorHitPercentage = in.readFloat();
> entryProcessorHits = in.readLong();
> entryProcessorMisses = in.readLong();
> entryProcessorMissPercentage = in.readFloat();
> entryProcessorRemovals = in.readLong();
> }
> {code}
> Here we have 6 long variables but not an 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11738:
Description:
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
There we have 6 long but not a 11.
> Incorrect check ObjectInput.available() in CacheMetricsSnapshot
>
>
> Key: IGNITE-11738
> URL: https://issues.apache.org/jira/browse/IGNITE-11738
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> // 11 long and 5 float values give 108 bytes in total.
> if (in.available() >= 108) {
> entryProcessorPuts = in.readLong();
> entryProcessorAverageInvocationTime = in.readFloat();
> entryProcessorInvocations = in.readLong();
> entryProcessorMaxInvocationTime = in.readFloat();
> entryProcessorMinInvocationTime = in.readFloat();
> entryProcessorReadOnlyInvocations = in.readLong();
> entryProcessorHitPercentage = in.readFloat();
> entryProcessorHits = in.readLong();
> entryProcessorMisses = in.readLong();
> entryProcessorMissPercentage = in.readFloat();
> entryProcessorRemovals = in.readLong();
> }
> {code}
> There we have 6 long but not a 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11738:
Description:
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
Here we have 6 long but not an 11.
was:
{code}
// 11 long and 5 float values give 108 bytes in total.
if (in.available() >= 108) {
entryProcessorPuts = in.readLong();
entryProcessorAverageInvocationTime = in.readFloat();
entryProcessorInvocations = in.readLong();
entryProcessorMaxInvocationTime = in.readFloat();
entryProcessorMinInvocationTime = in.readFloat();
entryProcessorReadOnlyInvocations = in.readLong();
entryProcessorHitPercentage = in.readFloat();
entryProcessorHits = in.readLong();
entryProcessorMisses = in.readLong();
entryProcessorMissPercentage = in.readFloat();
entryProcessorRemovals = in.readLong();
}
{code}
There we have 6 long but not a 11.
> Incorrect check ObjectInput.available() in CacheMetricsSnapshot
>
>
> Key: IGNITE-11738
> URL: https://issues.apache.org/jira/browse/IGNITE-11738
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> // 11 long and 5 float values give 108 bytes in total.
> if (in.available() >= 108) {
> entryProcessorPuts = in.readLong();
> entryProcessorAverageInvocationTime = in.readFloat();
> entryProcessorInvocations = in.readLong();
> entryProcessorMaxInvocationTime = in.readFloat();
> entryProcessorMinInvocationTime = in.readFloat();
> entryProcessorReadOnlyInvocations = in.readLong();
> entryProcessorHitPercentage = in.readFloat();
> entryProcessorHits = in.readLong();
> entryProcessorMisses = in.readLong();
> entryProcessorMissPercentage = in.readFloat();
> entryProcessorRemovals = in.readLong();
> }
> {code}
> Here we have 6 long but not an 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11696) Create JMX metric for current PME execution time
[ https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11696: -- Ignite Flags: (was: Docs Required) > Create JMX metric for current PME execution time > > > Key: IGNITE-11696 > URL: https://issues.apache.org/jira/browse/IGNITE-11696 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Now PME process can't be monitored from JMX, only from the logs. It makes > sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11738: Fix Version/s: 2.8 > Incorrect check ObjectInput.available() in CacheMetricsSnapshot > > > Key: IGNITE-11738 > URL: https://issues.apache.org/jira/browse/IGNITE-11738 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-11738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11738: Ignite Flags: (was: Docs Required) > Incorrect check ObjectInput.available() in CacheMetricsSnapshot > > > Key: IGNITE-11738 > URL: https://issues.apache.org/jira/browse/IGNITE-11738 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
Dmitriy Govorukhin created IGNITE-11738: --- Summary: Incorrect check ObjectInput.available() in CacheMetricsSnapshot Key: IGNITE-11738 URL: https://issues.apache.org/jira/browse/IGNITE-11738 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11703) CPP: Add default BinaryType methods implementations where possible
[
https://issues.apache.org/jira/browse/IGNITE-11703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11703:
-
Description:
Currently, most of specifications of {{BinaryType}} template have the same
default implementations of certain methods, which may be implemented by
default. Here is the list:
* {{GetTypeId}}
* {{GetFieldId}}
was:
Currently, most of specifications of {{BinaryType}} template have the same
default implementations of certain methods, which may be implemented by
default. Here is the list:
{{GetTypeId}}
{{GetFieldId}}
> CPP: Add default BinaryType methods implementations where possible
> --
>
> Key: IGNITE-11703
> URL: https://issues.apache.org/jira/browse/IGNITE-11703
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: cpp
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, most of specifications of {{BinaryType}} template have the same
> default implementations of certain methods, which may be implemented by
> default. Here is the list:
> * {{GetTypeId}}
> * {{GetFieldId}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11737) Apache Ignite 2.7.5 Linux packages version update
Peter Ivanov created IGNITE-11737: - Summary: Apache Ignite 2.7.5 Linux packages version update Key: IGNITE-11737 URL: https://issues.apache.org/jira/browse/IGNITE-11737 Project: Ignite Issue Type: Task Reporter: Peter Ivanov Assignee: Peter Ivanov Update DEB and RPM packages' versions in Apache Ignite for the next version (2.7.5) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11737) Apache Ignite 2.7.5 Linux packages version update
[ https://issues.apache.org/jira/browse/IGNITE-11737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-11737: -- Fix Version/s: 2.7.5 > Apache Ignite 2.7.5 Linux packages version update > - > > Key: IGNITE-11737 > URL: https://issues.apache.org/jira/browse/IGNITE-11737 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.7.5 > > > Update DEB and RPM packages' versions in Apache Ignite for the next version > (2.7.5) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11698) Issue with P2P class loader
[
https://issues.apache.org/jira/browse/IGNITE-11698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11698:
--
Description:
Sometimes classes of remote query filter are incorrectly loaded.
This happens because p2p context incorrectly matches
{{CacheClassLoader#findClass}} with {{GridCacheDeploymentManager#p2pContext}}.
{noformat}
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Failed to execute query on node
[query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, clsName=null,
clause=null, filter=CompositePredicate@7ba93755, transform=null, part=null,
incMeta=false, metrics=GridCacheQueryMetricsAdapter
[minTime=9223372036854775807, maxTime=0, sumTime=0, avgTime=0.0, execs=0,
completed=0, fails=0], pageSize=1024, timeout=0, incBackups=false,
forceLocal=false, dedup=false, prj=null, keepBinary=false,
subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0, mvccSnapshot=null,
dataPageScanEnabled=null], rdc=null, trans=null],
nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:168)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:643)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:38)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
at
org.apache.ignite.internal.processors.cache.AutoClosableCursorIterator.next(AutoClosableCursorIterator.java:59)
at ClientP2P.query(ClientP2P.java:61)
at ClientP2P.main(ClientP2P.java:45)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
clsName=null, clause=null, filter=CompositePredicate@7ba93755, transform=null,
part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter
[minTime=9223372036854775807, maxTime=0, sumTime=0, avgTime=0.0, execs=0,
completed=0, fails=0], pageSize=1024, timeout=0, incBackups=false,
forceLocal=false, dedup=false, prj=null, keepBinary=false,
subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0, mvccSnapshot=null,
dataPageScanEnabled=null], rdc=null, trans=null],
nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:384)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:402)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:64)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:94)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:92)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1126)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1691)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2753)
at
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1521)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1490)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class
[jira] [Created] (IGNITE-11736) Make the TeamCity console quiet.
Stepachev Maksim created IGNITE-11736: - Summary: Make the TeamCity console quiet. Key: IGNITE-11736 URL: https://issues.apache.org/jira/browse/IGNITE-11736 Project: Ignite Issue Type: Improvement Reporter: Stepachev Maksim Assignee: Stepachev Maksim As a result of this discussion: [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] 1. Rollover will be locked. Pros: Only one big file in an archive. Cons: Max size of the file isn't limited. 2. Run all will contain a parameter for switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816206#comment-16816206 ] Ivan Bessonov commented on IGNITE-11346: [~Maxoid] I see now, you created PR for the gridgain fork, original github repository is here: [https://github.com/apache/ignite] Master branch is also there, I'd suggest recreating PR for the proper repository. After that you can use your PR to run tests here: [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll] Please link your run to this issue and I (or someone else) will take a look at the results. Thank you! > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Priority: Minor > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11730) Discovery Compression check fails when nodes reconnect to cluster
[
https://issues.apache.org/jira/browse/IGNITE-11730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816200#comment-16816200
]
Ilya Kasnacheev commented on IGNITE-11730:
--
[~akalashnikov] seems like this fix is working, I can no longer cause clients
to segment.
> Discovery Compression check fails when nodes reconnect to cluster
> -
>
> Key: IGNITE-11730
> URL: https://issues.apache.org/jira/browse/IGNITE-11730
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Anton Kalashnikov
>Priority: Major
>
> There is a check that Discovery Data Bag compression is supported by all
> nodes.
> Apparently this check does not work when nodes reconnect after server
> restart. When there is at least one client node that does not support this
> feature, clients will still send zipped data that server would not
> understand, leaving to following server error:
> {code}
> [15:46:47,101][SEVERE][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Failed to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> with given class loader: sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:161)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9922)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:290)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalJoiningNodeData(DiscoveryDataPacket.java:169)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2076)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4620)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:4307)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2962)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2729)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7496)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2833)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7427)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.EOFException
> at
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2638)
> at
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3113)
> at
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:853)
> at java.io.ObjectInputStream.(ObjectInputStream.java:349)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:43)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:137)
> ... 16 more
> {code}
> and client nodes will fail with following error:
> {code}
> [15:46:47,175][SEVERE][tcp-client-disco-msg-worker-#4][] Critical system
> error detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Node with
> BaselineTopology cannot join mixed cluster running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:727)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:899)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2083)
> at
>
[jira] [Updated] (IGNITE-11731) CPP: Implement minimal Cluster API
[
https://issues.apache.org/jira/browse/IGNITE-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11731:
-
Description:
Let's start implementing Cluster API for C++.
Desired functionality from Java:
* {{ClusterNode.id()}}
* {{ClusterNode.attribute()}}
* {{IgniteCluster.active()}}
* {{IgniteCluster.disableWal()}}
* {{IgntieCluster.enableWal()}}
* {{IgniteCluster.isWalEnabled()}}
* {{IgniteClusterGroup.forAttribute()}}
* {{IgniteClusterGroup.forDataNodes()}}
* {{IgniteClusterGroup.forServers()}}
Also, we need to have one platform-specific method:
* {{IgniteClusterGroup.forCpp()}}
was:
Let's start implementing Cluster API for C++.
Desired functionality from Java:
* ClusterNode.id()
* ClusterNode.attribute()
* IgniteCluster.active()
* IgniteCluster.disableWal()
* IgntieCluster.enableWal()
* IgniteCluster.isWalEnabled()
* IgniteClusterGroup.forAttribute()
* IgniteClusterGroup.forDataNodes()
* IgniteClusterGroup.forServers()
Also, we need to have one platform-specific method:
* IgniteClusterGroup.forCpp()
> CPP: Implement minimal Cluster API
> --
>
> Key: IGNITE-11731
> URL: https://issues.apache.org/jira/browse/IGNITE-11731
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Priority: Major
> Labels: cpp
> Fix For: 2.8
>
>
> Let's start implementing Cluster API for C++.
> Desired functionality from Java:
> * {{ClusterNode.id()}}
> * {{ClusterNode.attribute()}}
> * {{IgniteCluster.active()}}
> * {{IgniteCluster.disableWal()}}
> * {{IgntieCluster.enableWal()}}
> * {{IgniteCluster.isWalEnabled()}}
> * {{IgniteClusterGroup.forAttribute()}}
> * {{IgniteClusterGroup.forDataNodes()}}
> * {{IgniteClusterGroup.forServers()}}
> Also, we need to have one platform-specific method:
> * {{IgniteClusterGroup.forCpp()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816194#comment-16816194
]
Pavel Kuznetsov commented on IGNITE-11563:
--
One more point to think:
guess we decided to store internally decimal values with any scale. We have
column with type {{decimal(19,5)}} , but in cache we store decimal with scale =
7. We perform select returning this value - what should we do in this case:
return value with greater scale (7) that specified in the type (5)? Or should
we round it ( to scale = 5)? Jdbc spec says we should return full *precision*
value.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11734:
--
Fix Version/s: 2.8
> IgniteCache.replace(k, v, nv) requires classes when element is null
> ---
>
> Key: IGNITE-11734
> URL: https://issues.apache.org/jira/browse/IGNITE-11734
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example execute this code:
> {code}
> cache.replace(i, new Entity(), new Entity())
> {code}
> when cache have not a value by the key.
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> ClientP2P$Entity
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
> ... 39 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11734:
--
Ignite Flags: (was: Docs Required)
> IgniteCache.replace(k, v, nv) requires classes when element is null
> ---
>
> Key: IGNITE-11734
> URL: https://issues.apache.org/jira/browse/IGNITE-11734
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example execute this code:
> {code}
> cache.replace(i, new Entity(), new Entity())
> {code}
> when cache have not a value by the key.
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> ClientP2P$Entity
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
> ... 39 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-11734:
--
Assignee: Vladislav Pyatkov
> IgniteCache.replace(k, v, nv) requires classes when element is null
> ---
>
> Key: IGNITE-11734
> URL: https://issues.apache.org/jira/browse/IGNITE-11734
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> For example execute this code:
> {code}
> cache.replace(i, new Entity(), new Entity())
> {code}
> when cache have not a value by the key.
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> ClientP2P$Entity
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
> ... 39 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11624) Discovery SPI: The client can handle events from the previous cluster after reconnect.
[
https://issues.apache.org/jira/browse/IGNITE-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816180#comment-16816180
]
Amelchev Nikita commented on IGNITE-11624:
--
I have prepared PR to fix the issue.
I added the future in the DiscoverySpiListener to wait for all previous events
before the disconnect event will be processed.
Discovery implementations wait for the discovery will be notified on disconnect
before reconnecting attempt. The future in the discovery listener will wait for
handling the disconnect event by the event thread. Therefore no one previous
cluster event will be processed after reconnecting attempt.
[~agoncharuk], Hi, could you take a look, please?
> Discovery SPI: The client can handle events from the previous cluster after
> reconnect.
> --
>
> Key: IGNITE-11624
> URL: https://issues.apache.org/jira/browse/IGNITE-11624
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Discovery has a queue for events. It's processed by event thread. If we hold
> up event processing using a listener on the client side and restarts cluster
> - the client will reconnect. After it reconnects it will continue processing
> events from the previous cluster.
> This behavior produces bugs in MvccProcessor (IGNITE-11460) and [hanging of
> partitions exchange|https://github.com/NSAmelchev/ignite/pull/26/files] on
> the client side. The reason is that discovery notifies components about
> reconnection in the notifier thread by calling the 'onLocalJoin' method.
> After it (or at the same time), components can process events from the
> previous cluster in their listeners and break their logic.
> The order of events is fine - after processing previous cluster events - it
> will process client disconnection/reconnection and new cluster events.
> The possible solution is to fix discovery logic. Make a guarantee that no one
> event from the previous cluster will be processed after the client reconnect
> ('onLocalJoin' called). For example, wait for the client disconnect event
> will be processed in the discovery event thread. Then start attempt to
> reconnect.
> [Dev-list
> discussion.|http://apache-ignite-developers.2346864.n4.nabble.com/The-client-can-handle-events-from-the-previous-cluster-after-reconnect-td41392.html]
> [Reproducer.|https://github.com/NSAmelchev/ignite/pull/26/files]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11624) Discovery SPI: The client can handle events from the previous cluster after reconnect.
[
https://issues.apache.org/jira/browse/IGNITE-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816177#comment-16816177
]
Ignite TC Bot commented on IGNITE-11624:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3571191buildTypeId=IgniteTests24Java8_RunAll]
> Discovery SPI: The client can handle events from the previous cluster after
> reconnect.
> --
>
> Key: IGNITE-11624
> URL: https://issues.apache.org/jira/browse/IGNITE-11624
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Discovery has a queue for events. It's processed by event thread. If we hold
> up event processing using a listener on the client side and restarts cluster
> - the client will reconnect. After it reconnects it will continue processing
> events from the previous cluster.
> This behavior produces bugs in MvccProcessor (IGNITE-11460) and [hanging of
> partitions exchange|https://github.com/NSAmelchev/ignite/pull/26/files] on
> the client side. The reason is that discovery notifies components about
> reconnection in the notifier thread by calling the 'onLocalJoin' method.
> After it (or at the same time), components can process events from the
> previous cluster in their listeners and break their logic.
> The order of events is fine - after processing previous cluster events - it
> will process client disconnection/reconnection and new cluster events.
> The possible solution is to fix discovery logic. Make a guarantee that no one
> event from the previous cluster will be processed after the client reconnect
> ('onLocalJoin' called). For example, wait for the client disconnect event
> will be processed in the discovery event thread. Then start attempt to
> reconnect.
> [Dev-list
> discussion.|http://apache-ignite-developers.2346864.n4.nabble.com/The-client-can-handle-events-from-the-previous-cluster-after-reconnect-td41392.html]
> [Reproducer.|https://github.com/NSAmelchev/ignite/pull/26/files]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816173#comment-16816173 ] Maxim Karavaev commented on IGNITE-11346: - BTW, where and how can I find a current release commit in the repo? There are several branches and tags, but nothing looks like the one, which is available for download on the official site. > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Priority: Minor > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816170#comment-16816170 ] Maxim Karavaev commented on IGNITE-11346: - Hi [~ibessonov] , I've added a Unit test. Unfortunately, I didn't get how are they structured, so I just extended one of the most prominent in my opinion and added a method. Regarding the running existing tests - I've tried to execute them but lost all my patience after an hour of waiting for their finishing, sorry. At least, the GridClient - related tests were finished green. > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Priority: Minor > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11732) Multi-merged partitions exchange future may hang if node left event is received last
[
https://issues.apache.org/jira/browse/IGNITE-11732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816169#comment-16816169
]
Alexey Goncharuk commented on IGNITE-11732:
---
[~Jokser], can you take a look at the change?
> Multi-merged partitions exchange future may hang if node left event is
> received last
>
>
> Key: IGNITE-11732
> URL: https://issues.apache.org/jira/browse/IGNITE-11732
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The scenario is similar to IGNITE-11204, but several exchanges should be
> merged. If in this case a merged-exchange node is left and all other nodes
> messages are already received, the exchange will not be completed because
> {{F.isEmpty(mergedJoinExchMsgs)}} is {{false}}.
> Looks like we should decrement the {{awaitMergedMsgs}} and check this field
> for {{0}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11732) Multi-merged partitions exchange future may hang if node left event is received last
[
https://issues.apache.org/jira/browse/IGNITE-11732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816166#comment-16816166
]
Ignite TC Bot commented on IGNITE-11732:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3578862]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3573028buildTypeId=IgniteTests24Java8_RunAll]
> Multi-merged partitions exchange future may hang if node left event is
> received last
>
>
> Key: IGNITE-11732
> URL: https://issues.apache.org/jira/browse/IGNITE-11732
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The scenario is similar to IGNITE-11204, but several exchanges should be
> merged. If in this case a merged-exchange node is left and all other nodes
> messages are already received, the exchange will not be completed because
> {{F.isEmpty(mergedJoinExchMsgs)}} is {{false}}.
> Looks like we should decrement the {{awaitMergedMsgs}} and check this field
> for {{0}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11717) Web console: project generation runtime error caused by IGFS
[ https://issues.apache.org/jira/browse/IGNITE-11717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816158#comment-16816158 ] Ilya Borisov commented on IGNITE-11717: --- [~kuaw26] the fix looks good to me, if it works. Maybe add a unit/e2e test? > Web console: project generation runtime error caused by IGFS > > > Key: IGNITE-11717 > URL: https://issues.apache.org/jira/browse/IGNITE-11717 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: image-2019-04-10-17-52-48-599.png > > Time Spent: 10m > Remaining Estimate: 0h > > *What happens:* > Runtime error in console. > !image-2019-04-10-17-52-48-599.png! > How to reproduce: > 1. Go to cluster configuration/create igfs. > 2. Choose "Caching" FS factory. > 3. Choose "Chained" user name mapper. > 4. Open new mapper sub form, choose custom. > 5. Change FS factory a couple of time, change it back to "Caching". > 6. Do the same with with "Name mapper" select, change it back to "Custom". > 7. If the error does not happen, play around by changing other select values. > *Expected behavior:* > Run time error should not happen. > This happens in master. [~vsisko] I think you should look into why `bean` is > `null` or handle this case gracefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11717) Web console: project generation runtime error caused by IGFS
[ https://issues.apache.org/jira/browse/IGNITE-11717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11717: -- Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Web console: project generation runtime error caused by IGFS > > > Key: IGNITE-11717 > URL: https://issues.apache.org/jira/browse/IGNITE-11717 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: image-2019-04-10-17-52-48-599.png > > > *What happens:* > Runtime error in console. > !image-2019-04-10-17-52-48-599.png! > How to reproduce: > 1. Go to cluster configuration/create igfs. > 2. Choose "Caching" FS factory. > 3. Choose "Chained" user name mapper. > 4. Open new mapper sub form, choose custom. > 5. Change FS factory a couple of time, change it back to "Caching". > 6. Do the same with with "Name mapper" select, change it back to "Custom". > 7. If the error does not happen, play around by changing other select values. > *Expected behavior:* > Run time error should not happen. > This happens in master. [~vsisko] I think you should look into why `bean` is > `null` or handle this case gracefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11717) Web console: project generation runtime error caused by IGFS
[ https://issues.apache.org/jira/browse/IGNITE-11717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816139#comment-16816139 ] Vasiliy Sisko commented on IGNITE-11717: Fixed generation of Custom user name mapper of IGFS Secondary file system when class name is not configured. Fixed generation of Custom file system factory of IGFS Secondary file system when class name is not configured. > Web console: project generation runtime error caused by IGFS > > > Key: IGNITE-11717 > URL: https://issues.apache.org/jira/browse/IGNITE-11717 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Major > Attachments: image-2019-04-10-17-52-48-599.png > > > *What happens:* > Runtime error in console. > !image-2019-04-10-17-52-48-599.png! > How to reproduce: > 1. Go to cluster configuration/create igfs. > 2. Choose "Caching" FS factory. > 3. Choose "Chained" user name mapper. > 4. Open new mapper sub form, choose custom. > 5. Change FS factory a couple of time, change it back to "Caching". > 6. Do the same with with "Name mapper" select, change it back to "Custom". > 7. If the error does not happen, play around by changing other select values. > *Expected behavior:* > Run time error should not happen. > This happens in master. [~vsisko] I think you should look into why `bean` is > `null` or handle this case gracefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11734:
---
Description:
For example execute this code:
{code}
cache.replace(i, new Entity(), new Entity())
{code}
when cache have not a value by the key.
{noformat}
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
ClientP2P$Entity
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
... 31 more
Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
... 39 more
{noformat}
was:
For example execute this code:
{code}
cache.replace(i, new Entity(i + ""), new Entity(i + ""))
{code}
when cache have not a value by the key.
{noformat}
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
ClientP2P$Entity
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
... 31 more
Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
... 39 more
{noformat}
> IgniteCache.replace(k, v, nv) requires classes when
[jira] [Updated] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11734:
---
Description:
For example execute this code:
{code}
cache.replace(i, new Entity(i + ""), new Entity(i + ""))
{code}
when cache have not a value by the key.
{noformat}
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
ClientP2P$Entity
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
... 31 more
Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
... 39 more
{noformat}
was:
For example execute this code:
{code}
cache.replace(i, new Entity(i + ""), new Entity(i + ""))
{code}
when cache have not a value by the key.
{noformat}
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
ClientP2P$Entity
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
... 31 more
Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
... 39 more
{noformat}
> IgniteCache.replace(k, v, nv)
[jira] [Updated] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11734:
---
Description:
For example execute this code:
{code}
cache.replace(i, new Entity(i + ""), new Entity(i + ""))
{code}
when cache have not a value by the key.
{noformat}
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
ClientP2P$Entity
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
at
org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
... 31 more
Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
... 39 more
{noformat}
> IgniteCache.replace(k, v, nv) requires classes when element is null
> ---
>
> Key: IGNITE-11734
> URL: https://issues.apache.org/jira/browse/IGNITE-11734
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> For example execute this code:
> {code}
> cache.replace(i, new Entity(i + ""), new Entity(i + ""))
> {code}
> when cache have not a value by the key.
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> ClientP2P$Entity
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at
[jira] [Updated] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[ https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-11734: --- Summary: IgniteCache.replace(k, v, nv) requires classes when element is null (was: IgniteCache.replace(k, v, nv) requires classes when element is null or old value - null) > IgniteCache.replace(k, v, nv) requires classes when element is null > --- > > Key: IGNITE-11734 > URL: https://issues.apache.org/jira/browse/IGNITE-11734 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[ https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-11735: Description: Under IGNITE-11392 we have added two new closures (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). In case we'll assemble mixed cluster (some nodes contain the patch, some don't), we may bump into situation when closures are sent to node that doesn't contain corresponding classes in classpath. Normally, closures will be deployed to "old" node via peer-to-peer class deployment. However, p2p may be disabled in configuration, which will cause ClassNotFoundException on "old" node. We should register IGNITE-11392 in IgniteFeatures (recent example: IGNITE-11598) and filter out nodes that don't support new feature before sending compute. was: Under IGNITE-11392 we have added two new closures (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). In case we'll assemble mixed cluster (some nodes contain the patch, some don't), we may bump into situation when closures are sent to node that doesn't contain corresponding classes in classpath. Normally, closurer will be deployed to "old" node via peer-to-peer class deployment. However, p2p may be disabled in configuration, which will cause ClassNotFoundException on "old" node. We should register IGNITE-11392 in IgniteFeatures (recent example: IGNITE-11598) and filter out nodes that don't support new feature before sending compute. > Safely handle new closures of IGNITE-11392 in mixed cluster environment > --- > > Key: IGNITE-11735 > URL: https://issues.apache.org/jira/browse/IGNITE-11735 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > > Under IGNITE-11392 we have added two new closures > (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). > In case we'll assemble mixed cluster (some nodes contain the patch, some > don't), we may bump into situation when closures are sent to node that > doesn't contain corresponding classes in classpath. Normally, closures will > be deployed to "old" node via peer-to-peer class deployment. However, p2p may > be disabled in configuration, which will cause ClassNotFoundException on > "old" node. > We should register IGNITE-11392 in IgniteFeatures (recent example: > IGNITE-11598) and filter out nodes that don't support new feature before > sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9700: Ignite Flags: (was: Docs Required) > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9700: Labels: mesos (was: ) > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Labels: mesos > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9700: Component/s: build > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Labels: mesos > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
Ivan Rakov created IGNITE-11735: --- Summary: Safely handle new closures of IGNITE-11392 in mixed cluster environment Key: IGNITE-11735 URL: https://issues.apache.org/jira/browse/IGNITE-11735 Project: Ignite Issue Type: Improvement Reporter: Ivan Rakov Assignee: Denis Chudov Fix For: 2.8 Under IGNITE-11392 we have added two new closures (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). In case we'll assemble mixed cluster (some nodes contain the patch, some don't), we may bump into situation when closures are sent to node that doesn't contain corresponding classes in classpath. Normally, closurer will be deployed to "old" node via peer-to-peer class deployment. However, p2p may be disabled in configuration, which will cause ClassNotFoundException on "old" node. We should register IGNITE-11392 in IgniteFeatures (recent example: IGNITE-11598) and filter out nodes that don't support new feature before sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null or old value - null
Vladislav Pyatkov created IGNITE-11734: -- Summary: IgniteCache.replace(k, v, nv) requires classes when element is null or old value - null Key: IGNITE-11734 URL: https://issues.apache.org/jira/browse/IGNITE-11734 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10654) Report in case of creating index with already existing fields collection.
[
https://issues.apache.org/jira/browse/IGNITE-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816065#comment-16816065
]
Ignite TC Bot commented on IGNITE-10654:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Start Nodes{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3577834]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds - 0,0% fails in
last 145 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3526276buildTypeId=IgniteTests24Java8_RunAll]
> Report in case of creating index with already existing fields collection.
> -
>
> Key: IGNITE-10654
> URL: https://issues.apache.org/jira/browse/IGNITE-10654
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Report in log if new index creating with already existing fields collection.
> for example, need to log warn here:
> {code:java}
> cache.query(new SqlFieldsQuery("create index \"idx1\" on Val(keyStr,
> keyLong)"));
> cache.query(new SqlFieldsQuery("create index \"idx3\" on Val(keyStr,
> keyLong)"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9352) Web Console: Investigate how correctly use package-lock.json
[ https://issues.apache.org/jira/browse/IGNITE-9352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9352: - Ignite Flags: (was: Docs Required) > Web Console: Investigate how correctly use package-lock.json > > > Key: IGNITE-9352 > URL: https://issues.apache.org/jira/browse/IGNITE-9352 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > We need to investigate how correctly use package-lock.json and "^" symbol in > package.json. > Using "^" allows to use latest version of dependencies, but sometimes it can > break build or application just before release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9352) Web Console: Investigate how correctly use package-lock.json
[ https://issues.apache.org/jira/browse/IGNITE-9352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9352: - Priority: Major (was: Blocker) > Web Console: Investigate how correctly use package-lock.json > > > Key: IGNITE-9352 > URL: https://issues.apache.org/jira/browse/IGNITE-9352 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > We need to investigate how correctly use package-lock.json and "^" symbol in > package.json. > Using "^" allows to use latest version of dependencies, but sometimes it can > break build or application just before release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9352) Web Console: Investigate how correctly use package-lock.json
[ https://issues.apache.org/jira/browse/IGNITE-9352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9352: - Fix Version/s: (was: 2.8) > Web Console: Investigate how correctly use package-lock.json > > > Key: IGNITE-9352 > URL: https://issues.apache.org/jira/browse/IGNITE-9352 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > > We need to investigate how correctly use package-lock.json and "^" symbol in > package.json. > Using "^" allows to use latest version of dependencies, but sometimes it can > break build or application just before release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11696) Create JMX metric for current PME execution time
[ https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11696: --- Fix Version/s: 2.8 > Create JMX metric for current PME execution time > > > Key: IGNITE-11696 > URL: https://issues.apache.org/jira/browse/IGNITE-11696 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Now PME process can't be monitored from JMX, only from the logs. It makes > sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11711) Web console: MS SQL server missing JDBC download link
[ https://issues.apache.org/jira/browse/IGNITE-11711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11711: -- Fix Version/s: 2.8 > Web console: MS SQL server missing JDBC download link > - > > Key: IGNITE-11711 > URL: https://issues.apache.org/jira/browse/IGNITE-11711 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2019-04-10-12-54-22-561.png > > Time Spent: 26m > Remaining Estimate: 0h > > *What happens:* > In configuration / advanced / caches / store if user selects "JDBC Pojo store > factory" and "MS SQL Server" dialect, a link labeled "Download JDBC drivers?" > is displayed. When "oracle" or "IBM" dialects are selected, the link leads to > a proper download page, while "MS" dialect link leads nowhere. > !image-2019-04-10-12-54-22-561.png! > *Expected behavior:* > If there is a download page for MS JDBC driver, add it's URL to JDBC_LINKS > provider. If there's none, maybe don't show the link or show appropriate > plain text? > The issue was reproduced in master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816001#comment-16816001
]
Ivan Pavlukhin commented on IGNITE-11708:
-
[~ivanan.fed], yes it seems that it is hard to be sure that all tests methods
were executed. For example, in junit 4 is simple to skip all test methods but
having all them as passed in report with a _rule_ that does not _evaluate base
statement_. Perhaps, we can find some ideas in the Internet. I think we can
tackle with writing a special test extending
_IgniteConfigVariationsAbstractTest_ checking in _after class_ callback that a
test method (or couple of methods and perhaps other before/after callbacks)
were executed. Schematically, it is:
{code}
public class VariationExecutionTest extends IgniteConfigVariationsAbstractTest {
private boolean testExecuted = false;
@AfterClass
public void validate() {
assertTrue(testExecuted);
}
@Test
public void test() {
testExecuted = true;
}
}
{code}
Also I have a comment about _rules_ execution order. It seems that when we have
a {{RuleChain}} annotated with a {{@Rule}} annotaiton which includes another
rule (let's is is _ruleA_) annotated with {{@Rule}} then _ruleA_ will be
executed twice. And it does not look desired. First we should look for common
best practice how to solve it.
Also it is still unclear and quite interesting why all _variation_ test methods
are skipped. Please write back once you find a clue.
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
