[jira] [Created] (IGNITE-17519) Fix error handlers in Flow
Aleksandr created IGNITE-17519: -- Summary: Fix error handlers in Flow Key: IGNITE-17519 URL: https://issues.apache.org/jira/browse/IGNITE-17519 Project: Ignite Issue Type: Task Components: cli, ignite-3 Reporter: Aleksandr In FlowTest there is a couple of tests that reproduce the issue. In case the custom exception handerl is set to Flow it is not used in some cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-11547) ClassCastException when creating LOCAL cache on client in Data Region which is considered persistent
[ https://issues.apache.org/jira/browse/IGNITE-11547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-11547. -- Resolution: Won't Fix LOCAL caches removed from support. > ClassCastException when creating LOCAL cache on client in Data Region which > is considered persistent > > > Key: IGNITE-11547 > URL: https://issues.apache.org/jira/browse/IGNITE-11547 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Madhusudhan Reddy Vennapusa >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > If default region in cluster is persistent, then creating a LOCAL cache on > client will fail with: > org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast > to > org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx > This is unless there is a second non-persistent data region, and cache is > created in this non-persistent region. > I think this case calls for a check and helpful error message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-13076) Cluster read-only mode doesn't affect LOCAL caches
[
https://issues.apache.org/jira/browse/IGNITE-13076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov resolved IGNITE-13076.
--
Resolution: Won't Fix
> Cluster read-only mode doesn't affect LOCAL caches
> --
>
> Key: IGNITE-13076
> URL: https://issues.apache.org/jira/browse/IGNITE-13076
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
>
> You can make data modification operations with LOCAL cache even if cluster in
> a {{ACTIVE_READ_ONLY}} state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-9110) Tx commit hangs after cross-cache operations with LOCAL cache
[
https://issues.apache.org/jira/browse/IGNITE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov resolved IGNITE-9110.
-
Resolution: Won't Fix
> Tx commit hangs after cross-cache operations with LOCAL cache
> -
>
> Key: IGNITE-9110
> URL: https://issues.apache.org/jira/browse/IGNITE-9110
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ryabov Dmitrii
>Priority: Minor
>
> Commit hangs when tx contains operations on LOCAL and PARTITIONED or
> REPLICATED caches in some cases. Example:
> {code:java}
> public class LocalCacheFails extends GridCommonAbstractTest {
> /** */
> public void testLocalCache() throws Exception {
> IgniteEx ignite = startGrid(0);
> IgniteCache locCache =
> ignite.createCache(getConfig(LOCAL));
> IgniteCache partCache =
> ignite.createCache(getConfig(PARTITIONED));
> try (Transaction tx = ignite.transactions().txStart(OPTIMISTIC,
> SERIALIZABLE)) {
> locCache.put(1, 1);
> partCache.put(1, 1);
> tx.commit(); // Fails here.
> }
> }
> /** */
> private CacheConfiguration getConfig(CacheMode
> cacheMode) {
> CacheConfiguration cfg = new CacheConfiguration<>();
> cfg.setCacheMode(cacheMode);
> cfg.setName(cacheMode.name());
> cfg.setAtomicityMode(TRANSACTIONAL);
> return cfg;
> }
> }
> {code}
> Stacktrace here:
> {code:java}
> [18:05:44] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=ff3264cd461-707c41df-7a8c-4067-8367-5d941df0aec1, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
> colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
> trackTimeout=false, lb=null,
> thread=test-runner-#1%transactions.LocalCacheFails%,
> mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxStateImpl
> [activeCacheIds=[72607563,-887906071], recovery=false, txMap=[IgniteTxEntry
> [key=KeyCacheObjectImpl [part=0, val=1, hasValBytes=true], cacheId=72607563,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=0, val=1, hasValBytes=true],
> cacheId=72607563], val=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridLocalCacheEntry [super=GridCacheMapEntry [key=KeyCacheObjectImpl
> [part=0, val=1, hasValBytes=true], val=CacheObjectImpl [val=null,
> hasValBytes=true], ver=GridCacheVersion [topVer=144183944,
> order=1532703942007, nodeOrder=1], hash=1, extras=null, flags=2]],
> prepared=1, locked=false, nodeId=1068e98c-9c17-4fee-967b-8270,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=144183944,
> order=1532703942006, nodeOrder=1]], IgniteTxEntry [key=KeyCacheObjectImpl
> [part=1, val=1, hasValBytes=true], cacheId=-887906071, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> cacheId=-887906071], val=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtCacheEntry [rdrs=[], part=1, super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [part=1, val=1,
> hasValBytes=true], val=CacheObjectImpl [val=null, hasValBytes=true],
> ver=GridCacheVersion [topVer=144183944, order=1532703942007, nodeOrder=1],
> hash=1, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=[GridCacheMvccCandidate [nodeId=1068e98c-9c17-4fee-967b-8270,
> ver=GridCacheVersion [topVer=144183944, order=1532703942006, nodeOrder=1],
> threadId=14, id=2, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=2],
> reentry=null, otherNodeId=1068e98c-9c17-4fee-967b-8270,
> otherVer=GridCacheVersion [topVer=144183944, order=1532703942006,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=GridCacheVersion [topVer=144183944, order=1532703942006,
> nodeOrder=1], key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
>
[jira] [Assigned] (IGNITE-17309) Transactional support for partition scans
[
https://issues.apache.org/jira/browse/IGNITE-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-17309:
--
Assignee: Vladislav Pyatkov
> Transactional support for partition scans
> -
>
> Key: IGNITE-17309
> URL: https://issues.apache.org/jira/browse/IGNITE-17309
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> It's required to add transactional support to
> {code:java}
> org.apache.ignite.internal.table.InternalTable#scan {code}
> binding it to
> {code:java}
> org.apache.ignite.internal.storage.MvPartitionStorage#scan(java.util.function.Predicate,
> java.util.UUID) {code}
> along with acquiring corresponding locks, namely S_commit(table) - if a
> predicate can produce phantom reads, IS_commit(table) - otherwise.
> Besides transactional support itself, it worth to introduce direct storage
> reads from within PrimaryReplica instead of going through raft.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17514) Exception handling in InternalTableImpl
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17514: - Reviewer: Alexander Lapin > Exception handling in InternalTableImpl > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. > Need to throw ReplicaUnavailableException in case when Replica is not ready. > See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17514) Exception handling in InternalTableImpl
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17514: - Ignite Flags: (was: Docs Required,Release Notes Required) > Exception handling in InternalTableImpl > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. > Need to throw ReplicaUnavailableException in case when Replica is not ready. > See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17514) Exception handling in InternalTableImpl
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578565#comment-17578565 ] Alexander Lapin commented on IGNITE-17514: -- [~Sergey Uttsel] LGTM > Exception handling in InternalTableImpl > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. > Need to throw ReplicaUnavailableException in case when Replica is not ready. > See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15759) [IEP-80] Removal of LOCAL caches support
[ https://issues.apache.org/jira/browse/IGNITE-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578563#comment-17578563 ] Pavel Tupitsyn commented on IGNITE-15759: - Thin client and .NET changes look good to me. > [IEP-80] Removal of LOCAL caches support > > > Key: IGNITE-15759 > URL: https://issues.apache.org/jira/browse/IGNITE-15759 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Maxim Muzafarov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > LOCAL cachens has huge amount of known limitation and not intended to be used > in production environment. > Should be removed in 2.13 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17518) Actualize cli module
Aleksandr created IGNITE-17518: -- Summary: Actualize cli module Key: IGNITE-17518 URL: https://issues.apache.org/jira/browse/IGNITE-17518 Project: Ignite Issue Type: Task Components: cli, ignite-3 Reporter: Aleksandr 1) move all classes in CLI module under 'internal' package 2) remove cli-common module that is not needed any more. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17517) Clean up todo's with closed tickets in CLI
Aleksandr created IGNITE-17517: -- Summary: Clean up todo's with closed tickets in CLI Key: IGNITE-17517 URL: https://issues.apache.org/jira/browse/IGNITE-17517 Project: Ignite Issue Type: Task Components: cli, ignite-3 Reporter: Aleksandr There are a couple of todo's that are forgotten, clean them up or create new tickets that are not in CLOSED state. https://issues.apache.org/jira/browse/IGNITE-17091 https://issues.apache.org/jira/browse/IGNITE-17092 https://issues.apache.org/jira/browse/IGNITE-17162 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17516) Support fields with same name in different members of dynamic config hierarcny
Roman Puchkovskiy created IGNITE-17516: -- Summary: Support fields with same name in different members of dynamic config hierarcny Key: IGNITE-17516 URL: https://issues.apache.org/jira/browse/IGNITE-17516 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha6 In IGNITE-17497, an ability to have more than 2 levels of polymorphic configuration classes (base and instance) is introduced. This means that fields with same name might present on several levels of hierarchy. Currently, it's not clear whether it's supported (as we have 2 levels, more than one) or forbidden. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17515) tablesByIdVv exceptional completing can lead to resource leaking
[
https://issues.apache.org/jira/browse/IGNITE-17515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17515:
-
Description:
Currently, {{tablesByIdVv}}, which holds the mapping for table ids and table
implementations, is updated through the mechanism of versioned values, and
{{tablesByIdVv}} is dependent on a list of other versioned values, like schema
versioned value, calcite versioned value and etc. If one of this versioned
value is completed exceptionally, {{tablesByIdVv}} will also be completed
exceptionally, and that means that we cannot access to the the mapping for
table ids and tables, and actually that means, that all tables will be
unreachable.
Also, that means, that tables can't be properly stopped, which can lead to
resource leaking.
Expected behaviour is when exceptional situations for {{tablesByIdVv}} updates
are handled, tables, that weren't participated in the updated, still
accessible, and tables, that were affected, properly stopped.
was:
Currently, {{tablesByIdVv}}, which is holding the mapping for table ids and
table implementations, is updated through the mechanism of versioned values,
and {{tablesByIdVv}} is dependent on a list of other versioned values, like
schema versioned value, calcite versioned value and etc. If one of this
versioned value is completed exceptionally, {{tablesByIdVv}} will also be
completed exceptionally, and that means that we cannot access to the the
mapping for table ids and tables, and actually that means, that all tables will
be unreachable.
Also, that means, that tables can't be properly stopped, which can lead to
resource leaking.
Expected behaviour is when exceptional situations for {{tablesByIdVv}} updates
are handled, tables, that weren't participated in the updated, still
accessible, and tables, that were affected, properly stopped.
> tablesByIdVv exceptional completing can lead to resource leaking
>
>
> Key: IGNITE-17515
> URL: https://issues.apache.org/jira/browse/IGNITE-17515
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Currently, {{tablesByIdVv}}, which holds the mapping for table ids and table
> implementations, is updated through the mechanism of versioned values, and
> {{tablesByIdVv}} is dependent on a list of other versioned values, like
> schema versioned value, calcite versioned value and etc. If one of this
> versioned value is completed exceptionally, {{tablesByIdVv}} will also be
> completed exceptionally, and that means that we cannot access to the the
> mapping for table ids and tables, and actually that means, that all tables
> will be unreachable.
> Also, that means, that tables can't be properly stopped, which can lead to
> resource leaking.
> Expected behaviour is when exceptional situations for {{tablesByIdVv}}
> updates are handled, tables, that weren't participated in the updated, still
> accessible, and tables, that were affected, properly stopped.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17515) tablesByIdVv exceptional completing can lead to resource leaking
[
https://issues.apache.org/jira/browse/IGNITE-17515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17515:
-
Description:
Currently, {{tablesByIdVv}}, which is holding the mapping for table ids and
table implementations, is updated through the mechanism of versioned values,
and {{tablesByIdVv}} is dependent on a list of other versioned values, like
schema versioned value, calcite versioned value and etc. If one of this
versioned value is completed exceptionally, {{tablesByIdVv}} will also be
completed exceptionally, and that means that we cannot access to the the
mapping for table ids and tables, and actually that means, that all tables will
be unreachable.
Also, that means, that tables can't be properly stopped, which can lead to
resource leaking.
Expected behaviour is when exceptional situations for {{tablesByIdVv}} updates
are handled, tables, that weren't participated in the updated, still
accessible, and tables, that were affected, properly stopped.
was:
Currently, {{tablesByIdVv}}, which is holding the mapping for table ids and
table implementations, is updated through the mechanism of versioned values,
and {{tablesByIdVv}} is dependent on a list of other versioned values, like
schema versioned value, calcite versioned value and etc. If one of this
versioned value is completed exceptionally, {{tablesByIdVv}} will also be
completed exceptionally, and that means that we cannot access to the the
mapping for table ids and tables, and actually that means, that all tables will
be unreachable.
Also, that means, that tables can't be properly stopped, which can lead to
Expected behevio
> tablesByIdVv exceptional completing can lead to resource leaking
>
>
> Key: IGNITE-17515
> URL: https://issues.apache.org/jira/browse/IGNITE-17515
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Currently, {{tablesByIdVv}}, which is holding the mapping for table ids and
> table implementations, is updated through the mechanism of versioned values,
> and {{tablesByIdVv}} is dependent on a list of other versioned values, like
> schema versioned value, calcite versioned value and etc. If one of this
> versioned value is completed exceptionally, {{tablesByIdVv}} will also be
> completed exceptionally, and that means that we cannot access to the the
> mapping for table ids and tables, and actually that means, that all tables
> will be unreachable.
> Also, that means, that tables can't be properly stopped, which can lead to
> resource leaking.
> Expected behaviour is when exceptional situations for {{tablesByIdVv}}
> updates are handled, tables, that weren't participated in the updated, still
> accessible, and tables, that were affected, properly stopped.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17515) tablesByIdVv exceptional completing can lead to resource leaking
[
https://issues.apache.org/jira/browse/IGNITE-17515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17515:
-
Description:
Currently, {{tablesByIdVv}}, which is holding the mapping for table ids and
table implementations, is updated through the mechanism of versioned values,
and {{tablesByIdVv}} is dependent on a list of other versioned values, like
schema versioned value, calcite versioned value and etc. If one of this
versioned value is completed exceptionally, {{tablesByIdVv}} will also be
completed exceptionally, and that means that we cannot access to the the
mapping for table ids and tables, and actually that means, that all tables will
be unreachable.
Also, that means, that tables can't be properly stopped, which can lead to
Expected behevio
was:TBD
> tablesByIdVv exceptional completing can lead to resource leaking
>
>
> Key: IGNITE-17515
> URL: https://issues.apache.org/jira/browse/IGNITE-17515
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Currently, {{tablesByIdVv}}, which is holding the mapping for table ids and
> table implementations, is updated through the mechanism of versioned values,
> and {{tablesByIdVv}} is dependent on a list of other versioned values, like
> schema versioned value, calcite versioned value and etc. If one of this
> versioned value is completed exceptionally, {{tablesByIdVv}} will also be
> completed exceptionally, and that means that we cannot access to the the
> mapping for table ids and tables, and actually that means, that all tables
> will be unreachable.
> Also, that means, that tables can't be properly stopped, which can lead to
> Expected behevio
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17507) Failed to wait for partition map exchange on some clients
[ https://issues.apache.org/jira/browse/IGNITE-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578503#comment-17578503 ] Vyacheslav Koptilin commented on IGNITE-17507: -- Hello [~ivandasch], Could you please take a look? > Failed to wait for partition map exchange on some clients > - > > Key: IGNITE-17507 > URL: https://issues.apache.org/jira/browse/IGNITE-17507 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > We have scenario with several client and server nodes, which can stuck on PME > after start: > * Start some server nodes > * Trigger rebalance > * Start some client and server nodes > * Some of the client nodes stuck with _Failed to wait for partition map > exchange [topVer=AffinityTopologyVersion…_ > Deep investigation of the logs showed, that the root cause of the stuck PME > on client is the race between joining new client node and receiving stale > _CacheAffinityChangeMessage_ on a client, which causes PME, but when other > old nodes receive this _CacheAffinityChangeMessage_, they skip it because of > some optimization. > Optimization can be found in the method > _CacheAffinitySharedManager#onDiscoveryEvent_, we save _lastAffVer = topVer_ > for old nodes, but because of some race _lastAffVer_ for the problem client > node is null when we reach _CacheAffinitySharedManager#onCustomEvent_ and we > schedule invalid PME in _msg.exchangeNeeded(exchangeNeeded)_, but other > nodes skip this PME > The possible fix is that we can try to make the _CacheAffinityChangeMessage_ > mutable (mutable discovery custom message). It allows to modify the message > before sending it across the ring. This approach does not require to make a > decision to apply or skip the message on client nodes, the required flag will > be transferred from a server node. In case of using Zookeeper Discovery, > there is no ability to mutate discovery messages. However is is possible to > mutate the message on the coordinator node (this requires adding > _stopProcess_ flag in _DiscoveryCustomMessage_ which was removed by > IGNITE-12400). This is quite enough for our case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17507) Failed to wait for partition map exchange on some clients
[ https://issues.apache.org/jira/browse/IGNITE-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17507: - Reviewer: Ivan Daschinsky > Failed to wait for partition map exchange on some clients > - > > Key: IGNITE-17507 > URL: https://issues.apache.org/jira/browse/IGNITE-17507 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > We have scenario with several client and server nodes, which can stuck on PME > after start: > * Start some server nodes > * Trigger rebalance > * Start some client and server nodes > * Some of the client nodes stuck with _Failed to wait for partition map > exchange [topVer=AffinityTopologyVersion…_ > Deep investigation of the logs showed, that the root cause of the stuck PME > on client is the race between joining new client node and receiving stale > _CacheAffinityChangeMessage_ on a client, which causes PME, but when other > old nodes receive this _CacheAffinityChangeMessage_, they skip it because of > some optimization. > Optimization can be found in the method > _CacheAffinitySharedManager#onDiscoveryEvent_, we save _lastAffVer = topVer_ > for old nodes, but because of some race _lastAffVer_ for the problem client > node is null when we reach _CacheAffinitySharedManager#onCustomEvent_ and we > schedule invalid PME in _msg.exchangeNeeded(exchangeNeeded)_, but other > nodes skip this PME > The possible fix is that we can try to make the _CacheAffinityChangeMessage_ > mutable (mutable discovery custom message). It allows to modify the message > before sending it across the ring. This approach does not require to make a > decision to apply or skip the message on client nodes, the required flag will > be transferred from a server node. In case of using Zookeeper Discovery, > there is no ability to mutate discovery messages. However is is possible to > mutate the message on the coordinator node (this requires adding > _stopProcess_ flag in _DiscoveryCustomMessage_ which was removed by > IGNITE-12400). This is quite enough for our case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17110) Auto-connect on the REPL start
[
https://issues.apache.org/jira/browse/IGNITE-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578499#comment-17578499
]
Kirill Gusakov commented on IGNITE-17110:
-
LGTM
> Auto-connect on the REPL start
> --
>
> Key: IGNITE-17110
> URL: https://issues.apache.org/jira/browse/IGNITE-17110
> Project: Ignite
> Issue Type: Task
> Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h2. Description
> When a user starts REPL by the {{ignite}} command they get
> {{{}[disconnected]{}}}> prompt by default. Even if the user already connected
> to the cluster node in the previous session.
> h2. To-Do
> Implement the auto-connect logic for the case described below. The URL for
> the connect command can be taken from the defaults. If the user previously
> connected to the URL that differs from the default one then suggest using the
> last URL as a default.
> {code:bash}
> $ ignite
> > connect to http://host.from.previous.session:10300 ? # this is asked only
> > if the default url is not possible to connect
> > yes
> [http://host.from.previous.session:10300]> would you like to use
> http://host.from.previous.session:10300 as the default URL?
> [http://host.from.previous.session:10300]> no
> [http://host.from.previous.session:10300]> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17507) Failed to wait for partition map exchange on some clients
[
https://issues.apache.org/jira/browse/IGNITE-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578496#comment-17578496
]
Ignite TC Bot commented on IGNITE-17507:
{panel:title=Branch: [pull/10187/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10187/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6723321]]
* {color:#013220}IgniteCacheTestSuite5:
CacheLateAffinityAssignmentTest.testDelayAssignmentAffinityChangedUnexpectedPME
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6723417buildTypeId=IgniteTests24Java8_RunAll]
> Failed to wait for partition map exchange on some clients
> -
>
> Key: IGNITE-17507
> URL: https://issues.apache.org/jira/browse/IGNITE-17507
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have scenario with several client and server nodes, which can stuck on PME
> after start:
> * Start some server nodes
> * Trigger rebalance
> * Start some client and server nodes
> * Some of the client nodes stuck with _Failed to wait for partition map
> exchange [topVer=AffinityTopologyVersion…_
> Deep investigation of the logs showed, that the root cause of the stuck PME
> on client is the race between joining new client node and receiving stale
> _CacheAffinityChangeMessage_ on a client, which causes PME, but when other
> old nodes receive this _CacheAffinityChangeMessage_, they skip it because of
> some optimization.
> Optimization can be found in the method
> _CacheAffinitySharedManager#onDiscoveryEvent_, we save _lastAffVer = topVer_
> for old nodes, but because of some race _lastAffVer_ for the problem client
> node is null when we reach _CacheAffinitySharedManager#onCustomEvent_ and we
> schedule invalid PME in _msg.exchangeNeeded(exchangeNeeded)_, but other
> nodes skip this PME
> The possible fix is that we can try to make the _CacheAffinityChangeMessage_
> mutable (mutable discovery custom message). It allows to modify the message
> before sending it across the ring. This approach does not require to make a
> decision to apply or skip the message on client nodes, the required flag will
> be transferred from a server node. In case of using Zookeeper Discovery,
> there is no ability to mutate discovery messages. However is is possible to
> mutate the message on the coordinator node (this requires adding
> _stopProcess_ flag in _DiscoveryCustomMessage_ which was removed by
> IGNITE-12400). This is quite enough for our case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17515) tablesByIdVv exceptional completing can lead to resource leaking
Mirza Aliev created IGNITE-17515: Summary: tablesByIdVv exceptional completing can lead to resource leaking Key: IGNITE-17515 URL: https://issues.apache.org/jira/browse/IGNITE-17515 Project: Ignite Issue Type: Task Reporter: Mirza Aliev TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17502) Tasks to sent the snapshot files are not ordered
[
https://issues.apache.org/jira/browse/IGNITE-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578383#comment-17578383
]
Amelchev Nikita edited comment on IGNITE-17502 at 8/11/22 2:03 PM:
---
[~xtern], Hi. Could you take a look please?
was (Author: nsamelchev):
[~mmuzaf], Hi. Could you take a look please?
> Tasks to sent the snapshot files are not ordered
>
>
> Key: IGNITE-17502
> URL: https://issues.apache.org/jira/browse/IGNITE-17502
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tasks to sent the snapshot files are not ordered. This leads to socket
> timeout in a file sender while thread is busy by sending to other node:
> {noformat}
> sender.send(part1);
> ...
> otherSender.send(part3);
> ...
> // `sender` throws socket timeout exception.
> sender.send(part2);
> {noformat}
> {noformat}
> java.io.EOFException: null
> at
> java.io.ObjectInputStream$BlockDataInputStream.readBoolean(ObjectInputStream.java:3120)
> ~[?:1.8.0_201]
> at java.io.ObjectInputStream.readBoolean(ObjectInputStream.java:966)
> ~[?:1.8.0_201]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2935)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2895)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> [classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_201]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_201]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> ...
> Caused by: org.apache.ignite.IgniteCheckedException: Requested topic is busy
> by another transmission. It's not allowed to process different sessions over
> the same topic simultaneously. Channel will be closed
> [initMsg=SessionChannelMessage
> [sesId=9c855b38281-d8dcd34f-916f-49d0-a453-cd1866acfce1],
> channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:47102
> remote=/127.0.0.1:55621], nodeId=5ace7280-b08a-4cf9-b428-7f70ef70]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2867)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> ~[classes/:?]
> ... 3 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17461) Status command incorrectly handle invalid URLs
[ https://issues.apache.org/jira/browse/IGNITE-17461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578478#comment-17578478 ] Kirill Gusakov commented on IGNITE-17461: - LGTM > Status command incorrectly handle invalid URLs > -- > > Key: IGNITE-17461 > URL: https://issues.apache.org/jira/browse/IGNITE-17461 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > Time Spent: 10m > Remaining Estimate: 0h > > node/cluster status commands print "Internal error!" instead of an error > description in case invalid URL is passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17257) Implement Replica server-side logic
[ https://issues.apache.org/jira/browse/IGNITE-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-17257: -- Assignee: Sergey Uttsel (was: Denis Chudov) > Implement Replica server-side logic > --- > > Key: IGNITE-17257 > URL: https://issues.apache.org/jira/browse/IGNITE-17257 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > For general context please check IGNITE-17252. In addition to client > [ReplicaService|https://issues.apache.org/jira/browse/IGNITE-17257] it's > required to implement server side logic that will handle actionRequests. > Generally speaking all business related logic will be specified in > ReplicaListener, Replica or replica server itself should only handle > replication-outer action requests and propagate them to ReplicaListener, so > that it might be considered as > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer / > org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor counterpart that > handles all business related replication-external requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15759) [IEP-80] Removal of LOCAL caches support
[
https://issues.apache.org/jira/browse/IGNITE-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578431#comment-17578431
]
Ignite TC Bot commented on IGNITE-15759:
{panel:title=Branch: [pull/10157/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10157/head] Base: [master] : New Tests
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6724871]]
* {color:#013220}IgniteCacheTestSuite2:
GridCacheFastNodeLeftForTransactionTest.testRollbackTransactions - PASSED{color}
* {color:#013220}IgniteCacheTestSuite2:
GridCacheFastNodeLeftForTransactionTest.testRollbackTransactionsWithKeyOperationOutsideThem
- PASSED{color}
{color:#8b}Cache 8{color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6724503]]
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsFifo - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsSorted - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionsSelfTest.testConcurrentPutsLru - PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyLruFewKeys
- PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencySorted -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyLruTwoKeys
- PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyFifoTwoKeys
- PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyFifoFewKeys
- PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyLru -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyFifo -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencySortedTwoKeys
- PASSED{color}
... and 1 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6724596buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-80] Removal of LOCAL caches support
>
>
> Key: IGNITE-15759
> URL: https://issues.apache.org/jira/browse/IGNITE-15759
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: IEP-80
> Fix For: 2.14
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> LOCAL cachens has huge amount of known limitation and not intended to be used
> in production environment.
> Should be removed in 2.13
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17339) Implement B+Tree based hash index storage
[ https://issues.apache.org/jira/browse/IGNITE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17339: - Labels: ignite-3 (was: ) > Implement B+Tree based hash index storage > - > > Key: IGNITE-17339 > URL: https://issues.apache.org/jira/browse/IGNITE-17339 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Please refer to IGNITE-17320 and issues from the epic for the gist. It's > basically the same thing, but with hash slapped inside of the tree pages and > a simplified comparison algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17339) Implement B+Tree based hash index storage
[ https://issues.apache.org/jira/browse/IGNITE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-17339: Assignee: Kirill Tkalenko > Implement B+Tree based hash index storage > - > > Key: IGNITE-17339 > URL: https://issues.apache.org/jira/browse/IGNITE-17339 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > > Please refer to IGNITE-17320 and issues from the epic for the gist. It's > basically the same thing, but with hash slapped inside of the tree pages and > a simplified comparison algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17339) Implement B+Tree based hash index storage
[ https://issues.apache.org/jira/browse/IGNITE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17339: - Fix Version/s: 3.0.0-alpha6 > Implement B+Tree based hash index storage > - > > Key: IGNITE-17339 > URL: https://issues.apache.org/jira/browse/IGNITE-17339 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 3.0.0-alpha6 > > > Please refer to IGNITE-17320 and issues from the epic for the gist. It's > basically the same thing, but with hash slapped inside of the tree pages and > a simplified comparison algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17339) Implement B+Tree based hash index storage
[ https://issues.apache.org/jira/browse/IGNITE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17339: - Ignite Flags: (was: Docs Required,Release Notes Required) > Implement B+Tree based hash index storage > - > > Key: IGNITE-17339 > URL: https://issues.apache.org/jira/browse/IGNITE-17339 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > > Please refer to IGNITE-17320 and issues from the epic for the gist. It's > basically the same thing, but with hash slapped inside of the tree pages and > a simplified comparison algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17354) Metrics framework
[ https://issues.apache.org/jira/browse/IGNITE-17354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578389#comment-17578389 ] Andrey N. Gura commented on IGNITE-17354: - [~Denis Chudov] I left additional set of comments. Could you please fix them and request a review again? Thanks. > Metrics framework > -- > > Key: IGNITE-17354 > URL: https://issues.apache.org/jira/browse/IGNITE-17354 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Metrics types* > Metrics framework should provide the following metrics types: > - Gauge - is an instantaneous measurement of a value provided by some > existing component. Gauge should support primitive types: int, long, double > - Metric - is just a wrapper on a numeric value which could be increased or > decreased to some value. Metric should support primitive types: int, long, > double. > - Hit Rate - accumulates approximate hit rate statistics based on hits in the > last time interval. > - Distribution - distributes values by buckets where each bucket represent > some numeric interval (Histogram in AI 2). Internal type - primitive long > (should be enough). > *Concurrency characteristics* > For scalar numeric metrics it is enough to have atomic number (e.g. > AtomicInteger) and striped number (e.g. LongAdder). Such approaches affects > memory footprint and performance differently. > *Design* > Metrics should have the same life cycle as well as component that produces > these metrics. So metrics related to some particular component should be tied > together in MetricsSet. the only purpose of metrics set is provide access to > metrics values from exporters. Metrics instances itself placed in > MetricsSource - an entity which keeps instances of metrics and provides > access to the metrics through an interface that is specific for each metrics > source. A component that produces metrics must control metrics source life > cycle (create it and register in metrics registry, see below). > All metrics sources (it is not important, enabled or disabled metrics for > particular metrics source) must be registered in metrics registry on > component start and removed on component stop. > MetricsSource itself produces an instance of MetricsSet which should be > registered in metrics registry on event "metrics enabled" and unregistered on > event "metrics disabled". > Metrics registry provide an access to all metrics sets from exporters side. > It is possible that metrics registry is overloaded by functionality (manage > by metrics sources and metrics sets), so, probably, special component is need > for these purposes (e.g. metrics manager). > Each instance of metric has a name (local in some metric set) and > description. So the full metric name it is a concatenation of metrics source > name and metric name separated by dot. > For composite metrics like distribution we should treat each metrics inside > (e.g. each range) as separate metric. So the full name for each internal > metric will be metrics source + dot + metric instance name + dot + range as > string (e.g. 0_100). > Metrics set must be immutable in order to meet the requirements described in > the epic. > Data structure (likely map) that is responsible for keeping enabled metrics > set should be modified using copy-on-write semantics in order to avoid data > races between main functionality (metrics enabling\disabling) and exporters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17502) Tasks to sent the snapshot files are not ordered
[
https://issues.apache.org/jira/browse/IGNITE-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578383#comment-17578383
]
Amelchev Nikita commented on IGNITE-17502:
--
[~mmuzaf], Hi. Could you take a look please?
> Tasks to sent the snapshot files are not ordered
>
>
> Key: IGNITE-17502
> URL: https://issues.apache.org/jira/browse/IGNITE-17502
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tasks to sent the snapshot files are not ordered. This leads to socket
> timeout in a file sender while thread is busy by sending to other node:
> {noformat}
> sender.send(part1);
> ...
> otherSender.send(part3);
> ...
> // `sender` throws socket timeout exception.
> sender.send(part2);
> {noformat}
> {noformat}
> java.io.EOFException: null
> at
> java.io.ObjectInputStream$BlockDataInputStream.readBoolean(ObjectInputStream.java:3120)
> ~[?:1.8.0_201]
> at java.io.ObjectInputStream.readBoolean(ObjectInputStream.java:966)
> ~[?:1.8.0_201]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2935)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2895)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> [classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_201]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_201]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> ...
> Caused by: org.apache.ignite.IgniteCheckedException: Requested topic is busy
> by another transmission. It's not allowed to process different sessions over
> the same topic simultaneously. Channel will be closed
> [initMsg=SessionChannelMessage
> [sesId=9c855b38281-d8dcd34f-916f-49d0-a453-cd1866acfce1],
> channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:47102
> remote=/127.0.0.1:55621], nodeId=5ace7280-b08a-4cf9-b428-7f70ef70]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2867)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> ~[classes/:?]
> ... 3 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17502) Tasks to sent the snapshot files are not ordered
[
https://issues.apache.org/jira/browse/IGNITE-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578382#comment-17578382
]
Ignite TC Bot commented on IGNITE-17502:
{panel:title=Branch: [pull/10189/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10189/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=6554451]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteSnapshotRemoteRequestTest.testSendPartitonsSequentially[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteSnapshotRemoteRequestTest.testSendPartitonsSequentially[Encryption=false]
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6554469buildTypeId=IgniteTests24Java8_RunAll]
> Tasks to sent the snapshot files are not ordered
>
>
> Key: IGNITE-17502
> URL: https://issues.apache.org/jira/browse/IGNITE-17502
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tasks to sent the snapshot files are not ordered. This leads to socket
> timeout in a file sender while thread is busy by sending to other node:
> {noformat}
> sender.send(part1);
> ...
> otherSender.send(part3);
> ...
> // `sender` throws socket timeout exception.
> sender.send(part2);
> {noformat}
> {noformat}
> java.io.EOFException: null
> at
> java.io.ObjectInputStream$BlockDataInputStream.readBoolean(ObjectInputStream.java:3120)
> ~[?:1.8.0_201]
> at java.io.ObjectInputStream.readBoolean(ObjectInputStream.java:966)
> ~[?:1.8.0_201]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2935)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2895)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> [classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_201]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_201]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> ...
> Caused by: org.apache.ignite.IgniteCheckedException: Requested topic is busy
> by another transmission. It's not allowed to process different sessions over
> the same topic simultaneously. Channel will be closed
> [initMsg=SessionChannelMessage
> [sesId=9c855b38281-d8dcd34f-916f-49d0-a453-cd1866acfce1],
> channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:47102
> remote=/127.0.0.1:55621], nodeId=5ace7280-b08a-4cf9-b428-7f70ef70]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2867)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> ~[classes/:?]
> ... 3 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17514) Exception handling in InternalTableImpl
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-17514: -- Assignee: Sergey Uttsel > Exception handling in InternalTableImpl > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. > Need to throw ReplicaUnavailableException in case when Replica is not ready. > See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17514) Exception handling in InternalTableImpl
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17514: --- Summary: Exception handling in InternalTableImpl (was: Exception handling in ReplicaService and ReplicaManager) > Exception handling in InternalTableImpl > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. > Need to throw ReplicaUnavailableException in case when Replica is not ready. > See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17514) Exception handling in ReplicaService and ReplicaManager
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17514: --- Description: Need to handle exceptions from ReplicaService and ReplicaManager in InternalTableImpl and wrap it to TransactionException. Need to throw ReplicaUnavailableException in case when Replica is not ready. See TODO in the code. was: Provide an exceptional response to the client side when the replica is absent in ReplicaService and ReplicaManager. Need to handle exceptions from ReplicaService and ReplicaManager in InternalTableImpl and wrap it to TransactionException. See TODO in the code. > Exception handling in ReplicaService and ReplicaManager > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. > Need to throw ReplicaUnavailableException in case when Replica is not ready. > See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17514) Exception handling in ReplicaService and ReplicaManager
[ https://issues.apache.org/jira/browse/IGNITE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17514: --- Description: Provide an exceptional response to the client side when the replica is absent in ReplicaService and ReplicaManager. Need to handle exceptions from ReplicaService and ReplicaManager in InternalTableImpl and wrap it to TransactionException. See TODO in the code. was:Provide an exceptional response to the client side when the replica is absent in ReplicaService and ReplicaManager. See TODO in the code. > Exception handling in ReplicaService and ReplicaManager > --- > > Key: IGNITE-17514 > URL: https://issues.apache.org/jira/browse/IGNITE-17514 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Provide an exceptional response to the client side when the replica is absent > in ReplicaService and ReplicaManager. > > Need to handle exceptions from ReplicaService and ReplicaManager in > InternalTableImpl and wrap it to TransactionException. See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17470) Add initial support of Spark 3.2
[ https://issues.apache.org/jira/browse/IGNITE-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578352#comment-17578352 ] Ivan Gagarkin commented on IGNITE-17470: [~NIzhikov] Could you take a look at the PR, please? > Add initial support of Spark 3.2 > > > Key: IGNITE-17470 > URL: https://issues.apache.org/jira/browse/IGNITE-17470 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.14 >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update ignite-spark module to spark-3.2 and scala 12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17513) [ducktests] Support non-ascii symbols in SSH command lines in docker
[ https://issues.apache.org/jira/browse/IGNITE-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-17513: - Ignite Flags: (was: Docs Required,Release Notes Required) > [ducktests] Support non-ascii symbols in SSH command lines in docker > > > Key: IGNITE-17513 > URL: https://issues.apache.org/jira/browse/IGNITE-17513 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 20m > Remaining Estimate: 0h > > Currently (at least in docker environment) it's not possible to pass the > non-ascii symbols via the command line to programs started via SSH in > ducktape. > In particular it's not possible to pass the password with non-ascii symbols > to control.sh > Reason is that the POSIX locale is assigned for such programs by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17513) [ducktests] Support non-ascii symbols in SSH command lines in docker
[ https://issues.apache.org/jira/browse/IGNITE-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578326#comment-17578326 ] Sergey Korotkov commented on IGNITE-17513: -- [~ivandasch] would you please review? > [ducktests] Support non-ascii symbols in SSH command lines in docker > > > Key: IGNITE-17513 > URL: https://issues.apache.org/jira/browse/IGNITE-17513 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > > Currently (at least in docker environment) it's not possible to pass the > non-ascii symbols via the command line to programs started via SSH in > ducktape. > In particular it's not possible to pass the password with non-ascii symbols > to control.sh > Reason is that the POSIX locale is assigned for such programs by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17511) Support IndexQuery for Java ThinClient
[
https://issues.apache.org/jira/browse/IGNITE-17511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578310#comment-17578310
]
Ignite TC Bot commented on IGNITE-17511:
{panel:title=Branch: [pull/10188/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10188/head] Base: [master] : New Tests
(12)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Index Query API{color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6724646]]
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testRanges[keepBinary=true] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testPageSize[keepBinary=true] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testLocal[keepBinary=true] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testRanges[keepBinary=false] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testFilter[keepBinary=true] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testIndexName[keepBinary=true] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testIndexName[keepBinary=false] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testLocal[keepBinary=false] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testPageSize[keepBinary=false] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testFilter[keepBinary=false] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
ThinClientIndexQueryTest.testPartition[keepBinary=true] - PASSED{color}
... and 1 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6724708buildTypeId=IgniteTests24Java8_RunAll]
> Support IndexQuery for Java ThinClient
> --
>
> Key: IGNITE-17511
> URL: https://issues.apache.org/jira/browse/IGNITE-17511
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ThinClient doesn't support IndexQuery. Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17514) Exception handling in ReplicaService and ReplicaManager
Sergey Uttsel created IGNITE-17514: -- Summary: Exception handling in ReplicaService and ReplicaManager Key: IGNITE-17514 URL: https://issues.apache.org/jira/browse/IGNITE-17514 Project: Ignite Issue Type: Improvement Reporter: Sergey Uttsel Provide an exceptional response to the client side when the replica is absent in ReplicaService and ReplicaManager. See TODO in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
