[jira] [Commented] (IGNITE-12805) Node fails to restart
[
https://issues.apache.org/jira/browse/IGNITE-12805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077558#comment-17077558
]
Ignite TC Bot commented on IGNITE-12805:
{panel:title=Branch: [pull/7562/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5196641buildTypeId=IgniteTests24Java8_RunAll]
> Node fails to restart
> -
>
> Key: IGNITE-12805
> URL: https://issues.apache.org/jira/browse/IGNITE-12805
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Sarunas Valaskevicius
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. nodes have default persistence false, but there is a cache region with
> persistence on.
> 2. a cluster starts ok with ignite data directory clean
> 3. but when the nodes are restarted, they fail and can never join the cluster
> again:
>
> {code:java}
> 12:352020-03-19_13:34:30.273 [main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11073) Persistence cache snapshot
[
https://issues.apache.org/jira/browse/IGNITE-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077496#comment-17077496
]
Ignite TC Bot commented on IGNITE-11073:
{panel:title=Branch: [pull/7607/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5199634buildTypeId=IgniteTests24Java8_RunAll]
> Persistence cache snapshot
> --
>
> Key: IGNITE-11073
> URL: https://issues.apache.org/jira/browse/IGNITE-11073
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-28, iep-43
> Fix For: 2.9
>
> Time Spent: 31h 10m
> Remaining Estimate: 0h
>
> *Snapshot requirements*
> # Users must have the ability to create a snapshot of persisted user data
> (in-memory is out of the scope).
> # Users must have the ability to create a snapshot from the cluster under the
> load without cluster deactivation.
> # The snapshot process must not block for a long time any of the user
> transactions (short-time blocks are acceptable).
> # The snapshot process must allow creating a data snapshot on each node and
> transfer it to any of the remote nodes for internal cluster needs.
> # The created snapshot at the cluster-level must be fully consistent from
> cluster-wide terms, there should not be any incomplete transactions inside.
> # The snapshot of each node must be consistent – cache partitions, binary
> meta, etc. must not have unnecessary changes.
> *The following API must be available:*
> # [public] Java API
> # [public] JMX MBean
> # [internal] File Transmission
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12872) Check of correct work of explicit security permissions
[ https://issues.apache.org/jira/browse/IGNITE-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12872: - Ignite Flags: (was: Docs Required,Release Notes Required) > Check of correct work of explicit security permissions > -- > > Key: IGNITE-12872 > URL: https://issues.apache.org/jira/browse/IGNITE-12872 > Project: Ignite > Issue Type: Test >Reporter: Nikolay Izhikov >Assignee: Denis Garus >Priority: Major > > We need to add 3 tests that checks explicit security permission for the cache. > 1. If a user has only CACHE_READ permission for some cache. > * get(and other read operations are permitted) > * put, remove (and other write operations are prohibited). > 2. If a user has only CACHE_REMOVE permission for some cache. > * put, get(and other reads/write operations are prohibited) > * remove (and other remove operations are permitted). > 3. If a user has only CACHE_PUT permission for some cache. > * get, remove(and other reads/remove operations are prohibited) > * put (and other write operations are permitted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12872) Check of correct work of explicit security permissions
[ https://issues.apache.org/jira/browse/IGNITE-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12872: - Description: We need to add 3 tests that checks explicit security permission for the cache. 1. If a user has only CACHE_READ permission for some cache. * get(and other read operations are permitted) * put, remove (and other write operations are prohibited). 2. If a user has only CACHE_REMOVE permission for some cache. * put, get(and other reads/write operations are prohibited) * remove (and other remove operations are permitted). 3. If a user has only CACHE_PUT permission for some cache. * get, remove(and other reads/remove operations are prohibited) * put (and other write operations are permitted). was: We need to add 3 tests that checks explicit security permission for the cache. 1. If a user has only CACHE_READ permission for some cache. * get(and other read operations are permitted) * put, remove (and other write operations are prohibited). 2. If a user has only CACHE_REMOVE permission for some cache. * put, get(and other reads/write operations are prohibited) * remove (and other remove operations are permitted). 3. If a user has only CACHE_WRITE permission for some cache. * get, remove(and other reads/remove operations are prohibited) * put (and other write operations are permitted). > Check of correct work of explicit security permissions > -- > > Key: IGNITE-12872 > URL: https://issues.apache.org/jira/browse/IGNITE-12872 > Project: Ignite > Issue Type: Test >Reporter: Nikolay Izhikov >Assignee: Denis Garus >Priority: Major > > We need to add 3 tests that checks explicit security permission for the cache. > 1. If a user has only CACHE_READ permission for some cache. > * get(and other read operations are permitted) > * put, remove (and other write operations are prohibited). > 2. If a user has only CACHE_REMOVE permission for some cache. > * put, get(and other reads/write operations are prohibited) > * remove (and other remove operations are permitted). > 3. If a user has only CACHE_PUT permission for some cache. > * get, remove(and other reads/remove operations are prohibited) > * put (and other write operations are permitted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12872) Check of correct work of explicit security permissions
[ https://issues.apache.org/jira/browse/IGNITE-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12872: Assignee: Denis Garus > Check of correct work of explicit security permissions > -- > > Key: IGNITE-12872 > URL: https://issues.apache.org/jira/browse/IGNITE-12872 > Project: Ignite > Issue Type: Test >Reporter: Nikolay Izhikov >Assignee: Denis Garus >Priority: Major > > We need to add 3 tests that checks explicit security permission for the cache. > 1. If a user has only CACHE_READ permission for some cache. > * get(and other read operations are permitted) > * put, remove (and other write operations are prohibited). > 2. If a user has only CACHE_REMOVE permission for some cache. > * put, get(and other reads/write operations are prohibited) > * remove (and other remove operations are permitted). > 3. If a user has only CACHE_WRITE permission for some cache. > * get, remove(and other reads/remove operations are prohibited) > * put (and other write operations are permitted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12549: - Release Note: Fixed incorrect iteration of replicated cache during rebalance. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8.1 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12549: - Fix Version/s: (was: 2.9) 2.8.1 > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8.1 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12872) Check of correct work of explicit security permissions
Nikolay Izhikov created IGNITE-12872: Summary: Check of correct work of explicit security permissions Key: IGNITE-12872 URL: https://issues.apache.org/jira/browse/IGNITE-12872 Project: Ignite Issue Type: Test Reporter: Nikolay Izhikov We need to add 3 tests that checks explicit security permission for the cache. 1. If a user has only CACHE_READ permission for some cache. * get(and other read operations are permitted) * put, remove (and other write operations are prohibited). 2. If a user has only CACHE_REMOVE permission for some cache. * put, get(and other reads/write operations are prohibited) * remove (and other remove operations are permitted). 3. If a user has only CACHE_WRITE permission for some cache. * get, remove(and other reads/remove operations are prohibited) * put (and other write operations are permitted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-2771) Document machine safety
[ https://issues.apache.org/jira/browse/IGNITE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077381#comment-17077381 ] Denis A. Magda commented on IGNITE-2771: We already have a section briefly covering how to configure the rack-awareness [1] however the section lacks configuration examples and might miss some other important items. Instead, we should create a dedicated page related to the "rack-awareness" and merge the data from the existing paragraph with an example from the JavaDoc [2] [1] https://apacheignite.readme.io/docs/affinity-collocation#section-crash-safe-affinity [2] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html > Document machine safety > --- > > Key: IGNITE-2771 > URL: https://issues.apache.org/jira/browse/IGNITE-2771 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-2771) Document machine safety
[ https://issues.apache.org/jira/browse/IGNITE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda reassigned IGNITE-2771: -- Assignee: (was: Prachi Garg) > Document machine safety > --- > > Key: IGNITE-2771 > URL: https://issues.apache.org/jira/browse/IGNITE-2771 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12871) Calcite integration. Broadcast to hash conversion without exchange.
[ https://issues.apache.org/jira/browse/IGNITE-12871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-12871: - Assignee: Igor Seliverstov > Calcite integration. Broadcast to hash conversion without exchange. > --- > > Key: IGNITE-12871 > URL: https://issues.apache.org/jira/browse/IGNITE-12871 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > Use a partition filter instead of network communications -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12871) Calcite integration. Broadcast to hash conversion without exchange.
Igor Seliverstov created IGNITE-12871: - Summary: Calcite integration. Broadcast to hash conversion without exchange. Key: IGNITE-12871 URL: https://issues.apache.org/jira/browse/IGNITE-12871 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Use a partition filter instead of network communications -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[
https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077263#comment-17077263
]
Aleksey Plekhanov commented on IGNITE-12853:
# I see no difference in readability between {{isUserAttributesSupported()}}
and {{isFeatureSupported(USER_ATTRIBUTES)}}, but the second approach doesn't
require code duplication.
# Again, version comparison was always in the context of some feature, there
is no need for research. At least if you want to use features here, you should
introduce something like features bounded to versions (not bounded to feature
mask), in this case, you can use 'if !isFeatureSupported(MY_FEATURE) then error
"version MY_FEATURE.version() required', but not 'if isMyFeatureSupported()
then error "version x.x.x required"'
# Initially, thin client implementation always has dependencies on core. All
marshalling/unarshalling routine can't be done without core. Some of core
classes even exposed to thin client public API (see queries). I see no reason
why can't we use enum which was created for thin clients in thin client
internal API and why we should duplicate code instead.
> ThinClient: Introduce Features for thin clients
> ---
>
> Key: IGNITE-12853
> URL: https://issues.apache.org/jira/browse/IGNITE-12853
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> As we have a lot of different thin clients now, maintained by different
> people, the issues with our backward compatibility mechanism becomes more and
> more prominent.
> Currently, we use protocol versioning as the only approach to provide
> backward compatibility. The main issue of this approach is that we can not
> skip some change in protocol and implement i.e. protocol of version 1.5
> without implementation of 1.4. There are many cases when one may want to do
> so: e.g. when feature provided in 1.4 is not relevant for a specific client,
> or when protocol version 1.5 contains urgent fix or feature which is easy to
> implement, but its blocked by not-so-urgent and hard-to-implement feature
> introduced in 1.4.
> So to fix this issue I propose to introduce another backward compatibility
> mechanism. The idea is to send "supported features" mask by a client to a
> server, which should be answered with the same mask by the server. The
> resulting set of enabled features is acquired with a simple logical "AND"
> operation on these two masks.
> This change has many other positive effects:
> 1. It improves readability and also potentially simplifies debugging.
> 2. It gives users the ability to enable or disable features of thin clients
> on both server and client as they desire.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12726) Cache names can't be used as part of DistributedMetaStorage keys
[ https://issues.apache.org/jira/browse/IGNITE-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077239#comment-17077239 ] Sergey Chugunov commented on IGNITE-12726: -- [~ibessonov], Change looks good to me, lets merge it to master branch. Thank you for contribution! > Cache names can't be used as part of DistributedMetaStorage keys > > > Key: IGNITE-12726 > URL: https://issues.apache.org/jira/browse/IGNITE-12726 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Issue was discovered during the implementation of IGNITE-12721. Here's a shot > version of the description: > * local MetaStorage can't handle keys that have more than 64 bytes in their > "byte[]" representation. Since DistributedMetaStorage uses it and adds some > specific prefixes on top, we have a strict limit on the key length. > Just to be clear - it just won't work, IGNITE-12721 only adds a valid > exception and meaningful error message to the API. > > Recently IGNITE-11987 from [IEP-35] has been merged to master and 2.8 release > branch, and it does exactly whats written in the title - adds cache name as a > part of the key. So, if you use long cache name in, for example, test called > "org.apache.ignite.internal.metric.MetricsConfigurationTest#testConfigRemovedOnCacheRemove", > you'll get AssertionErrors in log. By "long" I mean about 50 symbols. This > should not happen. > > I see two options here: > * leave everything as it is and change keys format; > * modify MetaStorage so that it can handle longer keys. I prefer this one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077235#comment-17077235 ] Igor Sapego commented on IGNITE-12853: -- [~alex_pl] 1. I think it's much more readable and understandable for any newcomer. Also, code like this is easier to fix or change. 2. The same. Many versions were not even labeled in the code, so no one could find out what kind of changes were introduced by a certain version without additional research. Now it's much more easy to read, understand and thus change. Why do you think that numbers comparison is more intuitive? 3. All classes in Java thin client are duplicated, see ProtocolVersion for example. I believe, initially this was done for Java Thin client to have no dependencies on core, which looks reasonable and anyway this is not a ticket to change this approach. For the server-side interface -- this is a good catch, I belive I should copy it as well. > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12726) Cache names can't be used as part of DistributedMetaStorage keys
[
https://issues.apache.org/jira/browse/IGNITE-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077178#comment-17077178
]
Ignite TC Bot commented on IGNITE-12726:
{panel:title=Branch: [pull/7606/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5186870buildTypeId=IgniteTests24Java8_RunAll]
> Cache names can't be used as part of DistributedMetaStorage keys
>
>
> Key: IGNITE-12726
> URL: https://issues.apache.org/jira/browse/IGNITE-12726
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Issue was discovered during the implementation of IGNITE-12721. Here's a shot
> version of the description:
> * local MetaStorage can't handle keys that have more than 64 bytes in their
> "byte[]" representation. Since DistributedMetaStorage uses it and adds some
> specific prefixes on top, we have a strict limit on the key length.
> Just to be clear - it just won't work, IGNITE-12721 only adds a valid
> exception and meaningful error message to the API.
>
> Recently IGNITE-11987 from [IEP-35] has been merged to master and 2.8 release
> branch, and it does exactly whats written in the title - adds cache name as a
> part of the key. So, if you use long cache name in, for example, test called
> "org.apache.ignite.internal.metric.MetricsConfigurationTest#testConfigRemovedOnCacheRemove",
> you'll get AssertionErrors in log. By "long" I mean about 50 symbols. This
> should not happen.
>
> I see two options here:
> * leave everything as it is and change keys format;
> * modify MetaStorage so that it can handle longer keys. I prefer this one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12856) Fix two corruptedIndexPartition flaky tests.
[ https://issues.apache.org/jira/browse/IGNITE-12856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-12856: --- Reviewer: Alexey Scherbakov > Fix two corruptedIndexPartition flaky tests. > > > Key: IGNITE-12856 > URL: https://issues.apache.org/jira/browse/IGNITE-12856 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > TC highlights two new flack tests: > org.apache.ignite.util.GridCommandHandlerIndexingTest#testCorruptedIndexPartitionShouldFailValidationWithCrc > > org.apache.ignite.util.GridCommandHandlerIndexingTest#testCorruptedIndexPartitionShouldFailValidationWithoutCrc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12870) Fix test JdbcThinTransactionsLeaksMvccTest after connection manager refactoring
Taras Ledkov created IGNITE-12870:
-
Summary: Fix test JdbcThinTransactionsLeaksMvccTest after
connection manager refactoring
Key: IGNITE-12870
URL: https://issues.apache.org/jira/browse/IGNITE-12870
Project: Ignite
Issue Type: Test
Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.9
The test {{JdbcThinTransactionsLeaksMvccTest#testLeaks}} is broken by the patch
IGNITE-12804. The method {{detachedConnectionCount}} must be change to check
used connection after connection manager refactoring.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
