[jira] [Created] (IGNITE-20817) Make HybridTimestamp#toString readable by human
Ivan Bessonov created IGNITE-20817:
--
Summary: Make HybridTimestamp#toString readable by human
Key: IGNITE-20817
URL: https://issues.apache.org/jira/browse/IGNITE-20817
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Bessonov
I propose using date formatter from JavaLoggerFormatter.
Example:
{code:java}
HybridTimestamp [time=2023-11-09 10:49:30:840 +0300 [006],
value=111379491772170246]{code}
Brackets after datetime hold logical counter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20817) Make HybridTimestamp#toString readable by human
[
https://issues.apache.org/jira/browse/IGNITE-20817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-20817:
---
Labels: ignite-3 (was: )
> Make HybridTimestamp#toString readable by human
> ---
>
> Key: IGNITE-20817
> URL: https://issues.apache.org/jira/browse/IGNITE-20817
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> I propose using date formatter from JavaLoggerFormatter.
> Example:
> {code:java}
> HybridTimestamp [time=2023-11-09 10:49:30:840 +0300 [006],
> value=111379491772170246]{code}
> Brackets after datetime hold logical counter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20817) Make HybridTimestamp#toString readable by human
[
https://issues.apache.org/jira/browse/IGNITE-20817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-20817:
--
Assignee: Ivan Bessonov
> Make HybridTimestamp#toString readable by human
> ---
>
> Key: IGNITE-20817
> URL: https://issues.apache.org/jira/browse/IGNITE-20817
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> I propose using date formatter from JavaLoggerFormatter.
> Example:
> {code:java}
> HybridTimestamp [time=2023-11-09 10:49:30:840 +0300 [006],
> value=111379491772170246]{code}
> Brackets after datetime hold logical counter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20817) Make HybridTimestamp#toString readable by human
[
https://issues.apache.org/jira/browse/IGNITE-20817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-20817:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Make HybridTimestamp#toString readable by human
> ---
>
> Key: IGNITE-20817
> URL: https://issues.apache.org/jira/browse/IGNITE-20817
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> I propose using date formatter from JavaLoggerFormatter.
> Example:
> {code:java}
> HybridTimestamp [time=2023-11-09 10:49:30:840 +0300 [006],
> value=111379491772170246]{code}
> Brackets after datetime hold logical counter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20816) in-memory server node is crashed by TcpIgniteClient.putAllConflict() if cache objects transformation applied
Sergey Korotkov created IGNITE-20816:
Summary: in-memory server node is crashed by
TcpIgniteClient.putAllConflict() if cache objects transformation applied
Key: IGNITE-20816
URL: https://issues.apache.org/jira/browse/IGNITE-20816
Project: Ignite
Issue Type: Task
Reporter: Sergey Korotkov
The in-memory server node crashes with the below exception if
TcpIgniteClient.putAllConflict() if cache objects transformation is applied.
{noformat}
[2023-11-09T09:34:30,401][ERROR][client-connector-#68%target%][] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [groupId=-1407396309, pageIds=[844420635164695], msg=Runtime failure
on search row: SearchRow [key=KeyCacheObjectImpl [part=10, val=52234,
hasValBytes=true], hash=52234, cacheId=0
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
B+Tree is corrupted [groupId=-1407396309, pageIds=[844420635164695],
msg=Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=10,
val=52234, hasValBytes=true], hash=52234, cacheId=0]]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6534)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:2215)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1692)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1675)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:424)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1903)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2536)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1996)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1688)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:791)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:645)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1080)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1078)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:752)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1078)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflictAsync(GridDhtAtomicCache.java:679)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflict(GridDhtAtomicCache.java:670)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAllConflict(GridCacheProxyImpl.java:536)
[classes/:?]
at
org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutAllConflictRequest.process(ClientCachePutAllConflictRequest.java:81)
[classes/:?]
at
org.apache.ignite.in
[jira] [Assigned] (IGNITE-20737) Idle Verify fails with "Cluster not idle" error when log level is set to DEBUG
[
https://issues.apache.org/jira/browse/IGNITE-20737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Egor Fomin reassigned IGNITE-20737:
---
Assignee: Egor Fomin
> Idle Verify fails with "Cluster not idle" error when log level is set to DEBUG
> --
>
> Key: IGNITE-20737
> URL: https://issues.apache.org/jira/browse/IGNITE-20737
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Valery Shorin
>Assignee: Egor Fomin
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
>
> In case if idle verify executed with DEBUG log level it fails with error:
>
> {code:java}
> Exception: org.apache.ignite.IgniteException Cluster not idle. Modifications
> found in caches or groups: [grpName=default, grpId=1544803905, partId=30]
> changed during size calculation [updCntrBefore=Counter [init=0, val=1],
> updCntrAfter=Counter [init=0, val=1]]
> {code}
>
> This issue can be reproduced by the following test (shoud be added to
> \{{GridCommandHandlerTest}}:
>
> {code:java}
> @Test
> public void testCacheIdleVerifyLogLevelDebug() throws Exception {
> IgniteEx ignite = startGrids(3);
> ignite.cluster().state(ACTIVE);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setAffinity(new RendezvousAffinityFunction(false, 32))
> .setBackups(1));
> cache.put("key", "value");
> injectTestSystemOut();
> setLoggerDebugLevel();
> assertEquals(EXIT_CODE_OK, execute("--cache", "idle_verify"));
> assertContains(log, testOut.toString(), "no conflicts have been found");
> } {code}
>
>
> The reason of this failure - {{equals(}} method is not defined for
> {{PartitionUpdateCounterDebugWrapper}} class
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20753) Add additional information on the recoverable exception
[
https://issues.apache.org/jira/browse/IGNITE-20753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-20753:
--
Assignee: Kirill Sizov
> Add additional information on the recoverable exception
> ---
>
> Key: IGNITE-20753
> URL: https://issues.apache.org/jira/browse/IGNITE-20753
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> This warning has happened due to the recoverable exception (timeout, for
> example), but this log message has too little useful information. Replication
> group ID and details about the RAFT command are also wanted.
> {noformat}
> [2023-10-06T13:08:46,787][WARN
> ][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable error
> during the request type=ActionRequestImpl occurred (will be retried on the
> randomly selected node):
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> [?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> [?:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more{noformat}
> *Definition of done*
> Log contains request itself and replication group id. Also the message should
> comply the code style requirements, meaning that the parameters (request and
> group id) should be contain in brackets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784283#comment-17784283 ] Pavel Tupitsyn commented on IGNITE-20524: - Merged to main: b54f5bbc0c5867e72c51ad24985cdc9b3897dfb0 > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > *KeyValueView.put* behavior with null value is inconsistent: > * Interface method does not have *@Nullable* annotation on *val* > * *KeyValueBinaryViewImpl* throws an exception when *val* is null > * *KeyValueViewImpl* does not throw exception right away; null is allowed for > simple mapping (e.g. **), but not allowed with POJOs > () > This affects embedded and thin APIs equally. > It is understood that single-column mapping allows nulls to set nullable > column values; however, overall situation is confusing. We can improve it in > 3 ways: > # Keep existing behavior, improve javadoc > # Always disallow null value (NOTE: makes it impossible to work with nulls in > 2-column simple type mapping scenario) > # Always allow null value (set all mapped columns to null for POJO use case) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19855) ODBC 3.0: Implement multiple queries execution
[ https://issues.apache.org/jira/browse/IGNITE-19855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19855: - Epic Link: IGNITE-20815 (was: IGNITE-19251) > ODBC 3.0: Implement multiple queries execution > -- > > Key: IGNITE-19855 > URL: https://issues.apache.org/jira/browse/IGNITE-19855 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > Currently, we do not support execution of multiple queries and fetching of > multiple result sets. Let's implement it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19968) ODBC 3.0 Performance: Avoid storing row values in primitive, read them directly from binary tuple
[ https://issues.apache.org/jira/browse/IGNITE-19968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19968: - Epic Link: IGNITE-20815 (was: IGNITE-19251) > ODBC 3.0 Performance: Avoid storing row values in primitive, read them > directly from binary tuple > - > > Key: IGNITE-19968 > URL: https://issues.apache.org/jira/browse/IGNITE-19968 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3, perfomance > > Currently, on fetch ODBC driver first reads row from result set into a vector > of primitives (including columns that are not bound to any buffers) and then > put them into buffers. Avoid this, read only needed columns when required and > store them directly in buffer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19943) ODBC 3.0: Implement wstring support
[ https://issues.apache.org/jira/browse/IGNITE-19943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19943: - Epic Link: IGNITE-20815 (was: IGNITE-19251) > ODBC 3.0: Implement wstring support > --- > > Key: IGNITE-19943 > URL: https://issues.apache.org/jira/browse/IGNITE-19943 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > Currently, ODBC our driver only support SQLCHAR type for strings with UTF-8 > encoding. We may want to add SQLWCHAR support with UTF-16 encoding. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19210) ODBC 3.0: Make sure DSN-managing UI works properly in Windows
[ https://issues.apache.org/jira/browse/IGNITE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19210: - Epic Link: IGNITE-20815 (was: IGNITE-19251) > ODBC 3.0: Make sure DSN-managing UI works properly in Windows > - > > Key: IGNITE-19210 > URL: https://issues.apache.org/jira/browse/IGNITE-19210 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Scope: > - Properly port content of ignite/odbc/system; > - Probably, come up with some kind of automatic tests for this functionality, > as it's always hard to make sure that UI is not broken. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20815) ODBC 3.0 Extra
Igor Sapego created IGNITE-20815: Summary: ODBC 3.0 Extra Key: IGNITE-20815 URL: https://issues.apache.org/jira/browse/IGNITE-20815 Project: Ignite Issue Type: Epic Components: odbc Reporter: Igor Sapego Assignee: Igor Sapego Tickets that may improve ODBC driver user experience. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19208) ODBC 3.0: Port msi builder scripts properly
[ https://issues.apache.org/jira/browse/IGNITE-19208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19208: - Epic Link: IGNITE-20815 (was: IGNITE-19251) > ODBC 3.0: Port msi builder scripts properly > --- > > Key: IGNITE-19208 > URL: https://issues.apache.org/jira/browse/IGNITE-19208 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > To do: > Make sure CMake flag ENABLE_ODBC_MSI works properly; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20814) Replace AuthorizationHeaderFilter with own implementation of SecurityFilter
[
https://issues.apache.org/jira/browse/IGNITE-20814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20814:
--
Assignee: Ivan Gagarkin
> Replace AuthorizationHeaderFilter with own implementation of SecurityFilter
> ---
>
> Key: IGNITE-20814
> URL: https://issues.apache.org/jira/browse/IGNITE-20814
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Current Behavior:* We're currently injecting an empty Authorization header
> in requests lacking one, as Micronaut filters out requests without
> authentication headers. This is handled by the AuthorizationHeaderFilter.
> *Problem:* This workaround is not ideal and could lead to maintainability
> issues.
> *Proposed Solution:* Develop a custom SecurityFilter that:
> * Checks whether authentication is enabled.
> * Forwards requests to {{io.micronaut.security.filters.SecurityFilter}} if
> authentication is required.
> * Allows requests to proceed without authentication if it's not required.
> *Objective:* To replace the AuthorizationHeaderFilter with a more robust and
> maintainable custom SecurityFilter implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20814) Replace AuthorizationHeaderFilter with own implementation of SecurityFilter
Ivan Gagarkin created IGNITE-20814:
--
Summary: Replace AuthorizationHeaderFilter with own implementation
of SecurityFilter
Key: IGNITE-20814
URL: https://issues.apache.org/jira/browse/IGNITE-20814
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Ivan Gagarkin
*Current Behavior:* We're currently injecting an empty Authorization header in
requests lacking one, as Micronaut filters out requests without authentication
headers. This is handled by the AuthorizationHeaderFilter.
*Problem:* This workaround is not ideal and could lead to maintainability
issues.
*Proposed Solution:* Develop a custom SecurityFilter that:
* Checks whether authentication is enabled.
* Forwards requests to {{io.micronaut.security.filters.SecurityFilter}} if
authentication is required.
* Allows requests to proceed without authentication if it's not required.
*Objective:* To replace the AuthorizationHeaderFilter with a more robust and
maintainable custom SecurityFilter implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) hibernate-ext: "default-query-results-region" and "default-update-timestamps-region" should not be atomic
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2], but problem can be deeper, because these regions are used under the hood
by the Hibernate itself *_for query and entity caching_*.
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
was:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2], but problem can be deeper, because these regions are used under the hood
by the Hibernate itself *_for query caching_*.
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
> hibernate-ext: "default-query-results-region" and
> "default-update-timestamps-region" should not be atomic
> -
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2], but problem can be deeper, because these regions are used under the hood
> by the Hibernate itself *_for query and entity caching_*.
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20013) Update documentation for DZ
[ https://issues.apache.org/jira/browse/IGNITE-20013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20013: - Fix Version/s: 3.0.0-beta2 > Update documentation for DZ > --- > > Key: IGNITE-20013 > URL: https://issues.apache.org/jira/browse/IGNITE-20013 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > We now support DATA_NODES_AUTO_ADJUST_SCALE_UP, > DATA_NODES_AUTO_ADJUST_SCALE_DOWN and DATA_NODES_FILTER properties of data > nodes. Also, ALTER ZONE now works and needs to be documented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20772) ItTableRaftSnapshotsTest#txSemanticsIsMaintained is flaky in different branches
[
https://issues.apache.org/jira/browse/IGNITE-20772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-20772:
--
Assignee: Roman Puchkovskiy
> ItTableRaftSnapshotsTest#txSemanticsIsMaintained is flaky in different
> branches
> ---
>
> Key: IGNITE-20772
> URL: https://issues.apache.org/jira/browse/IGNITE-20772
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_18692.log.zip
>
>
> Test fails from time to time in different branches, success rate is 98%.
> Latest failure in main branch was caused by timeout in test logic:
> {code:java}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
> at org.apache.ignite.internal.Cluster.startNode(Cluster.java:336)
> at org.apache.ignite.internal.Cluster.startNode(Cluster.java:315)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.reanimateNode(ItTableRaftSnapshotsTest.java:453)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.reanimateNodeAndWaitForSnapshotInstalled(ItTableRaftSnapshotsTest.java:435)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.reanimateNode2AndWaitForSnapshotInstalled(ItTableRaftSnapshotsTest.java:425)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.txSemanticsIsMaintainedAfterInstallingSnapshot(ItTableRaftSnapshotsTest.java:494)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.txSemanticsIsMaintained(ItTableRaftSnapshotsTest.java:466)
> ...
> Caused by: java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at org.apache.ignite.internal.Cluster.startNode(Cluster.java:330)
> ... 93 more {code}
> Test involves node restart so multiple errors in logs about connection issues
> are expected:
> {code:java}
> [2023-10-27T08:24:44,662][WARN
> ][%itrst_tsim_2%Raft-Group-Client-4][RaftGroupServiceImpl] Recoverable error
> during the request type=GetLeaderRequestImpl occurred (will be retried on the
> randomly selected node):
> java.util.concurrent.CompletionException: java.net.ConnectException: Peer
> itrst_tsim_0 is unavailable
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:523)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleThrowable$40(RaftGroupServiceImpl.java:564)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.net.ConnectException: Peer itrst_tsim_0 is unavailable
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.resolvePeer(RaftGroupServiceImpl.java:761)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:522)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> ... 7 more {code}
> At the same time it is not clear from logs what prevented node from starting.
> Suite run with failed test is available
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=7590927&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner&tab=buildLog],
> logs are attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) hibernate-ext: "default-query-results-region" and "default-update-timestamps-region" should not be atomic
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2], but problem can be deeper, because these regions are used under the hood
by the Hibernate itself *_for query caching_*.
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
was:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2], but problem can be deeper, because these regions are used under the hood
by the Hibernate itself.
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
> hibernate-ext: "default-query-results-region" and
> "default-update-timestamps-region" should not be atomic
> -
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2], but problem can be deeper, because these regions are used under the hood
> by the Hibernate itself *_for query caching_*.
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) hibernate-ext: "default-query-results-region" and "default-update-timestamps-region" should not be atomic
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2], but problem can be deeper, because these regions are used under the hood
by the Hibernate itself.
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
was:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2].
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
> hibernate-ext: "default-query-results-region" and
> "default-update-timestamps-region" should not be atomic
> -
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2], but problem can be deeper, because these regions are used under the hood
> by the Hibernate itself.
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) hibernate-ext: "default-query-results-region" and "default-update-timestamps-region" should not be atomic
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Summary: hibernate-ext: "default-query-results-region" and
"default-update-timestamps-region" should not be atomic (was: hibernate-ext:
add ability to work with )
> hibernate-ext: "default-query-results-region" and
> "default-update-timestamps-region" should not be atomic
> -
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2].
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) hibernate-ext: add ability to work with
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Summary: hibernate-ext: add ability to work with (was: Fix Hibernate
tests)
> hibernate-ext: add ability to work with
>
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2].
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20799) Fix Hibernate tests
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov reassigned IGNITE-20799:
--
Assignee: Ilya Shishkov
> Fix Hibernate tests
> ---
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2].
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) Fix Hibernate tests
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region"
[2].
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
was:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region".
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
> Fix Hibernate tests
> ---
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2].
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) Fix Hibernate tests
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region".
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
was:
Currently, Hibernate test job fails because of execution timeout [1]. It should
be fixed.
*Failures:*
After IGNITE-20579 {{HibernateL2CacheSelfTest}} fails and hangs with an error:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
HibernateL2CacheTransactionalSelfTest tests fails with a following error:
{code}
[error] SubCoordinator.addResource: bad status=
STATUS_COMMITTED[2023-11-07T18:50:26,244][ERROR][main][] Test failed
[test=HibernateL2CacheTransactionalSelfTest#testQueryCache, duration=1327]
org.hibernate.TransactionException: JTA TransactionManager#commit failed
at
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionAdapterTransactionManagerImpl.commit(JtaTransactionAdapterTransactionManagerImpl.java:65)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
at
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JtaTransactionCoordinatorImpl.java:437)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
at
org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
at
org.apache.ignite.cache.hibernate.HibernateL2CacheSelfTest.testQueryCache(HibernateL2CacheSelfTest.java:1459)
~[test-classes/:?]
at
org.apache.ignite.cache.hibernate.HibernateL2CacheSelfTest.testQueryCache(HibernateL2CacheSelfTest.java:1440)
~[test-classes/:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:?]
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:?]
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
~[junit-4.12.jar:4.12]
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
~[junit-4.12.jar:4.12]
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2499)
~[test-classes/:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
Caused by: java.lang.IllegalStateException: enlistResource: could not
addResource CacheJtaResource [cacheTx=GridNearTxLocal ...]
at
org.objectweb.jotm.TransactionImpl.enlistResource(TransactionImpl.java:483)
~[jotm-core-2.3.1-M1.jar:?]
at
org.apache.ignite.internal.processors.cache.jta.CacheJtaManager.checkJta(CacheJtaManager.java:180)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.checkJta(GridCacheAdapter.java:3579)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4167)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2456)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2434)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2413)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.put(GridCacheProxyImpl.java:524)
~[classes/:?]
at
org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:198)
~[classes/:?]
at
org.apache.ignite.cache.hibernate.IgniteGeneralDa
[jira] [Updated] (IGNITE-20799) Fix Hibernate tests
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region".
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
was:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region".
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
> Fix Hibernate tests
> ---
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region".
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) Fix Hibernate tests
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region".
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
#
was:
Currently, Hibernate test job fails because of execution timeout [1]. After
IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
As we can see, these problem occur because of ATOMIC caches for Hibernate
regions "default-query-results-region" and "default-update-timestamps-region".
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> Fix Hibernate tests
> ---
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region".
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20811) Refactoring DataInput hierarchy
[ https://issues.apache.org/jira/browse/IGNITE-20811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-20811: Ignite Flags: Docs Required (was: Docs Required,Release Notes Required) > Refactoring DataInput hierarchy > --- > > Key: IGNITE-20811 > URL: https://issues.apache.org/jira/browse/IGNITE-20811 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Current hierarchy should be redesigned, as such methods like "position", > "size" and Crc32CheckingDataInput should be part of ByteBufferedDataInput. > Now they are implemented only for FileInput. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20811) Refactoring DataInput hierarchy
[ https://issues.apache.org/jira/browse/IGNITE-20811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-20811: Ignite Flags: (was: Docs Required) > Refactoring DataInput hierarchy > --- > > Key: IGNITE-20811 > URL: https://issues.apache.org/jira/browse/IGNITE-20811 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Current hierarchy should be redesigned, as such methods like "position", > "size" and Crc32CheckingDataInput should be part of ByteBufferedDataInput. > Now they are implemented only for FileInput. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16431) Entry expiration requires twice the entry size of heap
[
https://issues.apache.org/jira/browse/IGNITE-16431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel reassigned IGNITE-16431:
--
Assignee: Sergey Uttsel
> Entry expiration requires twice the entry size of heap
> --
>
> Key: IGNITE-16431
> URL: https://issues.apache.org/jira/browse/IGNITE-16431
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.12
>Reporter: Alexey Kukushkin
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: cggg
> Attachments: 500MB-put-expiry-master.png
>
> Original Estimate: 64h
> Remaining Estimate: 64h
>
> Ignite takes twice the entry size off the heap to expire the entry when
> {{{}eagerTtl=true{}}}. See the attached heap memory usage diagram of putting
> and then expiring a 500MB entry in Ignite.
> This makes Ignite inefficient with handling large objects causing
> {{OutOfMemory}} errors.
> Do we really need loading entry's value on heap at all to expiry the entry?
> Please enhance Ignite cache entry expiration not to load the entry's value on
> heap even once or explain why it is not possible.
> !500MB-put-expiry-master.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20813) Sql. Introduce InternalSqlRow as resulting row of QueryProcessor
Konstantin Orlov created IGNITE-20813:
-
Summary: Sql. Introduce InternalSqlRow as resulting row of
QueryProcessor
Key: IGNITE-20813
URL: https://issues.apache.org/jira/browse/IGNITE-20813
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
As for now, the method signature of
{{QueryProcessor#querySingleAsync}} looks like this:
{code:java}
CompletableFuture>> querySingleAsync(
SqlProperties properties,
IgniteTransactions transactions,
@Nullable InternalTransaction transaction,
String qry,
Object... params
);
{code}
The problem is that client code may not need de-serialised row right here right
now (for instance, thin client handler will send those rows down the channel
anyway), yet current signature force us to do deserialisation from a storage
format.
Let's change the signature to return something that extends InternalTuple, but
also provides a way to get column value by having only index of column of
interest (e.g. {{@Nullable Object get(int idx)}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20013) Update documentation for DZ
[ https://issues.apache.org/jira/browse/IGNITE-20013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784023#comment-17784023 ] Igor Gusev commented on IGNITE-20013: - [~sk0x50] can you review and merge? > Update documentation for DZ > --- > > Key: IGNITE-20013 > URL: https://issues.apache.org/jira/browse/IGNITE-20013 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > We now support DATA_NODES_AUTO_ADJUST_SCALE_UP, > DATA_NODES_AUTO_ADJUST_SCALE_DOWN and DATA_NODES_FILTER properties of data > nodes. Also, ALTER ZONE now works and needs to be documented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20013) Update documentation for DZ
[ https://issues.apache.org/jira/browse/IGNITE-20013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-20013: --- Assignee: Igor Gusev > Update documentation for DZ > --- > > Key: IGNITE-20013 > URL: https://issues.apache.org/jira/browse/IGNITE-20013 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > We now support DATA_NODES_AUTO_ADJUST_SCALE_UP, > DATA_NODES_AUTO_ADJUST_SCALE_DOWN and DATA_NODES_FILTER properties of data > nodes. Also, ALTER ZONE now works and needs to be documented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20744) StandaloneContext should not load plugins from classpath
[ https://issues.apache.org/jira/browse/IGNITE-20744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-20744: --- Labels: ise (was: ) > StandaloneContext should not load plugins from classpath > > > Key: IGNITE-20744 > URL: https://issues.apache.org/jira/browse/IGNITE-20744 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Only explicitly specified plugins should be loaded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20812) Sql. Performance of a queries affected by number of partitions
Konstantin Orlov created IGNITE-20812: - Summary: Sql. Performance of a queries affected by number of partitions Key: IGNITE-20812 URL: https://issues.apache.org/jira/browse/IGNITE-20812 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Performance of INSERT and SELECT by primary key queries is affected by number of partitions in the table. Most probably, the reason is a lack of partition pruning in sql engine. Let's investigate and fix the problem. Here is a result of local (on my laptop; 2,6 GHz 6-Core Intel Core i7 32GB RAM) benchmark: ||Benchmark||(clusterSize)||(fsync)||(partitionCount)||Mode||Cnt||Score||Error||Units|| |InsertBenchmark.sqlInsert|1|false|1|avgt|20|0.643|± 0.069|ms/op| |InsertBenchmark.sqlInsert|1|false|5|avgt|20|0.756|± 0.049|ms/op| |InsertBenchmark.sqlInsert|1|false|25|avgt|20|1.114|± 0.093|ms/op| |SelectBenchmark.sqlGet|1|false|1|avgt|20|203.432|± 16.617|us/op| |SelectBenchmark.sqlGet|1|false|5|avgt|20|320.383|± 22.086|us/op| |SelectBenchmark.sqlGet|1|false|25|avgt|20|794.232|± 49.473|us/op| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18595) Implement index build process during the full state transfer
[
https://issues.apache.org/jira/browse/IGNITE-18595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-18595:
Assignee: Kirill Tkalenko
> Implement index build process during the full state transfer
>
>
> Key: IGNITE-18595
> URL: https://issues.apache.org/jira/browse/IGNITE-18595
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> Here there is no source of information for schema versions, associated with
> individual inserts. The core idea of the full rebalance is that all versions
> of all rows will be sent, while indexes will be rebuilt locally on the
> consumer. This is unfortunate. Why, you may ask.
> Imagine the following situation:
> * time T1: table A with index X is created
> * time T2: user uploads the data
> * time T3: user drops index X
> * time T4: “clean” node N enters topology and downloads data via full
> rebalance procedure
> * time T5: N becomes a leader and receives (already running) RO transactions
> with timestamp T2 Ideally, index X should be available for timestamp T. If the index is already
> available, it can’t suddenly become unavailable without an explicit rebuild
> request from the user (I guess).
> The LATEST schema version at the moment of rebalance must be known. That’s
> unavoidable and makes total sense. First idea that comes to mind is updating
> all Registered and Available indexes. Situation, when an index has more
> indexed rows than it requires, is correct. Scan queries only return indexed
> rows that match corresponding value in the partition MV store. The real
> problem would be having less data than required.
> The way that the approach is described in paragraph above is not quite
> correct. Let’s consider that there is a BinaryRow version. It defines a set
> of columns in the table at the moment of update. Not all row versions are
> compatible with all indexes. For example, you cannot put data into an index
> if a column has been deleted. On the other hand, you can put data in the
> index if a column has not yet been created (assuming it has a default value).
> In both cases the column is missing from the row version, but the outcome is
> very different.
> This fact has some implications. A set of indexes to be updated depends on
> the row version for every particular row. I propose calculating it as a set
> of all indexes from a {_}maximal continuous range of db schemas{_}, that (if
> not empty) starts with the earliest known schema and _all schemas in the
> range have all indexed columns_ existing in the table.
> For example, there’s a table T:
> |DB schema version|Table columns|
> |1|PK, A|
> |2|PK, A, B|
> |3 (LATEST)|PK, B|
>
> In such configuration, ranges would be:
> |Index columns|Schemas range|
> |A|[1 ... 2]|
> |B|[1 ... 3]|
> |A, B|[1 ... 2]|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18595) Implement index build process during the full state transfer
[
https://issues.apache.org/jira/browse/IGNITE-18595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-18595:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Implement index build process during the full state transfer
>
>
> Key: IGNITE-18595
> URL: https://issues.apache.org/jira/browse/IGNITE-18595
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> Here there is no source of information for schema versions, associated with
> individual inserts. The core idea of the full rebalance is that all versions
> of all rows will be sent, while indexes will be rebuilt locally on the
> consumer. This is unfortunate. Why, you may ask.
> Imagine the following situation:
> * time T1: table A with index X is created
> * time T2: user uploads the data
> * time T3: user drops index X
> * time T4: “clean” node N enters topology and downloads data via full
> rebalance procedure
> * time T5: N becomes a leader and receives (already running) RO transactions
> with timestamp T2 Ideally, index X should be available for timestamp T. If the index is already
> available, it can’t suddenly become unavailable without an explicit rebuild
> request from the user (I guess).
> The LATEST schema version at the moment of rebalance must be known. That’s
> unavoidable and makes total sense. First idea that comes to mind is updating
> all Registered and Available indexes. Situation, when an index has more
> indexed rows than it requires, is correct. Scan queries only return indexed
> rows that match corresponding value in the partition MV store. The real
> problem would be having less data than required.
> The way that the approach is described in paragraph above is not quite
> correct. Let’s consider that there is a BinaryRow version. It defines a set
> of columns in the table at the moment of update. Not all row versions are
> compatible with all indexes. For example, you cannot put data into an index
> if a column has been deleted. On the other hand, you can put data in the
> index if a column has not yet been created (assuming it has a default value).
> In both cases the column is missing from the row version, but the outcome is
> very different.
> This fact has some implications. A set of indexes to be updated depends on
> the row version for every particular row. I propose calculating it as a set
> of all indexes from a {_}maximal continuous range of db schemas{_}, that (if
> not empty) starts with the earliest known schema and _all schemas in the
> range have all indexed columns_ existing in the table.
> For example, there’s a table T:
> |DB schema version|Table columns|
> |1|PK, A|
> |2|PK, A, B|
> |3 (LATEST)|PK, B|
>
> In such configuration, ranges would be:
> |Index columns|Schemas range|
> |A|[1 ... 2]|
> |B|[1 ... 3]|
> |A, B|[1 ... 2]|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18595) Implement index build process during the full state transfer
[
https://issues.apache.org/jira/browse/IGNITE-18595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-18595:
-
Fix Version/s: 3.0.0-beta2
> Implement index build process during the full state transfer
>
>
> Key: IGNITE-18595
> URL: https://issues.apache.org/jira/browse/IGNITE-18595
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Here there is no source of information for schema versions, associated with
> individual inserts. The core idea of the full rebalance is that all versions
> of all rows will be sent, while indexes will be rebuilt locally on the
> consumer. This is unfortunate. Why, you may ask.
> Imagine the following situation:
> * time T1: table A with index X is created
> * time T2: user uploads the data
> * time T3: user drops index X
> * time T4: “clean” node N enters topology and downloads data via full
> rebalance procedure
> * time T5: N becomes a leader and receives (already running) RO transactions
> with timestamp T2 Ideally, index X should be available for timestamp T. If the index is already
> available, it can’t suddenly become unavailable without an explicit rebuild
> request from the user (I guess).
> The LATEST schema version at the moment of rebalance must be known. That’s
> unavoidable and makes total sense. First idea that comes to mind is updating
> all Registered and Available indexes. Situation, when an index has more
> indexed rows than it requires, is correct. Scan queries only return indexed
> rows that match corresponding value in the partition MV store. The real
> problem would be having less data than required.
> The way that the approach is described in paragraph above is not quite
> correct. Let’s consider that there is a BinaryRow version. It defines a set
> of columns in the table at the moment of update. Not all row versions are
> compatible with all indexes. For example, you cannot put data into an index
> if a column has been deleted. On the other hand, you can put data in the
> index if a column has not yet been created (assuming it has a default value).
> In both cases the column is missing from the row version, but the outcome is
> very different.
> This fact has some implications. A set of indexes to be updated depends on
> the row version for every particular row. I propose calculating it as a set
> of all indexes from a {_}maximal continuous range of db schemas{_}, that (if
> not empty) starts with the earliest known schema and _all schemas in the
> range have all indexed columns_ existing in the table.
> For example, there’s a table T:
> |DB schema version|Table columns|
> |1|PK, A|
> |2|PK, A, B|
> |3 (LATEST)|PK, B|
>
> In such configuration, ranges would be:
> |Index columns|Schemas range|
> |A|[1 ... 2]|
> |B|[1 ... 3]|
> |A, B|[1 ... 2]|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20811) Refactoring DataInput hierarchy
Maksim Timonin created IGNITE-20811: --- Summary: Refactoring DataInput hierarchy Key: IGNITE-20811 URL: https://issues.apache.org/jira/browse/IGNITE-20811 Project: Ignite Issue Type: Improvement Reporter: Maksim Timonin Assignee: Maksim Timonin Current hierarchy should be redesigned, as such methods like "position", "size" and Crc32CheckingDataInput should be part of ByteBufferedDataInput. Now they are implemented only for FileInput. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20805) Extract integration raft snapshot tests from runner module to table module
[ https://issues.apache.org/jira/browse/IGNITE-20805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784003#comment-17784003 ] Roman Puchkovskiy commented on IGNITE-20805: The patch looks good to me > Extract integration raft snapshot tests from runner module to table module > -- > > Key: IGNITE-20805 > URL: https://issues.apache.org/jira/browse/IGNITE-20805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to extract raft snapshot integration tests from runner module to > table module to reduce the load on [Runner > suite|https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner&branch_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E&tab=buildTypeStatusDiv] > which takes more than 29 minutes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20810) Fix duplicate documentation for Ignite extensions
[ https://issues.apache.org/jira/browse/IGNITE-20810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev updated IGNITE-20810: Component/s: documentation > Fix duplicate documentation for Ignite extensions > - > > Key: IGNITE-20810 > URL: https://issues.apache.org/jira/browse/IGNITE-20810 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Priority: Major > > Some time ago we created a separate documentation for Ignite extensions in > the extensions repository: > [https://github.com/apache/ignite-extensions] > It is also published, but without links from main doc > [https://ignite.apache.org/docs/extensions/aws/aws] > This currently conflicts with extensions documentation still in the main repo: > [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-boot] > [https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations] > We need to make sure there is only one documentation for extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20810) Fix duplicate documentation for Ignite extensions
Igor Gusev created IGNITE-20810: --- Summary: Fix duplicate documentation for Ignite extensions Key: IGNITE-20810 URL: https://issues.apache.org/jira/browse/IGNITE-20810 Project: Ignite Issue Type: Task Reporter: Igor Gusev Some time ago we created a separate documentation for Ignite extensions in the extensions repository: [https://github.com/apache/ignite-extensions] It is also published, but without links from main doc [https://ignite.apache.org/docs/extensions/aws/aws] This currently conflicts with extensions documentation still in the main repo: [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-boot] [https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations] We need to make sure there is only one documentation for extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20805) Extract integration raft snapshot tests from runner module to table module
[ https://issues.apache.org/jira/browse/IGNITE-20805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20805: - Description: We need to extract raft snapshot integration tests from runner module to table module to reduce the load on [Runner suite|https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner&branch_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E&tab=buildTypeStatusDiv] which takes more than 29 minutes. (was: We need to extract integration tests from runner module to others to reduce the load on [Runner suite|https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner&branch_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E&tab=buildTypeStatusDiv] which takes more than 24 minutes.) > Extract integration raft snapshot tests from runner module to table module > -- > > Key: IGNITE-20805 > URL: https://issues.apache.org/jira/browse/IGNITE-20805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to extract raft snapshot integration tests from runner module to > table module to reduce the load on [Runner > suite|https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner&branch_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E&tab=buildTypeStatusDiv] > which takes more than 29 minutes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20805) Extract integration raft snapshot tests from runner module to table module
[ https://issues.apache.org/jira/browse/IGNITE-20805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20805: - Summary: Extract integration raft snapshot tests from runner module to table module (was: Extract some tests from runner module) > Extract integration raft snapshot tests from runner module to table module > -- > > Key: IGNITE-20805 > URL: https://issues.apache.org/jira/browse/IGNITE-20805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to extract integration tests from runner module to others to reduce > the load on [Runner > suite|https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner&branch_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E&tab=buildTypeStatusDiv] > which takes more than 24 minutes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20808) Sql. Poor performance of INSERT
Konstantin Orlov created IGNITE-20808: - Summary: Sql. Poor performance of INSERT Key: IGNITE-20808 URL: https://issues.apache.org/jira/browse/IGNITE-20808 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov It's expected that sql INSERT is currently slower than kv puts because sql lacks partition pruning. But even on a single-partition table (this case should not be affected by lack of partition pruning) INSERT is 5x times slower than kv. Let's investigate and fix performance of sql INSERT. Here is a result of local (on my laptop; 2,6 GHz 6-Core Intel Core i7 32GB RAM) benchmark: || Benchmark || (clusterSize) || (fsync) || (partitionCount) || Mode || Cnt || Score || Error || Units || | InsertBenchmark.kvInsert | 1 | false | 1 | avgt | 20 | 0.153 | ± 0.019 | ms/op | | InsertBenchmark.sqlInsert | 1 | false | 1 | avgt | 20 | 0.657 | ± 0.056 | ms/op | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20809) Sql. NoSuchMethodException with substring.
Evgeny Stanilovsky created IGNITE-20809:
---
Summary: Sql. NoSuchMethodException with substring.
Key: IGNITE-20809
URL: https://issues.apache.org/jira/browse/IGNITE-20809
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
{code:java}
sql(String.format("SELECT substring((SELECT 'a'), 1, %d + 1)",
Long.MAX_VALUE));{code}
throws inner implementation exception:
{code:java}
Caused by: java.lang.NoSuchMethodException:
org.apache.calcite.runtime.SqlFunctions.substring(java.lang.String, int, long)
at java.base/java.lang.Class.getMethod(Class.java:2108)
at
org.apache.calcite.adapter.enumerable.EnumUtils.call(EnumUtils.java:658){code}
Seems we will obtain the same exceptions with all not implemented inner
functions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20807) Java thin 3.0: Implement nullable operations in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-20807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20807: Description: 1. Implement operations in *ClientKeyValueView*: * getNullableAsync * getOrDefaultAsync * getNullableAndPutAsync * getNullableAndRemoveAsync * getNullableAndReplaceAsync 2. Add null check and throw *UnexpectedNullValueException* the same way as *KeyValueViewImpl* does it. was: * getNullableAsync * getOrDefaultAsync * getNullableAndPutAsync * getNullableAndRemoveAsync * getNullableAndReplaceAsync > Java thin 3.0: Implement nullable operations in ClientKeyValueView > -- > > Key: IGNITE-20807 > URL: https://issues.apache.org/jira/browse/IGNITE-20807 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. Implement operations in *ClientKeyValueView*: > * getNullableAsync > * getOrDefaultAsync > * getNullableAndPutAsync > * getNullableAndRemoveAsync > * getNullableAndReplaceAsync > 2. Add null check and throw *UnexpectedNullValueException* the same way as > *KeyValueViewImpl* does it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20807) Java thin 3.0: Implement nullable operations in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-20807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20807: Description: * getNullableAsync * getOrDefaultAsync * getNullableAndPutAsync * getNullableAndRemoveAsync * getNullableAndReplaceAsync was: * getNullableAsync * getOrDefaultAsync * getNullableAndPutAsync > Java thin 3.0: Implement nullable operations in ClientKeyValueView > -- > > Key: IGNITE-20807 > URL: https://issues.apache.org/jira/browse/IGNITE-20807 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * getNullableAsync > * getOrDefaultAsync > * getNullableAndPutAsync > * getNullableAndRemoveAsync > * getNullableAndReplaceAsync -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20807) Java thin 3.0: Implement nullable operations in ClientKeyValueView
Pavel Tupitsyn created IGNITE-20807: --- Summary: Java thin 3.0: Implement nullable operations in ClientKeyValueView Key: IGNITE-20807 URL: https://issues.apache.org/jira/browse/IGNITE-20807 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20807) Java thin 3.0: Implement nullable operations in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-20807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20807: Description: * getNullableAsync * getOrDefaultAsync * getNullableAndPutAsync > Java thin 3.0: Implement nullable operations in ClientKeyValueView > -- > > Key: IGNITE-20807 > URL: https://issues.apache.org/jira/browse/IGNITE-20807 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * getNullableAsync > * getOrDefaultAsync > * getNullableAndPutAsync -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20295) Sql. Get rid of server-side session management
[ https://issues.apache.org/jira/browse/IGNITE-20295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20295: -- Fix Version/s: 3.0.0-beta2 > Sql. Get rid of server-side session management > -- > > Key: IGNITE-20295 > URL: https://issues.apache.org/jira/browse/IGNITE-20295 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > At the begining of Ignite 3 was plans to have server side sessions and > partially it was implemented, but now it's not actual and we could remove all > obsolete code related to the part. > At least required to remove package > org.apache.ignite.internal.sql.engine.session with all classes. > All stuff requires for keep 'session' information could be moved to client > handlers, like a ClientResource class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19830) Add a description check if the command argument is enum type.
[
https://issues.apache.org/jira/browse/IGNITE-19830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783980#comment-17783980
]
Ignite TC Bot commented on IGNITE-19830:
{panel:title=Branch: [pull/10818/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10818/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7604097]]
* {color:#013220}IgniteControlUtilityTestSuite:
CommandHandlerParsingTest.testEnumParameterDescription - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7604164&buildTypeId=IgniteTests24Java8_RunAll]
> Add a description check if the command argument is enum type.
> -
>
> Key: IGNITE-19830
> URL: https://issues.apache.org/jira/browse/IGNITE-19830
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: IEP-81, ise
> Fix For: 2.16
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add a check for the presence of a enum description ({{@EnumDescription}}) if
> the parameter ({{@Argument}}) is an enum type.
> Example of an uncovered argument: {{ShutdownPolicyCommandArg#shutdownPolicy}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20806) Add --format option to the configuration commands
Aleksandr created IGNITE-20806: -- Summary: Add --format option to the configuration commands Key: IGNITE-20806 URL: https://issues.apache.org/jira/browse/IGNITE-20806 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr Now commands `cluster/node config show` display the configuration in JSON format. It might be handy in some cases but by default, it should be displayed in HOCON format (without "). I propose adding a new --format option to these commands and specifying two types of values for it: json and hocon (default). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20799) Fix Hibernate tests
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20799:
---
Description:
Currently, Hibernate test job fails because of execution timeout [1]. It should
be fixed.
*Failures:*
After IGNITE-20579 {{HibernateL2CacheSelfTest}} fails and hangs with an error:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allowed by default. Since 2.16.0 atomic
operations inside transactions are finally forbidden.
{code}
HibernateL2CacheTransactionalSelfTest tests fails with a following error:
{code}
[error] SubCoordinator.addResource: bad status=
STATUS_COMMITTED[2023-11-07T18:50:26,244][ERROR][main][] Test failed
[test=HibernateL2CacheTransactionalSelfTest#testQueryCache, duration=1327]
org.hibernate.TransactionException: JTA TransactionManager#commit failed
at
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionAdapterTransactionManagerImpl.commit(JtaTransactionAdapterTransactionManagerImpl.java:65)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
at
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JtaTransactionCoordinatorImpl.java:437)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
at
org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
at
org.apache.ignite.cache.hibernate.HibernateL2CacheSelfTest.testQueryCache(HibernateL2CacheSelfTest.java:1459)
~[test-classes/:?]
at
org.apache.ignite.cache.hibernate.HibernateL2CacheSelfTest.testQueryCache(HibernateL2CacheSelfTest.java:1440)
~[test-classes/:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:?]
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:?]
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
~[junit-4.12.jar:4.12]
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
~[junit-4.12.jar:4.12]
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2499)
~[test-classes/:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
Caused by: java.lang.IllegalStateException: enlistResource: could not
addResource CacheJtaResource [cacheTx=GridNearTxLocal ...]
at
org.objectweb.jotm.TransactionImpl.enlistResource(TransactionImpl.java:483)
~[jotm-core-2.3.1-M1.jar:?]
at
org.apache.ignite.internal.processors.cache.jta.CacheJtaManager.checkJta(CacheJtaManager.java:180)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.checkJta(GridCacheAdapter.java:3579)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4167)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2456)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2434)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2413)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.put(GridCacheProxyImpl.java:524)
~[classes/:?]
at
org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:198)
~[classes/:?]
at
org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
~[classes/:?]
at
org.hibernate.cache.internal.TimestampsCacheEnabledImpl.invalidate(TimestampsCacheEnabledImpl.java:87)
~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
{code}
*Links:*
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
was:
Currently, Hibernate test job fails because of execution timeout [1]. It should
be fixed.
After IGNITE-20579 {{HibernateL2CacheSelfTest}} fails and hangs with an error:
{code}
class org.apache.ignite.IgniteException: Transaction spans operations on atomic
cache (don't use atomic cache inside a transaction). Since 2.15.0 atomic
operations inside transactions are not allow
[jira] [Updated] (IGNITE-20803) Split ActionRequest into read and write interfaces
[ https://issues.apache.org/jira/browse/IGNITE-20803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20803: - Ignite Flags: (was: Docs Required,Release Notes Required) > Split ActionRequest into read and write interfaces > -- > > Key: IGNITE-20803 > URL: https://issues.apache.org/jira/browse/IGNITE-20803 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Needed for https://issues.apache.org/jira/browse/IGNITE-19453. Write commands > must be (will be) serialized into byte[], while read commands will never be > serialized into a byte[]. > If we introduce different representations for different commands, using > different action request implementation is the only efficient choice that we > have. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20803) Split ActionRequest into read and write interfaces
[ https://issues.apache.org/jira/browse/IGNITE-20803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20803: - Reviewer: Kirill Tkalenko > Split ActionRequest into read and write interfaces > -- > > Key: IGNITE-20803 > URL: https://issues.apache.org/jira/browse/IGNITE-20803 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Needed for https://issues.apache.org/jira/browse/IGNITE-19453. Write commands > must be (will be) serialized into byte[], while read commands will never be > serialized into a byte[]. > If we introduce different representations for different commands, using > different action request implementation is the only efficient choice that we > have. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20803) Split ActionRequest into read and write interfaces
[ https://issues.apache.org/jira/browse/IGNITE-20803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20803: - Fix Version/s: 3.0.0-beta2 > Split ActionRequest into read and write interfaces > -- > > Key: IGNITE-20803 > URL: https://issues.apache.org/jira/browse/IGNITE-20803 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Needed for https://issues.apache.org/jira/browse/IGNITE-19453. Write commands > must be (will be) serialized into byte[], while read commands will never be > serialized into a byte[]. > If we introduce different representations for different commands, using > different action request implementation is the only efficient choice that we > have. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20803) Split ActionRequest into read and write interfaces
[ https://issues.apache.org/jira/browse/IGNITE-20803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783949#comment-17783949 ] Kirill Tkalenko commented on IGNITE-20803: -- Looks good! > Split ActionRequest into read and write interfaces > -- > > Key: IGNITE-20803 > URL: https://issues.apache.org/jira/browse/IGNITE-20803 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Needed for https://issues.apache.org/jira/browse/IGNITE-19453. Write commands > must be (will be) serialized into byte[], while read commands will never be > serialized into a byte[]. > If we introduce different representations for different commands, using > different action request implementation is the only efficient choice that we > have. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20700) Implement durable transaction coordinator finish
[ https://issues.apache.org/jira/browse/IGNITE-20700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-20700: --- Reviewer: Denis Chudov > Implement durable transaction coordinator finish > > > Key: IGNITE-20700 > URL: https://issues.apache.org/jira/browse/IGNITE-20700 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Time Spent: 8h > Remaining Estimate: 0h > > h3. Motivation > Transaction coordinator should properly handle: > * All kind of exceptions that might be thrown during sending finish request > and finish response awaiting. > * Commit partition primary replica changes. > * Including dedicated scenario of commit partition recovery after commit > partition majority loss. > h3. Definition of Done > Transaction finish request is sent in a durable manner. > h3. Implementation Notes > * Commit timestamp, tx outcome (commit/abort), enlisted paritions set, etc > are calculated once only and do not change over retries. > * Recipient on the other hand may change, and should be evaluated as > PD.awaitPrimaryReplica(commitPartition). Thus, we will handle both primary > replica changes and commit partition recovery after majority loss. > * On the commit partition side, finish request should await for all locks to > be released (see lock released flag in txnState). > * It's possible for finish request to see a terminated transaction with > another outcome, meaning that recovery logic (that's not yet implemented) > will rollback the transaction while finish request contains commit as the > desired outcome. In that case, we expect the user to receive a > tx-was-rolled-back exception. Any consecutive user calls, both commit and > rollback should not throw exceptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20748) Document new flags for JDK 11 and JDK 17
[ https://issues.apache.org/jira/browse/IGNITE-20748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783943#comment-17783943 ] Igor Gusev commented on IGNITE-20748: - [~ivandasch] can you review the PR? > Document new flags for JDK 11 and JDK 17 > > > Key: IGNITE-20748 > URL: https://issues.apache.org/jira/browse/IGNITE-20748 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ivan Daschinsky >Assignee: Igor Gusev >Priority: Major > Labels: documentation > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20748) Document new flags for JDK 11 and JDK 17
[ https://issues.apache.org/jira/browse/IGNITE-20748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-20748: --- Assignee: Igor Gusev > Document new flags for JDK 11 and JDK 17 > > > Key: IGNITE-20748 > URL: https://issues.apache.org/jira/browse/IGNITE-20748 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ivan Daschinsky >Assignee: Igor Gusev >Priority: Major > Labels: documentation > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20802) Java Thin Client doesn't retry service invocation on node-left-exception
[ https://issues.apache.org/jira/browse/IGNITE-20802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20802: Summary: Java Thin Client doesn't retry service invocation on node-left-exception (was: Java Thin Client doesn't retry service invocation on node-left-exception. ) > Java Thin Client doesn't retry service invocation on node-left-exception > > > Key: IGNITE-20802 > URL: https://issues.apache.org/jira/browse/IGNITE-20802 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Attachments: ServiceCallRetryThinClientTest.java > > > Consider: > 1) Thin Client sends a service call request to some node A. > 2) Node A has no the service instance and executes remote service invocation > task to node B. > 3) Node B leaves cluster at the same time. > 4) The service call redirection task fails on node A. > 5) Node A terminates the initial client request raising a Node-B-Left > Exception. > 6) The client receives this exception and does not process it with a service > call retry. > The service invocation request should be retried. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20356) Sql. Rework RowHandler "set" operation.
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-20356:
--
Fix Version/s: 3.0.0-beta2
> Sql. Rework RowHandler "set" operation.
> ---
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using {{set(int, RowT, Object)}} method, we can use the
> {{append(RowT, Object)}} method to add field values sequentially.
> We need:
> * Add a new RowFactory method that will return a builder that allows you to
> append values to row and build the row.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
