[jira] [Commented] (IGNITE-18102) Ignite does not support create table with dot column
[ https://issues.apache.org/jira/browse/IGNITE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644611#comment-17644611 ] Evgeny Stanilovsky commented on IGNITE-18102: - https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > Ignite does not support create table with dot column > > > Key: IGNITE-18102 > URL: https://issues.apache.org/jira/browse/IGNITE-18102 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Chenjian >Priority: Minor > Attachments: image-2022-11-07-17-57-49-255.png, > image-2022-11-07-18-01-49-687.png > > > Ignite does not support create the column with dot. > like create table (... , `a.dot` bigint, ...), using the !columns command > only can see the suffix about the defined name `dot`. > But Ignite allow add column with dot which is not compatible with self. > Eg: > !image-2022-11-07-17-57-49-255.png! > !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18352) ignite-spring-sessions: Unsupported default cache name for Windows platform
Andrey Novikov created IGNITE-18352: --- Summary: ignite-spring-sessions: Unsupported default cache name for Windows platform Key: IGNITE-18352 URL: https://issues.apache.org/jira/browse/IGNITE-18352 Project: Ignite Issue Type: Bug Components: extensions Affects Versions: 1.0 Reporter: Andrey Novikov IgniteIndexedSessionRepository#DEFAULT_SESSION_MAP_NAME contains unsupported character `:` in cache name for Windows platform. *What to do:* Rename default name of map to `IgniteSessionCache` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18294) Multiple lock intentions support
[ https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644484#comment-17644484 ] Vladislav Pyatkov commented on IGNITE-18294: Merged 92466d5bfce5f6a7efe2d4d6a744c6f67b56d48f > Multiple lock intentions support > > > Key: IGNITE-18294 > URL: https://issues.apache.org/jira/browse/IGNITE-18294 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Current implementation of HeapLockManager relies on waiters that can support > only one lock intention for each transaction at a moment of time. This can > lead to problems like following: > - there are transactions tx1, tx2, tx3 started in corresponding order; > - all txs acquire S-locks; > - tx2 tries to acquire IX-lock, it's incompatible with S-locks from tx1 and > tx3, this is a lock intention and a future is created, which is completed > when SIX-lock is acquired (supremum of S and IX locks) > - tx2 concurrently tries to acquire X-lock, this is another lock intention, > supremum of locks for tx2 is X-lock. The information about previous intention > is lost; > - tx3 is committed, and tx2 waits only for tx1 but it is not allowed to wait > for it due to wait-die deadlock prevention. All lock intentions should be > canceled. > Definition of done: > We have lock mode counters inside of waiter, they should be adapted for lock > intention support. Also, "upgraded" flag of waiters and all the logic related > to "previous lock mode" should be removed. After that, the test scenario > described above should pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18102) Ignite does not support create table with dot column
[ https://issues.apache.org/jira/browse/IGNITE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644421#comment-17644421 ] Chenjian commented on IGNITE-18102: --- [~jooger] Thanks for the clarification, do you know how to pick up the ticket? I wanna have a try > Ignite does not support create table with dot column > > > Key: IGNITE-18102 > URL: https://issues.apache.org/jira/browse/IGNITE-18102 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Chenjian >Priority: Minor > Attachments: image-2022-11-07-17-57-49-255.png, > image-2022-11-07-18-01-49-687.png > > > Ignite does not support create the column with dot. > like create table (... , `a.dot` bigint, ...), using the !columns command > only can see the suffix about the defined name `dot`. > But Ignite allow add column with dot which is not compatible with self. > Eg: > !image-2022-11-07-17-57-49-255.png! > !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18102) Ignite does not support create table with dot column
[ https://issues.apache.org/jira/browse/IGNITE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chenjian updated IGNITE-18102: -- Priority: Minor (was: Major) > Ignite does not support create table with dot column > > > Key: IGNITE-18102 > URL: https://issues.apache.org/jira/browse/IGNITE-18102 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Chenjian >Priority: Minor > Attachments: image-2022-11-07-17-57-49-255.png, > image-2022-11-07-18-01-49-687.png > > > Ignite does not support create the column with dot. > like create table (... , `a.dot` bigint, ...), using the !columns command > only can see the suffix about the defined name `dot`. > But Ignite allow add column with dot which is not compatible with self. > Eg: > !image-2022-11-07-17-57-49-255.png! > !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18102) Ignite does not support create table with dot column
[ https://issues.apache.org/jira/browse/IGNITE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644413#comment-17644413 ] Yury Gerzhedovich commented on IGNITE-18102: [~chenjian2664] unfortunately no, it looks not so critical issue and I just check and confirm that is real issue. Maybe someone from community takes the ticket. > Ignite does not support create table with dot column > > > Key: IGNITE-18102 > URL: https://issues.apache.org/jira/browse/IGNITE-18102 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Chenjian >Priority: Major > Attachments: image-2022-11-07-17-57-49-255.png, > image-2022-11-07-18-01-49-687.png > > > Ignite does not support create the column with dot. > like create table (... , `a.dot` bigint, ...), using the !columns command > only can see the suffix about the defined name `dot`. > But Ignite allow add column with dot which is not compatible with self. > Eg: > !image-2022-11-07-17-57-49-255.png! > !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18282) Illegal use of dynamic parameter exception in SQL functions
[
https://issues.apache.org/jira/browse/IGNITE-18282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644390#comment-17644390
]
Evgeny Stanilovsky commented on IGNITE-18282:
-
[~jooger] i fill some comments, plz check.
> Illegal use of dynamic parameter exception in SQL functions
> ---
>
> Key: IGNITE-18282
> URL: https://issues.apache.org/jira/browse/IGNITE-18282
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Query*
> {code}
> select Power(_T0.KEY, ?) from PUBLIC.TBL_DOUBLE as _T0
> {code}
> *Result*
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 27:
> Illegal use of dynamic parameter
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1982)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2064)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2064)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:462)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4505)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3710)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:207)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$1(PrepareServiceImpl.java:227)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Illegal use
> of dynamic parameter
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
> ... 23 more
> {code}
> * The same applies to all other functions, like *trim, instr, ln, concat*
> * This query works in Ignite 2.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18351) Make a lock menagment interface modre friendly
[ https://issues.apache.org/jira/browse/IGNITE-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18351: --- Description: Recently, we redesigned the behavior of lock manager, but did not modify the interface. This leads the method name does not compatible that the method do. The ticket inspires to improve interface of lock manager to avoid using the interface wrong. * The lock mode LockMode#NL is used nowhere. It is s candidate to remove. * The LockManager#release(org.apache.ignite.internal.tx.Lock) method is removed all locks on a particular transaction, but the method takes a lock (not a transaction id). Redesign the method in order to release all lock for the particular transaction. * The LockManager#release(UUID, LockKey, LockMode) releases a particular lock, but the method does not take a lock object. was: Recently, we redesigned the behavior of lock manager, but did not modify the interface. This leads the method name does not compatible that the method do. The ticket inspires to improve interface of lock manager to avoid using the interface wrong. 1) The lock mode LockMode#NL is used nowhere. It is s candidate to remove. 2) The LockManager#release(org.apache.ignite.internal.tx.Lock) method is removed all locks on a particular transaction, but the method takes a lock (not a transaction id). Redesign the method in order to release all lock for the particular transaction. 3) The LockManager#release(UUID, LockKey, LockMode) releases a particular lock, but the method does not take a lock object. > Make a lock menagment interface modre friendly > -- > > Key: IGNITE-18351 > URL: https://issues.apache.org/jira/browse/IGNITE-18351 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Recently, we redesigned the behavior of lock manager, but did not modify the > interface. This leads the method name does not compatible that the method do. > The ticket inspires to improve interface of lock manager to avoid using the > interface wrong. > * The lock mode LockMode#NL is used nowhere. It is s candidate to remove. > * The LockManager#release(org.apache.ignite.internal.tx.Lock) method is > removed all locks on a particular transaction, but the method takes a lock > (not a transaction id). Redesign the method in order to release all lock for > the particular transaction. > * The LockManager#release(UUID, LockKey, LockMode) releases a particular > lock, but the method does not take a lock object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18351) Make a lock menagment interface modre friendly
Vladislav Pyatkov created IGNITE-18351: -- Summary: Make a lock menagment interface modre friendly Key: IGNITE-18351 URL: https://issues.apache.org/jira/browse/IGNITE-18351 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov Recently, we redesigned the behavior of lock manager, but did not modify the interface. This leads the method name does not compatible that the method do. The ticket inspires to improve interface of lock manager to avoid using the interface wrong. 1) The lock mode LockMode#NL is used nowhere. It is s candidate to remove. 2) The LockManager#release(org.apache.ignite.internal.tx.Lock) method is removed all locks on a particular transaction, but the method takes a lock (not a transaction id). Redesign the method in order to release all lock for the particular transaction. 3) The LockManager#release(UUID, LockKey, LockMode) releases a particular lock, but the method does not take a lock object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18349) Move LogicalTopologyService to an internal package
[ https://issues.apache.org/jira/browse/IGNITE-18349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-18349: --- Summary: Move LogicalTopologyService to an internal package (was: Move LogicalTopologyService to an inner package) > Move LogicalTopologyService to an internal package > -- > > Key: IGNITE-18349 > URL: https://issues.apache.org/jira/browse/IGNITE-18349 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > This interface (and the dependent types) should not be a part of the public > API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18350) Redesign two ciollections of lock modes to a bitset into the heap lock manager
[
https://issues.apache.org/jira/browse/IGNITE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-18350:
---
Description:
We have two collections, those store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for convenient way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
was:
We have two collections, those store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for continent way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
> Redesign two ciollections of lock modes to a bitset into the heap lock manager
> --
>
> Key: IGNITE-18350
> URL: https://issues.apache.org/jira/browse/IGNITE-18350
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> We have two collections, those store lock modes:
> {code}
> HeapLockManager.WaiterImpl#locks
> HeapLockManager.WaiterImpl#intendedLocks
> {code}
> That is done for convenient way to implement all lock manager requirement.
> But for optimization, we can do this through _BitSet_. The redesign is
> possible because we have predefined lock modes (_LockMode_) and attempts to
> accesses to the modes are bounded. The amount of attempts significantly less
> than MaxInt value.
> The optimization allows using less memory for lock on each entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18350) Redesign two ciollections of lock modes to a bitset into the heap lock manager
[
https://issues.apache.org/jira/browse/IGNITE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-18350:
---
Description:
We have two collections, those store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for continent way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
was:
We have two collection that store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for continent way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
> Redesign two ciollections of lock modes to a bitset into the heap lock manager
> --
>
> Key: IGNITE-18350
> URL: https://issues.apache.org/jira/browse/IGNITE-18350
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> We have two collections, those store lock modes:
> {code}
> HeapLockManager.WaiterImpl#locks
> HeapLockManager.WaiterImpl#intendedLocks
> {code}
> That is done for continent way to implement all lock manager requirement. But
> for optimization, we can do this through _BitSet_. The redesign is possible
> because we have predefined lock modes (_LockMode_) and attempts to accesses
> to the modes are bounded. The amount of attempts significantly less than
> MaxInt value.
> The optimization allows using less memory for lock on each entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18294) Multiple lock intentions support
[ https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644374#comment-17644374 ] Sergey Uttsel commented on IGNITE-18294: LGTM > Multiple lock intentions support > > > Key: IGNITE-18294 > URL: https://issues.apache.org/jira/browse/IGNITE-18294 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Current implementation of HeapLockManager relies on waiters that can support > only one lock intention for each transaction at a moment of time. This can > lead to problems like following: > - there are transactions tx1, tx2, tx3 started in corresponding order; > - all txs acquire S-locks; > - tx2 tries to acquire IX-lock, it's incompatible with S-locks from tx1 and > tx3, this is a lock intention and a future is created, which is completed > when SIX-lock is acquired (supremum of S and IX locks) > - tx2 concurrently tries to acquire X-lock, this is another lock intention, > supremum of locks for tx2 is X-lock. The information about previous intention > is lost; > - tx3 is committed, and tx2 waits only for tx1 but it is not allowed to wait > for it due to wait-die deadlock prevention. All lock intentions should be > canceled. > Definition of done: > We have lock mode counters inside of waiter, they should be adapted for lock > intention support. Also, "upgraded" flag of waiters and all the logic related > to "previous lock mode" should be removed. After that, the test scenario > described above should pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18350) Redesign two ciollections of lock modes to a bitset into the heap lock manager
[
https://issues.apache.org/jira/browse/IGNITE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-18350:
---
Summary: Redesign two ciollections of lock modes to a bitset into the heap
lock manager (was: Redesign two ciollection of lock modes to a bitset into the
heap lock manager)
> Redesign two ciollections of lock modes to a bitset into the heap lock manager
> --
>
> Key: IGNITE-18350
> URL: https://issues.apache.org/jira/browse/IGNITE-18350
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> We have two collection that store lock modes:
> {code}
> HeapLockManager.WaiterImpl#locks
> HeapLockManager.WaiterImpl#intendedLocks
> {code}
> That is done for continent way to implement all lock manager requirement. But
> for optimization, we can do this through _BitSet_. The redesign is possible
> because we have predefined lock modes (_LockMode_) and attempts to accesses
> to the modes are bounded. The amount of attempts significantly less than
> MaxInt value.
> The optimization allows using less memory for lock on each entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17953) NPE and closed connection on some malformed SQL requests using third-party SQL clients
[
https://issues.apache.org/jira/browse/IGNITE-17953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-17953:
---
Labels: ignite-3 (was: calcite3-required ignite-3)
> NPE and closed connection on some malformed SQL requests using third-party
> SQL clients
> --
>
> Key: IGNITE-17953
> URL: https://issues.apache.org/jira/browse/IGNITE-17953
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I try to run different SQL queries in AI3 using
> [SqlLine|https://github.com/julianhyde/sqlline] tool and fresh ignite-client
> JAR downloaded from CI. I tried both correct and some incorrect SQL queries.
> And it looks like some incorrect SQL queries lead to irrecoverable error on
> the client side. The stack trace is the following:
> {code:java}
> Oct 21, 2022 4:57:02 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.lang.NullPointerException
> at org.apache.ignite.lang.ErrorGroup.errorMessage(ErrorGroup.java:193)
> at
> org.apache.ignite.lang.IgniteException.(IgniteException.java:190)
> at
> org.apache.ignite.internal.client.TcpClientChannel.readError(TcpClientChannel.java:336)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:301)
> at
> org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:160)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:94)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:34)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Oct 21, 2022 4:58:07 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.io.IOException: Connection reset by peer
> at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at
>
[jira] [Updated] (IGNITE-18350) Redesign two ciollection of lock modes to a bitset into the heap lock manager
[
https://issues.apache.org/jira/browse/IGNITE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-18350:
---
Labels: ignite-3 (was: )
> Redesign two ciollection of lock modes to a bitset into the heap lock manager
> -
>
> Key: IGNITE-18350
> URL: https://issues.apache.org/jira/browse/IGNITE-18350
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> We have two collection that store lock modes:
> {code}
> HeapLockManager.WaiterImpl#locks
> HeapLockManager.WaiterImpl#intendedLocks
> {code}
> That is done for continent way to implement all lock manager requirement. But
> for optimization, we can do this through _BitSet_. The redesign is possible
> because we have predefined lock modes (_LockMode_) and attempts to accesses
> to the modes are bounded. The amount of attempts significantly less than
> MaxInt value.
> The optimization allows using less memory for lock on each entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18350) Redesign two ciollection of lock modes to a bitset into the heap lock manager
Vladislav Pyatkov created IGNITE-18350:
--
Summary: Redesign two ciollection of lock modes to a bitset into
the heap lock manager
Key: IGNITE-18350
URL: https://issues.apache.org/jira/browse/IGNITE-18350
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
We have two collection that store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for continent way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18349) Move LogicalTopologyService to an inner package
Roman Puchkovskiy created IGNITE-18349: -- Summary: Move LogicalTopologyService to an inner package Key: IGNITE-18349 URL: https://issues.apache.org/jira/browse/IGNITE-18349 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy This interface (and the dependent types) should not be a part of the public API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-18348: --- Assignee: Julia Bakulina > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17793) Historical rebalance must use HWM instead of LWM to seek the proper checkpoint to avoid the data loss
[
https://issues.apache.org/jira/browse/IGNITE-17793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644342#comment-17644342
]
Anton Vinogradov commented on IGNITE-17793:
---
Merged to the master.
Thanks for the contribution!
> Historical rebalance must use HWM instead of LWM to seek the proper
> checkpoint to avoid the data loss
> -
>
> Key: IGNITE-17793
> URL: https://issues.apache.org/jira/browse/IGNITE-17793
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.15
>
> Attachments: HistoricalRebalanceCheckpointTest.java
>
>
> Currently, historical rebalance at
> {{CheckpointHistory#searchEarliestWalPointer}} seeks for the newest
> checkpoint with counter less that lowest entry has to be rebalanced.
> Unfortunately, we may have more that one checkpoint with the same counter and
> it's impossible to use the newest one as a rebalance start point.
> For example, we have partition with LWM=100, some gaps and HWM=200.
> Checkpoint will have the counter == 100.
> Then we may close some gaps, exluding 101 (to keep LWM == 100).
> And again, checkpoint will have counter == 100.
> Newest checkpoint (marked with counter 100) will not cointain all committed
> entries with counter > 100.
> Then lets close the rest of the gaps to make historical rebalance possible.
> And after the rebalance finish, we'll see a warning "Some partition entries
> were missed during historical rebalance" and inconsistent cluster state.
> See reproducer at [^HistoricalRebalanceCheckpointTest.java]
> Possible solution is to use HWM instead of LWM during the search.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise newbie (was: ise) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17793) Historical rebalance must use HWM instead of LWM to seek the proper checkpoint to avoid the data loss
[
https://issues.apache.org/jira/browse/IGNITE-17793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-17793:
--
Fix Version/s: 2.15
> Historical rebalance must use HWM instead of LWM to seek the proper
> checkpoint to avoid the data loss
> -
>
> Key: IGNITE-17793
> URL: https://issues.apache.org/jira/browse/IGNITE-17793
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.15
>
> Attachments: HistoricalRebalanceCheckpointTest.java
>
>
> Currently, historical rebalance at
> {{CheckpointHistory#searchEarliestWalPointer}} seeks for the newest
> checkpoint with counter less that lowest entry has to be rebalanced.
> Unfortunately, we may have more that one checkpoint with the same counter and
> it's impossible to use the newest one as a rebalance start point.
> For example, we have partition with LWM=100, some gaps and HWM=200.
> Checkpoint will have the counter == 100.
> Then we may close some gaps, exluding 101 (to keep LWM == 100).
> And again, checkpoint will have counter == 100.
> Newest checkpoint (marked with counter 100) will not cointain all committed
> entries with counter > 100.
> Then lets close the rest of the gaps to make historical rebalance possible.
> And after the rebalance finish, we'll see a warning "Some partition entries
> were missed during historical rebalance" and inconsistent cluster state.
> See reproducer at [^HistoricalRebalanceCheckpointTest.java]
> Possible solution is to use HWM instead of LWM during the search.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise (was: ise newbie) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise newbie (was: ise) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise (was: ) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
Julia Bakulina created IGNITE-18348: --- Summary: Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state() Key: IGNITE-18348 URL: https://issues.apache.org/jira/browse/IGNITE-18348 Project: Ignite Issue Type: Improvement Reporter: Julia Bakulina Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. As per the ignite docs: Ignite.active() -> it is recommended to use IgniteCluster.active() instead; Ignite.active(boolean active) -> it is recommended to use IgniteCluster.active(boolean active) instead. It seems that it is time to update these deprecated methods, update the corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17793) Historical rebalance must use HWM instead of LWM to seek the proper checkpoint to avoid the data loss
[
https://issues.apache.org/jira/browse/IGNITE-17793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644334#comment-17644334
]
Ignite TC Bot commented on IGNITE-17793:
{panel:title=Branch: [pull/10396/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10396/head] Base: [master] : New Tests
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
5|https://ci2.ignite.apache.org/viewLog.html?buildId=6950220]]
* {color:#013220}IgnitePdsTestSuite2:
HistoricalRebalanceCheckpointTest.testDelayedToBackupsRequests2BackupsMorePuts
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
HistoricalRebalanceCheckpointTest.testDelayedToBackupsRequests1BackupMorePuts -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
HistoricalRebalanceCheckpointTest.testDelayedToBackupsRequests1Backup -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
HistoricalRebalanceCheckpointTest.testDelayed1PhaseCommitResponses -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
HistoricalRebalanceCheckpointTest.testDelayedToBackupsRequests2Backups -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6940776buildTypeId=IgniteTests24Java8_RunAll]
> Historical rebalance must use HWM instead of LWM to seek the proper
> checkpoint to avoid the data loss
> -
>
> Key: IGNITE-17793
> URL: https://issues.apache.org/jira/browse/IGNITE-17793
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-31, ise
> Attachments: HistoricalRebalanceCheckpointTest.java
>
>
> Currently, historical rebalance at
> {{CheckpointHistory#searchEarliestWalPointer}} seeks for the newest
> checkpoint with counter less that lowest entry has to be rebalanced.
> Unfortunately, we may have more that one checkpoint with the same counter and
> it's impossible to use the newest one as a rebalance start point.
> For example, we have partition with LWM=100, some gaps and HWM=200.
> Checkpoint will have the counter == 100.
> Then we may close some gaps, exluding 101 (to keep LWM == 100).
> And again, checkpoint will have counter == 100.
> Newest checkpoint (marked with counter 100) will not cointain all committed
> entries with counter > 100.
> Then lets close the rest of the gaps to make historical rebalance possible.
> And after the rebalance finish, we'll see a warning "Some partition entries
> were missed during historical rebalance" and inconsistent cluster state.
> See reproducer at [^HistoricalRebalanceCheckpointTest.java]
> Possible solution is to use HWM instead of LWM during the search.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18347) .NET: B+Tree is corrupted when string value has emoticons
Danut Radoaica created IGNITE-18347: --- Summary: .NET: B+Tree is corrupted when string value has emoticons Key: IGNITE-18347 URL: https://issues.apache.org/jira/browse/IGNITE-18347 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.14 Environment: Apache Ignite: v2.14.0 JDK: v1.11 .NET Core: v6.0 Reporter: Danut Radoaica exception: "JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=CRITICAL_ERROR, err=class o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is corrupted [groupId=-1229361758, pageIds=[1129924291198982], groupName=Druid.DataAccess.DbEntities.LiveChatConversation, msg=Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=937, val=6194b7bf-64a0-4b00-87eb-2660ecc3536a, hasValBytes=true], hash=1847364021, cacheId=-998779923" test string value: "" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-13999) Switch to SHA-512 for jar checksum calculation.
[ https://issues.apache.org/jira/browse/IGNITE-13999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-13999: -- Assignee: Mikhail Pochatkin > Switch to SHA-512 for jar checksum calculation. > --- > > Key: IGNITE-13999 > URL: https://issues.apache.org/jira/browse/IGNITE-13999 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Andrey Mashenkov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > maven-deploy-plugin is responsible for signing jar. However, it seems SHA-1 > is hardcoded there. > In the latest apache parent pom (org.apache:apache:23) a > checksum-maven-plugin is used as a workaround to sign jars with SHA-512. But > it signs only source jar and do not affect binary jar. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-13999) Switch to SHA-512 for jar checksum calculation.
[ https://issues.apache.org/jira/browse/IGNITE-13999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin resolved IGNITE-13999. Resolution: Won't Fix Done in IGNITE-18040 > Switch to SHA-512 for jar checksum calculation. > --- > > Key: IGNITE-13999 > URL: https://issues.apache.org/jira/browse/IGNITE-13999 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Andrey Mashenkov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > maven-deploy-plugin is responsible for signing jar. However, it seems SHA-1 > is hardcoded there. > In the latest apache parent pom (org.apache:apache:23) a > checksum-maven-plugin is used as a workaround to sign jars with SHA-512. But > it signs only source jar and do not affect binary jar. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15452) [Ignite 3] Add JavaDoc style check to the build lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin resolved IGNITE-15452. Resolution: Won't Fix Done in IGNITE-17483 > [Ignite 3] Add JavaDoc style check to the build lifecycle > - > > Key: IGNITE-15452 > URL: https://issues.apache.org/jira/browse/IGNITE-15452 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 3.0.0-alpha2 >Reporter: Valentin Kulichenko >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Similar to IGNITE-15370, we need to enable the JavaDoc style checks as a part > of the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18211) Sql. Adjust Affinity distribution to the new colocation rules
[
https://issues.apache.org/jira/browse/IGNITE-18211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-18211:
-
Assignee: Pavel Pereslegin
> Sql. Adjust Affinity distribution to the new colocation rules
> -
>
> Key: IGNITE-18211
> URL: https://issues.apache.org/jira/browse/IGNITE-18211
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Need to adjust affinity function to be prepared to upcoming concept of
> [Distribution Zones|https://issues.apache.org/jira/browse/IGNITE-17924].
> Following changes are required:
> * AffinityFunction has to be updated with id (name) of the distribution zone
> * (De-)Serialization of the DistributionFunction need to be adjusted as well
> * Integration with table
> Besides, it looks like the following condition is no more valid, thus should
> be removed:
> {code:java}
> //
> org.apache.ignite.internal.sql.engine.trait.TraitUtils#convertDistribution
> if (toTrait.function().affinity() && toTrait.getKeys().size() > 1) {
> return null;
> }
> {code}
> see: org.apache.ignite.internal.sql.engine.planner.JoinColocationPlannerTest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-15451) [Ignite 3] Add PMD check to the build lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-15451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin resolved IGNITE-15451. Resolution: Won't Fix Done in IGNITE-17483 > [Ignite 3] Add PMD check to the build lifecycle > --- > > Key: IGNITE-15451 > URL: https://issues.apache.org/jira/browse/IGNITE-15451 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 3.0.0-alpha2 >Reporter: Valentin Kulichenko >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Similar to IGNITE-15370, we need to enable the PMD checks as a part of the > build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18140) Add ability to create, alter and drop distribution zones from within sql-like public API
[
https://issues.apache.org/jira/browse/IGNITE-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-18140.
Resolution: Done
> Add ability to create, alter and drop distribution zones from within sql-like
> public API
>
>
> Key: IGNITE-18140
> URL: https://issues.apache.org/jira/browse/IGNITE-18140
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]
> introduces new concept of distribution zone along with some assumptions of a
> corresponding manager that will provide an API to create, alter, and drop
> zones. It's however an internal API and thus it's required to provide a
> public one:
> {code:java}
> CREATE ZONE
> { database_name.schema_name.distribution_zone_name |
> schema_name.distribution_zone_name | distribution_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER = filter |
> (, DATA_NODES_FILTER = filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> Few examples
> {code:java}
> Ex 1.1: CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> PARTITIONS = 1024, REPLICAS = 3, AFFINITY_FUNCTION = rendezvous; // Scale up
> only.
>
> Ex 1.2: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = 300; // Both scale up and scale down.
> Default partitions count, replicas count and affinity function will be used.
>
> Ex 1.3: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST = 100; // Same value
> for both scale up and scale down. Default partitions count, replicas count
> and affinity function will be used.
> Ex 1.4: CREATE ZONES zone 4 WITH DATA_NODES_FILTER= ‘(“US” || “EU”) &&
> “SSD”’; // Defail just node filters
> {code}
> And yes, similar syntax is expected for altering and dropping distribution
> zones.
> h3. Definition of Done
> * It's possible to create/alter/drop distribution zones, meaning that
> corresponding methods of distribution zone manager are called.
> * Exceptions if any, e.g. validation ones are properly wrapped and returned
> back to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18319) Pass sender consistendId instead of ClusterNode to handler
[
https://issues.apache.org/jira/browse/IGNITE-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18319:
---
Issue Type: Improvement (was: Bug)
> Pass sender consistendId instead of ClusterNode to handler
> --
>
> Key: IGNITE-18319
> URL: https://issues.apache.org/jira/browse/IGNITE-18319
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, {{DefaultMessagingService#onMessage()}} throws an
> {{AssertionError}} if the message sender is not in the physical topology.
> As this is an expected behavior (a node can sometimes leave), it seems
> correct to handle this gracefully.
> The idea is to allow the handler resolve node by consistentId by itself and
> then decide what to do with a missing {{{}sender{}}}. Some of handlers don't
> even care about the sender because they do not send any response. There is
> also one handler that only cares about consistentId.
> A thing to reflect on: a node might disappear from a physical topology
> because of one of the two reaasons: either network connectivity is lost for
> some time, or a node stopped (maybe as a part of a restart). Do we need to
> account for this difference?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18227) Sql. Support RO transaction by index scan
[ https://issues.apache.org/jira/browse/IGNITE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-18227: -- Assignee: Yury Gerzhedovich > Sql. Support RO transaction by index scan > - > > Key: IGNITE-18227 > URL: https://issues.apache.org/jira/browse/IGNITE-18227 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Looks like integration IndexScanNode and RO transaction is missing. > Let's fill this gap by propagating transaction timestamp to the 'scan' > invocation in IndexScanNode. > TableScanNode may be used as reference. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18293) Fix NullPointerException in IgniteRpcServer
[ https://issues.apache.org/jira/browse/IGNITE-18293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-18293. Resolution: Invalid Not relevant anymore after changes made in IGNITE-18319 > Fix NullPointerException in IgniteRpcServer > --- > > Key: IGNITE-18293 > URL: https://issues.apache.org/jira/browse/IGNITE-18293 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > [16:47:18] : [dotnet test] SEVERE: handleRequest > AppendEntriesRequestImpl [committedIndex=7, data=null, entriesList=null, > groupId=cmg_group, > peerId=org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2, > prevLogIndex=7, prevLogTerm=1, > serverId=org.apache.ignite.internal.runner.app.PlatformTestNodeRunner, > term=1, timestamp=HybridTimestamp [physical=1669726028009, logical=0]] failed > [16:47:18] : [dotnet test] java.lang.NullPointerException > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.send0(DefaultMessagingService.java:146) > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.respond(DefaultMessagingService.java:124) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler$1.sendResponse(IgniteRpcServer.java:183) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor.processRequest0(AppendEntriesRequestProcessor.java:430) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor.processRequest0(AppendEntriesRequestProcessor.java:41) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:195) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.runTask(MpscSingleThreadExecutor.java:354) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.run(MpscSingleThreadExecutor.java:338) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor.lambda$doStartWorker$3(MpscSingleThreadExecutor.java:262) > [16:47:18] : [dotnet test] at > java.base/java.lang.Thread.run(Thread.java:834) > [16:47:18] : [dotnet test] Nov 29, 2022 3:47:18 PM > org.apache.ignite.internal.logger.IgniteLogger warn > [16:47:18] : [dotnet test] WARNING: Caught an unknown error while > executing a task > [16:47:18] : [dotnet test] java.lang.NullPointerException > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.send0(DefaultMessagingService.java:146) > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.respond(DefaultMessagingService.java:124) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler$1.sendResponse(IgniteRpcServer.java:183) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:57) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:195) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.runTask(MpscSingleThreadExecutor.java:354) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.run(MpscSingleThreadExecutor.java:338) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor.lambda$doStartWorker$3(MpscSingleThreadExecutor.java:262) > [16:47:18] : [dotnet test] at > java.base/java.lang.Thread.run(Thread.java:834) -- This
[jira] [Commented] (IGNITE-18293) Fix NullPointerException in IgniteRpcServer
[ https://issues.apache.org/jira/browse/IGNITE-18293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644274#comment-17644274 ] Roman Puchkovskiy commented on IGNITE-18293: A better exception is thrown after changes made in IGNITE-18319 > Fix NullPointerException in IgniteRpcServer > --- > > Key: IGNITE-18293 > URL: https://issues.apache.org/jira/browse/IGNITE-18293 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > [16:47:18] : [dotnet test] SEVERE: handleRequest > AppendEntriesRequestImpl [committedIndex=7, data=null, entriesList=null, > groupId=cmg_group, > peerId=org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2, > prevLogIndex=7, prevLogTerm=1, > serverId=org.apache.ignite.internal.runner.app.PlatformTestNodeRunner, > term=1, timestamp=HybridTimestamp [physical=1669726028009, logical=0]] failed > [16:47:18] : [dotnet test] java.lang.NullPointerException > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.send0(DefaultMessagingService.java:146) > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.respond(DefaultMessagingService.java:124) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler$1.sendResponse(IgniteRpcServer.java:183) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor.processRequest0(AppendEntriesRequestProcessor.java:430) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor.processRequest0(AppendEntriesRequestProcessor.java:41) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:195) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.runTask(MpscSingleThreadExecutor.java:354) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.run(MpscSingleThreadExecutor.java:338) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor.lambda$doStartWorker$3(MpscSingleThreadExecutor.java:262) > [16:47:18] : [dotnet test] at > java.base/java.lang.Thread.run(Thread.java:834) > [16:47:18] : [dotnet test] Nov 29, 2022 3:47:18 PM > org.apache.ignite.internal.logger.IgniteLogger warn > [16:47:18] : [dotnet test] WARNING: Caught an unknown error while > executing a task > [16:47:18] : [dotnet test] java.lang.NullPointerException > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.send0(DefaultMessagingService.java:146) > [16:47:18] : [dotnet test] at > org.apache.ignite.network.DefaultMessagingService.respond(DefaultMessagingService.java:124) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler$1.sendResponse(IgniteRpcServer.java:183) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:57) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:195) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.runTask(MpscSingleThreadExecutor.java:354) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor$Worker.run(MpscSingleThreadExecutor.java:338) > [16:47:18] : [dotnet test] at > org.apache.ignite.raft.jraft.util.concurrent.MpscSingleThreadExecutor.lambda$doStartWorker$3(MpscSingleThreadExecutor.java:262) > [16:47:18] : [dotnet test] at >
[jira] [Commented] (IGNITE-18344) JVM crash dumps are not included in .gitignore
[ https://issues.apache.org/jira/browse/IGNITE-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644271#comment-17644271 ] Roman Puchkovskiy commented on IGNITE-18344: LGTM > JVM crash dumps are not included in .gitignore > -- > > Key: IGNITE-18344 > URL: https://issues.apache.org/jira/browse/IGNITE-18344 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > JVM crash dumps are not ignored -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18085) Implement logical topology events subscription and notification
[ https://issues.apache.org/jira/browse/IGNITE-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644270#comment-17644270 ] Roman Puchkovskiy commented on IGNITE-18085: Thanks! > Implement logical topology events subscription and notification > --- > > Key: IGNITE-18085 > URL: https://issues.apache.org/jira/browse/IGNITE-18085 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > h3. Motivation > There are two types of typologies in Apache Ignite 3 > * Physical(Network) - nodes that are visible through network layer. > * Logical - nodes that successfully passed the join procedure including > local recovery and catch up phases, thus nodes that are ready to handle user > load. More details in IEP-77 > In order to recalculate data nodes for specific distribution zone (see > [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]) > it's required for distribution zone manager to receive notifications about > logical topology updates along with logical topology version similar to ones > we have in network topology: > * onAppeared > * onDisappeared > h3. Definition of Done > * It's possible to register listeners for logical topology > onAppeared/onDisappeared events > * Events are fired in a distributed manner to all recipients. > * Each event produces ClusterNode.consistentId that was either added or > removed and *logical topology version.* It's required to solve ABA problem on > topology events, see https://issues.apache.org/jira/browse/IGNITE-18087 for > more details. > * Events are ordered within each Producer to Recipient communication channel. > * It's valid to have multiple producers, e.g. during CMG leader change, thus > it's valid to send same set of event twice but order still matters. > * It's not valid to skip events, even in case of of CMG leader change. > * Delivery guarantee is required. > * Besides events, there should be a method to get current logical topology > along with topology version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18343) Refactor partition counters API.
[ https://issues.apache.org/jira/browse/IGNITE-18343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-18343: -- Parent: IGNITE-17845 Issue Type: Sub-task (was: Improvement) > Refactor partition counters API. > > > Key: IGNITE-18343 > URL: https://issues.apache.org/jira/browse/IGNITE-18343 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > > The suggestion is to simplify and separate the counters API. > `PartitionUpdateCounter` should be splited into transactional and amotic > ones. Unwrap where neded. Atomic caches have no LWM/HWM and related methods. > The method namings should correspond to the javadocs like lwm()/hwm(). > Also, looks like MVCC couneters might have own implementation. We should > consider transaction model when working and storing the counters. > Suggestions to improve: > 1. Use some separated counter interfaces for atomic and transactional caches. > 2. 'get()' should be renamed to 'lwm()' > 3. 'reserved()' -> 'hwm()' which is probably highestAppliedCounter(). > 'reserved()' is uncertain. It is only for primary node. Do we need it in a > interface? Should be removed. > It is used only in CacheContinuousQueryHandler, see [1]. > 4. Many setters 'update()' / 'update(long start, long delta)' / 'next()' / > 'next(long delta)' / 'reset()' / 'resetInitial()' look over-engineered. > Should be unified. > 5. 'next()' and 'next(long delta)' have wierd implementations in > PartitionUpdateCounterTrackingImpl. 'next(long delta)' doesn't update the > reserved counter. Shoulbe be revised. > 6. Reduce synchronized methods in counters like > 'PartitionUpdateCounterTrackingImpl#reserve(long delta)' > 7. Use same method names in related GridDhtLocalPartition. Not > 'reserved()/reservedCounter()' > Related design doc: > https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > [1] https://issues.apache.org/jira/browse/IGNITE-18281 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18283) Illegal use of dynamic parameter exception on SQL LIKE
[
https://issues.apache.org/jira/browse/IGNITE-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-18283.
Resolution: Duplicate
> Illegal use of dynamic parameter exception on SQL LIKE
> --
>
> Key: IGNITE-18283
> URL: https://issues.apache.org/jira/browse/IGNITE-18283
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> *Query*
> {code}
> select (_T0.VAL like '%' || ? || '%') from PUBLIC.TBL1 as _T0
> {code}
> *Result*
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 33:
> Illegal use of dynamic parameter
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1982)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2064)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2064)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2064)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2064)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:462)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4505)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3710)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:207)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$1(PrepareServiceImpl.java:227)
> {code}
> This query works in Ignite 2.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18344) JVM crash dumps are not included in .gitignore
[ https://issues.apache.org/jira/browse/IGNITE-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18344: --- Description: JVM crash dumps are not ignored (was: JVM crash dumps are also not ignored) > JVM crash dumps are not included in .gitignore > -- > > Key: IGNITE-18344 > URL: https://issues.apache.org/jira/browse/IGNITE-18344 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > JVM crash dumps are not ignored -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-18344) Generated sources are not included in .gitignore
[ https://issues.apache.org/jira/browse/IGNITE-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reopened IGNITE-18344: > Generated sources are not included in .gitignore > > > Key: IGNITE-18344 > URL: https://issues.apache.org/jira/browse/IGNITE-18344 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > JVM crash dumps are also not ignored -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18344) JVM crash dumps are not included in .gitignore
[ https://issues.apache.org/jira/browse/IGNITE-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18344: --- Summary: JVM crash dumps are not included in .gitignore (was: Generated sources are not included in .gitignore) > JVM crash dumps are not included in .gitignore > -- > > Key: IGNITE-18344 > URL: https://issues.apache.org/jira/browse/IGNITE-18344 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > JVM crash dumps are also not ignored -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18221) Filter non-repitable options in interactive suggestions
[ https://issues.apache.org/jira/browse/IGNITE-18221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-18221: -- Assignee: Ivan Gagarkin > Filter non-repitable options in interactive suggestions > --- > > Key: IGNITE-18221 > URL: https://issues.apache.org/jira/browse/IGNITE-18221 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > 'cluster init --cluster-name mycluster ' will display --cluster-name as > a suggested option. If fact, this option could be used only once, so we do > not have to display suggestions with it anymore. > Look through all such options and add them to a special group like > "non-repeatable options". I think 'Options' enum is a good place to put this > info into. > Also, I suggest filtering not only non-repeatable options but short aliases, > too. I don't think the user is happy to see --node-name and -n both at the > same time. I think it is enough to display only long option names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18346) .NET return Ignite version with a wrong timestamp part
[
https://issues.apache.org/jira/browse/IGNITE-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-18346:
-
Description:
The following code reproduces the issue:
{code:c#}
var node = Ignition.Start(cfg);
Console.WriteLine("Version: " + node.GetVersion());
{code}
For version 2.14:
{noformat}
Expected: 2.14.0#20220929-sha1:951e8deb
Actual: 2.14.0#19700102-sha1:951e8deb
{noformat}
was:
The following code reproduces the issue:
{code:c#}
var node = Ignition.Start(cfg);
Console.WriteLine("Version: " + node.GetVersion());
{code}
For version 2.14:
Expected: 2.14.0#20220929-sha1:951e8deb
Actual: 2.14.0#19700102-sha1:951e8deb
> .NET return Ignite version with a wrong timestamp part
> --
>
> Key: IGNITE-18346
> URL: https://issues.apache.org/jira/browse/IGNITE-18346
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.14
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>
> The following code reproduces the issue:
> {code:c#}
> var node = Ignition.Start(cfg);
> Console.WriteLine("Version: " + node.GetVersion());
> {code}
> For version 2.14:
> {noformat}
> Expected: 2.14.0#20220929-sha1:951e8deb
> Actual: 2.14.0#19700102-sha1:951e8deb
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18346) .NET return Ignite version with a wrong timestamp part
[
https://issues.apache.org/jira/browse/IGNITE-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-18346:
-
Description:
The following code reproduces the issue:
{code:c#}
var node = Ignition.Start(cfg);
Console.WriteLine("Version: " + node.GetVersion());
{code}
For version 2.14:
Expected: 2.14.0#20220929-sha1:951e8deb
Actual: 2.14.0#19700102-sha1:951e8deb
was:
The following code reproduces the issue:
{code:dotnet}
var node = Ignition.Start(cfg);
Console.WriteLine("Version: " + node.GetVersion());
{code}
For version 2.14:
Expected: 2.14.0#20220929-sha1:951e8deb
Actual: 2.14.0#19700102-sha1:951e8deb
> .NET return Ignite version with a wrong timestamp part
> --
>
> Key: IGNITE-18346
> URL: https://issues.apache.org/jira/browse/IGNITE-18346
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.14
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>
> The following code reproduces the issue:
> {code:c#}
> var node = Ignition.Start(cfg);
> Console.WriteLine("Version: " + node.GetVersion());
> {code}
> For version 2.14:
> Expected: 2.14.0#20220929-sha1:951e8deb
> Actual: 2.14.0#19700102-sha1:951e8deb
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18346) .NET return Ignite version with a wrong timestamp part
Igor Sapego created IGNITE-18346:
Summary: .NET return Ignite version with a wrong timestamp part
Key: IGNITE-18346
URL: https://issues.apache.org/jira/browse/IGNITE-18346
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.14
Reporter: Igor Sapego
Assignee: Igor Sapego
The following code reproduces the issue:
{code:dotnet}
var node = Ignition.Start(cfg);
Console.WriteLine("Version: " + node.GetVersion());
{code}
For version 2.14:
Expected: 2.14.0#20220929-sha1:951e8deb
Actual: 2.14.0#19700102-sha1:951e8deb
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18345) SQL. Cannot use java Date/Time classes as parameters for query
Yury Gerzhedovich created IGNITE-18345:
--
Summary: SQL. Cannot use java Date/Time classes as parameters for
query
Key: IGNITE-18345
URL: https://issues.apache.org/jira/browse/IGNITE-18345
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
Simple broken scenario looks as
{code:java}
assertQuery("SELECT LAST_DAY(?)").withParams(Date.valueOf("2022-01-01"))
.returns(Date.valueOf("2022-01-31")).check();
{code}
In the case we have the following error:
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:86aeab6a-5aa9-4f4e-a69d-5809e53f60b9 class java.lang.Integer cannot be
cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in
module java.base of loader 'bootstrap')
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18294) Multiple lock intentions support
[ https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-18294: -- Assignee: Vladislav Pyatkov (was: Denis Chudov) > Multiple lock intentions support > > > Key: IGNITE-18294 > URL: https://issues.apache.org/jira/browse/IGNITE-18294 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Current implementation of HeapLockManager relies on waiters that can support > only one lock intention for each transaction at a moment of time. This can > lead to problems like following: > - there are transactions tx1, tx2, tx3 started in corresponding order; > - all txs acquire S-locks; > - tx2 tries to acquire IX-lock, it's incompatible with S-locks from tx1 and > tx3, this is a lock intention and a future is created, which is completed > when SIX-lock is acquired (supremum of S and IX locks) > - tx2 concurrently tries to acquire X-lock, this is another lock intention, > supremum of locks for tx2 is X-lock. The information about previous intention > is lost; > - tx3 is committed, and tx2 waits only for tx1 but it is not allowed to wait > for it due to wait-die deadlock prevention. All lock intentions should be > canceled. > Definition of done: > We have lock mode counters inside of waiter, they should be adapted for lock > intention support. Also, "upgraded" flag of waiters and all the logic related > to "previous lock mode" should be removed. After that, the test scenario > described above should pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
