[jira] [Created] (IGNITE-20538) Thin 3.0: ignite-client uses ignite-core as a public dependency
Pavel Tupitsyn created IGNITE-20538: --- Summary: Thin 3.0: ignite-client uses ignite-core as a public dependency Key: IGNITE-20538 URL: https://issues.apache.org/jira/browse/IGNITE-20538 Project: Ignite Issue Type: Bug 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-20538) Thin 3.0: ignite-client uses ignite-core as a public dependency
[
https://issues.apache.org/jira/browse/IGNITE-20538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20538:
Description:
1. Change *ignite-client* dependency from *api project(':ignite-core')* to
*implementation project(':ignite-core')*
2. Move related classes to *ignite-api* module (logger, etc)
> Thin 3.0: ignite-client uses ignite-core as a public dependency
> ---
>
> Key: IGNITE-20538
> URL: https://issues.apache.org/jira/browse/IGNITE-20538
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. Change *ignite-client* dependency from *api project(':ignite-core')* to
> *implementation project(':ignite-core')*
> 2. Move related classes to *ignite-api* module (logger, etc)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20537) Add ability to create implicit transactions
[
https://issues.apache.org/jira/browse/IGNITE-20537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771353#comment-17771353
]
Vladislav Pyatkov commented on IGNITE-20537:
The patch looked good to me.
> Add ability to create implicit transactions
> ---
>
> Key: IGNITE-20537
> URL: https://issues.apache.org/jira/browse/IGNITE-20537
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, implicit transactions are created in {{{}InternalTableImpl{}}}.
> where the code knows whether it created the transaction itself or not. To
> correctly support schema synchronization, we need to create implicit
> transactions higher, in {{RecordBinaryViewImpl}} and other table views (if no
> transaction was provided), because transaction is used to obtain a timestamp
> used for schema sync.
> Such transactions will be created before the code in {{InternalTableImpl}}
> that will use them, so {{implicit()}} method is to be added to
> {{{}InternalTransaction{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20539) Unify creation of implicit transactions
Roman Puchkovskiy created IGNITE-20539:
--
Summary: Unify creation of implicit transactions
Key: IGNITE-20539
URL: https://issues.apache.org/jira/browse/IGNITE-20539
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
In IGNITE-20537, `implicit()` flag is added to {{{}InternalTransaction{}}}. On
the other hand, in {{SqlProcessor}} the {{implicit}} flag is defined on a
special wrapper ( {{QueryTransactionWrapper}} ). It seems we should align the
approaches.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20540) Document configuring logging in AI3
Vyacheslav Koptilin created IGNITE-20540:
Summary: Document configuring logging in AI3
Key: IGNITE-20540
URL: https://issues.apache.org/jira/browse/IGNITE-20540
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Vyacheslav Koptilin
Need to provide all required information to properly configure logging on the
client side.
{noformat}
*no* further _formatting_ is done here{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20540) Document configuring logging in AI3
[
https://issues.apache.org/jira/browse/IGNITE-20540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20540:
-
Description:
Need to provide all required information to properly configure logging on the
client side.
JUL:
- SLF4J JDK14 Provider should be added to the classpath -
org.slf4j:slf4j-jdk14:2.0.x
- configuration file can be specified via `java.util.logging.config.file`
property
additional details can be found here:
[https://docs.oracle.com/en/java/javase/11/core/java-logging-overview.html#GUID-B83B652C-17EA-48D9-93D2-563AE1FF8EDA]
LOG4J2:
- SLF4J Provider should be added to the classpath -
org.apache.logging.log4j:log4j-slf4j2-impl:2.x.x (2.20.0 or higher, for example)
- LOG4J2 API and implementation: org.apache.logging.log4j:log4j-api:2.x.x,
org.apache.logging.log4j:log4j-core:2.x.x
- LOG4J2 bridge: org.apache.logging.log4j:log4j-jpl:2.x.x
- configuration can be done via the properties file. additional details can be
found here [https://logging.apache.org/log4j/2.x/manual/configuration.html]
was:
Need to provide all required information to properly configure logging on the
client side.
{noformat}
*no* further _formatting_ is done here{noformat}
> Document configuring logging in AI3
> ---
>
> Key: IGNITE-20540
> URL: https://issues.apache.org/jira/browse/IGNITE-20540
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Need to provide all required information to properly configure logging on the
> client side.
> JUL:
> - SLF4J JDK14 Provider should be added to the classpath -
> org.slf4j:slf4j-jdk14:2.0.x
> - configuration file can be specified via `java.util.logging.config.file`
> property
> additional details can be found here:
> [https://docs.oracle.com/en/java/javase/11/core/java-logging-overview.html#GUID-B83B652C-17EA-48D9-93D2-563AE1FF8EDA]
> LOG4J2:
> - SLF4J Provider should be added to the classpath -
> org.apache.logging.log4j:log4j-slf4j2-impl:2.x.x (2.20.0 or higher, for
> example)
> - LOG4J2 API and implementation: org.apache.logging.log4j:log4j-api:2.x.x,
> org.apache.logging.log4j:log4j-core:2.x.x
> - LOG4J2 bridge: org.apache.logging.log4j:log4j-jpl:2.x.x
> - configuration can be done via the properties file. additional details can
> be found here [https://logging.apache.org/log4j/2.x/manual/configuration.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20457) Verify commitTimestamp against enlisted partitions expiration timestamps
[ https://issues.apache.org/jira/browse/IGNITE-20457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20457: - Description: On tx commit It’s required to check that commit timestamp is less than expiration timestamps for all enlisted partitions (was: On tx commit It’s required to check that commit timestamp is less than expiration timestamps for all enlisted partitions.) > Verify commitTimestamp against enlisted partitions expiration timestamps > > > Key: IGNITE-20457 > URL: https://issues.apache.org/jira/browse/IGNITE-20457 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Blocker > Labels: ignite-3, tech-debt > > On tx commit It’s required to check that commit timestamp is less than > expiration timestamps for all enlisted partitions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20435) Preserve key order in InternalTableImpl#deleteAll
[ https://issues.apache.org/jira/browse/IGNITE-20435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20435: - Description: The IGNITE-16004 fixed ordering for the most multi key methods but not for the removeAll methods. For example, removeAll(1, 2, 3) should return 1, 3 if a value for 1 and 3 doesn't exists, but in practice this order may be broken was: The IGNITE-16004 fixed ordering for the most multi key methods but not for the removeAll methods. For example, removeAll(1, 2, 3) should return 1, 3 if a value for 1 and 3 doesn't exists, but in practice this order may be broken. > Preserve key order in InternalTableImpl#deleteAll > - > > Key: IGNITE-20435 > URL: https://issues.apache.org/jira/browse/IGNITE-20435 > Project: Ignite > Issue Type: Bug >Reporter: Igor Sapego >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > The IGNITE-16004 fixed ordering for the most multi key methods but not for > the removeAll methods. > For example, removeAll(1, 2, 3) should return 1, 3 if a value for 1 and 3 > doesn't exists, but in practice this order may be broken -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19824) Implicit RO should be used in implicit single gets
[
https://issues.apache.org/jira/browse/IGNITE-19824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19824:
-
Description:
h3. Motivation
Currently, all implicit read operations start RW transactions, thus it's
possible to catch "Failed to acquire a lock due to a conflict" exception.
Generally speaking, given issue should be resolved by substituting RW with RO
for all implicit read transactions, however such approach will decrease
linearizability so it's required to verify it with product management. It's
still however possible to have special case RO for implicit single-key get
operation that will set readTimestamp on primary replica instead of transaction
coordinator and thus provide cluster-wide linearizability even for RO
transactions (only for single-key implicit get operations). Within this ticket,
such special RO transactions should be introduced along with their usage switch
for single-get implicit reads.
h3. Definition of Done
* Implicit single-get operations use special RO transactions that provide
cluster-wide linearizability and thus do not throw "Failed to acquire a lock
due to a conflict" exception.
* ItAbstractDataStreamerTest#testAutoFlushByTimer adjusted: catch block
removed.
h3. Implementation Notes
1. Basically, what we need to do here is to start RO transaction instead of RW
one in case of single-key implicit get, thus we should add
{code:java}
if (tx == null) {
tx = txManager.begin(true);
}{code}
right in front of
{code:java}
return enlistInTx({code}
Please pay attention, that we want to start special case RO transaction that
should go to primary and only primary, so it's not valid to put aforementioned
tx = txManager.begin(true); at the very beginning of the method, because in
that case balancer may return non-primary through
evaluateReadOnlyRecipientNode. Corresponging comment should be added.
2. Such specifal case RO transcation doesn't require readTimestamp calcualtion
on tx.start for the evaluation point of view, however it still required it for
lowWatermark managerment:
{code:java}
readOnlyTxFutureById.compute(new TxIdAndTimestamp(readTimestamp, txId),
(txIdAndTimestamp, readOnlyTxFuture) -> {
assert readOnlyTxFuture == null : "previous transaction has not completed
yet: " + txIdAndTimestamp;
if (lowWatermark != null && readTimestamp.compareTo(lowWatermark) <= 0) {
throw new IgniteInternalException(
TX_READ_ONLY_TOO_OLD_ERR,
"Timestamp read-only transaction must be greater than the low
watermark: [txTimestamp={}, lowWatermark={}]",
readTimestamp, lowWatermark
);
}
return new CompletableFuture<>();
}); {code}
So, seems that it worth to leave readTimestamp generatoin at it's current place.
3. And again in order to have cluster-wide linearizability it's requried to use
primaryReplica now as readTimestamp instead of the one proposed in
readOnlyReplicaRequest. Basically that means substitution of
{code:java}
HybridTimestamp readTimestamp = request.readTimestamp(); {code}
with
{code:java}
HybridTimestamp readTimestamp;
if (request.requestType() == RequestType.RO_GET && request.implicit()) {
readTimestamp = hybridClock.now();
} else {
readTimestamp = request.readTimestamp();
} {code}
along with
{code:java}
CompletableFuture safeReadFuture = isPrimaryInTimestamp(isPrimary,
readTimestamp) ? completedFuture(null)
: safeTime.waitFor(readTimestamp); {code}
in PartitionReplicaListnener. That on its part required adding implicit() to
ReadOnlySingleRowReplicaRequest that should be properly set on the client side.
4. That specific operation type should also include a timestamp in the response
(using TimestampAware). It is necessary to use the timestmp to adjust the clock
on the transaction coordinator (despite the fact that we are talking about a
single-get operation, it is a transaction, and the node that invoked the
operation is called a transaction coordinator). Then we can use clock.now() to
update the observation timestamp.
was:
h3. Motivation
Currently, all implicit read operations start RW transactions, thus it's
possible to catch "Failed to acquire a lock due to a conflict" exception.
Generally speaking, given issue should be resolved by substituting RW with RO
for all implicit read transactions, however such approach will decrease
linearizability so it's required to verify it with product management. It's
still however possible to have special case RO for implicit single-key get
operation that will set readTimestamp on primary replica instead of transaction
coordinator and thus provide cluster-wide linearizability even for RO
transactions (only for single-key implicit get operations). Within this ticket,
such special RO transactions should be introduced along with their usage switch
for single-get implicit reads.
h3. Definition of D
[jira] [Updated] (IGNITE-20541) Watch Processor performs unnecessary work in case of empty events
[ https://issues.apache.org/jira/browse/IGNITE-20541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20541: - Ignite Flags: (was: Docs Required,Release Notes Required) > Watch Processor performs unnecessary work in case of empty events > - > > Key: IGNITE-20541 > URL: https://issues.apache.org/jira/browse/IGNITE-20541 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20541) Watch Processor performs unnecessary work in case of empty events
[ https://issues.apache.org/jira/browse/IGNITE-20541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20541: - Labels: ignite-3 (was: ) > Watch Processor performs unnecessary work in case of empty events > - > > Key: IGNITE-20541 > URL: https://issues.apache.org/jira/browse/IGNITE-20541 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20541) Watch Processor performs unnecessary work in case of empty events
Aleksandr Polovtcev created IGNITE-20541: Summary: Watch Processor performs unnecessary work in case of empty events Key: IGNITE-20541 URL: https://issues.apache.org/jira/browse/IGNITE-20541 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20541) Watch Processor performs unnecessary work in case of empty events
[ https://issues.apache.org/jira/browse/IGNITE-20541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20541: - Description: If a Meta Storage event does not match any of the Watch Listeners, Watch Processor creates a bunch of empty futures for no reason, we can simply skip such events. > Watch Processor performs unnecessary work in case of empty events > - > > Key: IGNITE-20541 > URL: https://issues.apache.org/jira/browse/IGNITE-20541 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > If a Meta Storage event does not match any of the Watch Listeners, Watch > Processor creates a bunch of empty futures for no reason, we can simply skip > such events. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20315) Add support for renaming a table column
[ https://issues.apache.org/jira/browse/IGNITE-20315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20315: - Epic Link: IGNITE-19492 (was: IGNITE-20473) > Add support for renaming a table column > --- > > Key: IGNITE-20315 > URL: https://issues.apache.org/jira/browse/IGNITE-20315 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > At the moment there are tests for renaming table columns, but this function > is not supported in the catalog and SQL, I think it needs to be fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20542) Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml
Alexander Belyak created IGNITE-20542: - Summary: Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml Key: IGNITE-20542 URL: https://issues.apache.org/jira/browse/IGNITE-20542 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Alexander Belyak [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page contains broken link to the [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20542) Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml
[ https://issues.apache.org/jira/browse/IGNITE-20542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20542: -- Description: [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page contains broken link to the [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] Correct one seems to be [openapi.yaml|https://github.com/apache/ignite-3/blob/main/modules/rest-api/openapi/openapi.yaml] (was: [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page contains broken link to the [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml]) > Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml > -- > > Key: IGNITE-20542 > URL: https://issues.apache.org/jira/browse/IGNITE-20542 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > Labels: ignite-3 > > [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page > contains broken link to the > [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] > Correct one seems to be > [openapi.yaml|https://github.com/apache/ignite-3/blob/main/modules/rest-api/openapi/openapi.yaml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20537) Add ability to create implicit transactions
[
https://issues.apache.org/jira/browse/IGNITE-20537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771385#comment-17771385
]
Vladislav Pyatkov commented on IGNITE-20537:
Merged 192ea0ed31271ea99f18f9e50aad3a7839c3ed14
> Add ability to create implicit transactions
> ---
>
> Key: IGNITE-20537
> URL: https://issues.apache.org/jira/browse/IGNITE-20537
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, implicit transactions are created in {{{}InternalTableImpl{}}}.
> where the code knows whether it created the transaction itself or not. To
> correctly support schema synchronization, we need to create implicit
> transactions higher, in {{RecordBinaryViewImpl}} and other table views (if no
> transaction was provided), because transaction is used to obtain a timestamp
> used for schema sync.
> Such transactions will be created before the code in {{InternalTableImpl}}
> that will use them, so {{implicit()}} method is to be added to
> {{{}InternalTransaction{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20537) Add ability to create implicit transactions
[
https://issues.apache.org/jira/browse/IGNITE-20537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771388#comment-17771388
]
Roman Puchkovskiy commented on IGNITE-20537:
Thanks!
> Add ability to create implicit transactions
> ---
>
> Key: IGNITE-20537
> URL: https://issues.apache.org/jira/browse/IGNITE-20537
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, implicit transactions are created in {{{}InternalTableImpl{}}}.
> where the code knows whether it created the transaction itself or not. To
> correctly support schema synchronization, we need to create implicit
> transactions higher, in {{RecordBinaryViewImpl}} and other table views (if no
> transaction was provided), because transaction is used to obtain a timestamp
> used for schema sync.
> Such transactions will be created before the code in {{InternalTableImpl}}
> that will use them, so {{implicit()}} method is to be added to
> {{{}InternalTransaction{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20543) CacheStoreFactory should be invoked within sandbox
Maksim Timonin created IGNITE-20543: --- Summary: CacheStoreFactory should be invoked within sandbox Key: IGNITE-20543 URL: https://issues.apache.org/jira/browse/IGNITE-20543 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20543) CacheStoreFactory should be invoked within sandbox
[ https://issues.apache.org/jira/browse/IGNITE-20543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin reassigned IGNITE-20543: --- Assignee: Maksim Timonin > CacheStoreFactory should be invoked within sandbox > -- > > Key: IGNITE-20543 > URL: https://issues.apache.org/jira/browse/IGNITE-20543 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20543) CacheStoreFactory should be invoked within sandbox
[ https://issues.apache.org/jira/browse/IGNITE-20543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-20543: Fix Version/s: 2.16 > CacheStoreFactory should be invoked within sandbox > -- > > Key: IGNITE-20543 > URL: https://issues.apache.org/jira/browse/IGNITE-20543 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20523) .NET: Thin 3.0: ArgumentNullException.ThrowIfNull allocates on value types
[
https://issues.apache.org/jira/browse/IGNITE-20523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20523:
Description:
IGNITE-20479 replaced custom null checks with standard
*ArgumentNullException.ThrowIfNull*. However, *ThrowIfNull* takes *object*,
which involves boxing for value types. Therefore we do heap allocations just to
validate arguments in some cases, such as generic record/key/value validation
in *KeyValueView* and *RecordView*. Bring back the custom generic validation
method to fix this.
Also, *ToKv* method validates the wrong thing twice:
{code}
private static KvPair ToKv(KeyValuePair x)
{
ArgumentNullException.ThrowIfNull(x);
ArgumentNullException.ThrowIfNull(x);
return new(x.Key, x.Value);
}
{code}
was:
IGNITE-20479 replaced custom null checks with standard
*ArgumentNullException.ThrowIfNull*. However, *ThrowIfNull* takes *object*,
which involves boxing for value types. Therefore we do heap allocations just to
validate arguments in some cases, such as generic record/key/value validation
in *KeyValueView* and *RecordView*. Bring back the custom generic validation
method to fix this.
Also, *ToKv* method validates the wrong thing twice:
{code}
ArgumentNullException.ThrowIfNull(x);
ArgumentNullException.ThrowIfNull(x);
{code}
> .NET: Thin 3.0: ArgumentNullException.ThrowIfNull allocates on value types
> --
>
> Key: IGNITE-20523
> URL: https://issues.apache.org/jira/browse/IGNITE-20523
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-20479 replaced custom null checks with standard
> *ArgumentNullException.ThrowIfNull*. However, *ThrowIfNull* takes *object*,
> which involves boxing for value types. Therefore we do heap allocations just
> to validate arguments in some cases, such as generic record/key/value
> validation in *KeyValueView* and *RecordView*. Bring back the custom generic
> validation method to fix this.
> Also, *ToKv* method validates the wrong thing twice:
> {code}
> private static KvPair ToKv(KeyValuePair x)
> {
> ArgumentNullException.ThrowIfNull(x);
> ArgumentNullException.ThrowIfNull(x);
> return new(x.Key, x.Value);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20523) .NET: Thin 3.0: ArgumentNullException.ThrowIfNull allocates on value types
[
https://issues.apache.org/jira/browse/IGNITE-20523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20523:
Description:
IGNITE-20479 replaced custom null checks with standard
*ArgumentNullException.ThrowIfNull*. However, *ThrowIfNull* takes *object*,
which involves boxing for value types. Therefore we do heap allocations just to
validate arguments in some cases, such as generic record/key/value validation
in *KeyValueView* and *RecordView*. Bring back the custom generic validation
method to fix this.
Also, *ToKv* method validates the wrong thing twice:
{code}
ArgumentNullException.ThrowIfNull(x);
ArgumentNullException.ThrowIfNull(x);
{code}
was:
IGNITE-20479 replaced custom null checks with standard
*ArgumentNullException.ThrowIfNull*. However, *ThrowIfNull* takes *object*,
which involves boxing for value types. Therefore we do heap allocations just to
validate arguments in some cases, such as generic record/key/value validation
in *KeyValueView* and *RecordView*. Bring back the custom generic validation
method to fix this.
> .NET: Thin 3.0: ArgumentNullException.ThrowIfNull allocates on value types
> --
>
> Key: IGNITE-20523
> URL: https://issues.apache.org/jira/browse/IGNITE-20523
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-20479 replaced custom null checks with standard
> *ArgumentNullException.ThrowIfNull*. However, *ThrowIfNull* takes *object*,
> which involves boxing for value types. Therefore we do heap allocations just
> to validate arguments in some cases, such as generic record/key/value
> validation in *KeyValueView* and *RecordView*. Bring back the custom generic
> validation method to fix this.
> Also, *ToKv* method validates the wrong thing twice:
> {code}
> ArgumentNullException.ThrowIfNull(x);
> ArgumentNullException.ThrowIfNull(x);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20520) Specify schema version when getting table before query execution
[
https://issues.apache.org/jira/browse/IGNITE-20520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20520:
-
Description: {{ExecutableTableRegistryImpl#loadTable()}} obtains
{{SchemaDescriptor}} using the '{_}latest{_}' semantics, but the version of the
table it's loading is known, so it should be used to get a specific descriptor
with the given table version, not the latest one. (was:
{{ExecutableTableRegistryImpl#loadTable()}} obtains {{SchemaDescriptor}} using
the 'latest' semantics, but the version of the table it's loading is known, so
it should be used to get a specific descriptor with the given table version,
not the latest one.)
> Specify schema version when getting table before query execution
>
>
> Key: IGNITE-20520
> URL: https://issues.apache.org/jira/browse/IGNITE-20520
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ExecutableTableRegistryImpl#loadTable()}} obtains {{SchemaDescriptor}}
> using the '{_}latest{_}' semantics, but the version of the table it's loading
> is known, so it should be used to get a specific descriptor with the given
> table version, not the latest one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-12835) Thin client: compute support
[ https://issues.apache.org/jira/browse/IGNITE-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12835: Attachment: Thin client_ compute support.eml > Thin client: compute support > > > Key: IGNITE-12835 > URL: https://issues.apache.org/jira/browse/IGNITE-12835 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-42, important > Fix For: 2.9 > > Attachments: Thin client_ compute support.eml > > Time Spent: 3h > Remaining Estimate: 0h > > Add compute grid functionality to thin clients. > As a first step execution of task by task name should be added. > Implement a compute facade in java thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20508) DeadlockDetectionManager removal
[ https://issues.apache.org/jira/browse/IGNITE-20508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20508: -- Fix Version/s: 2.16 > DeadlockDetectionManager removal > > > Key: IGNITE-20508 > URL: https://issues.apache.org/jira/browse/IGNITE-20508 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20544) Implement the start of building indexes on node recovery
Kirill Tkalenko created IGNITE-20544: Summary: Implement the start of building indexes on node recovery Key: IGNITE-20544 URL: https://issues.apache.org/jira/browse/IGNITE-20544 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko After the node is restored, a change of leaseholders may not occur (a prolongation will occur), thus we may end up in a situation where build index will not be completed before the change of leaseholders. It is important for us to start building indexes on recovery only after the partition has been restored (after applying the raft log). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15556: -- Fix Version/s: 3.0.0-beta2 > Drop SchemaBuilder API. > --- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > Drop SchemaBuilders API as schema manupulation will be available only via SQL -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15556) Drop SchemaBuilder API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15556: - Assignee: Andrey Mashenkov > Drop SchemaBuilder API. > --- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3, tech-debt > > Drop SchemaBuilders API as schema manupulation will be available only via SQL -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20500) NullPointerException when restarting node with custom region
[
https://issues.apache.org/jira/browse/IGNITE-20500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20500:
-
Labels: ignite-3 (was: )
> NullPointerException when restarting node with custom region
>
>
> Key: IGNITE-20500
> URL: https://issues.apache.org/jira/browse/IGNITE-20500
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Tiago Marques Godinho
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: assert, full
>
>
> I've encountered this exception when restarting a node with data on a custom
> region:
> {code:java}
> SEVERE: Error starting tables
> ...
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryTableStorage.ensurePartitionFilePageStoreExists(PersistentPageMemoryTableStorage.java:144)
> at
> org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryTableStorage.getOrCreatePartitionMetaOnCreatePartition(PersistentPageMemoryTableStorage.java:500)
> at
> org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryTableStorage.createMvPartitionStorage(PersistentPageMemoryTableStorage.java:107)
> at
> org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryTableStorage.createMvPartitionStorage(PersistentPageMemoryTableStorage.java:54)
> at
> org.apache.ignite.internal.storage.pagememory.AbstractPageMemoryTableStorage.lambda$createMvPartition$4(AbstractPageMemoryTableStorage.java:164)
> at
> org.apache.ignite.internal.storage.util.MvPartitionStorages.lambda$create$1(MvPartitionStorages.java:121)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> ... 44 more {code}
>
> Steps to reproduce:
> # Start a cluster from scratch (can be a single node).
> # Initialise the cluster.
> # Update the cluster configurations with a custom region:
> {code:java}
> {"aipersist":{"regions":[{"memoryAllocator":{"type":"unsafe"},"name":"persistentDataRegionCfg","replacementMode":"CLOCK","size":6871947673}]}}{code}
> # Create a Distribution Zone on that data region:
> {code:java}
> CREATE ZONE MY_ZONE ENGINE aipersist WITH
> DATAREGION='persistentDataRegionCfg', REPLICAS=1;{code}
> # Shutdown the node using SIGINT
> # Start the node again
> Tested with:
> [d7970190|https://github.com/apache/ignite-3/commit/d7970190a48b999d0adddfd5906d691b050576d2]
> Notes:
> * Added [^full]
> * Added [^assert] when assertions where enabled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20527) Main compilation issue
[
https://issues.apache.org/jira/browse/IGNITE-20527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20527:
-
Labels: ignite-3 (was: )
> Main compilation issue
> --
>
> Key: IGNITE-20527
> URL: https://issues.apache.org/jira/browse/IGNITE-20527
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#1d1c1d}opt/buildagent/work/f768947ecdf9fa34/var/ignite3/modules/table/src/main/java/org/apache/ignite/internal/table/distributed/replicator/PartitionReplicaListener.java:1260:
> error: method awaitPrimaryReplica in interface PlacementDriver cannot be
> applied to given types;{color}
> {color:#1d1c1d} return
> placementDriver.awaitPrimaryReplica(partitionId, now){color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18942) Reactor library version conflict
[ https://issues.apache.org/jira/browse/IGNITE-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18942: --- Description: Scalecube and Micronaut use different versions of the Reactor library: 3.5.0 and 3.4.9, respectively. Currently, Gradle is using the newer version. However, we may need to consider shadowing one of the versions to avoid conflicts. This issue must be resolved before the GA release. [https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r] was: Scalecube and Micraonaut use different versions of the Reactor library - 3.5.0 and 3.4.9. Right now gradle uses the new one. But maybe it's worth shadowing one of them to avoid that conflict. We have to think and resolve it till the GA. https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r > Reactor library version conflict > > > Key: IGNITE-18942 > URL: https://issues.apache.org/jira/browse/IGNITE-18942 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Scalecube and Micronaut use different versions of the Reactor library: 3.5.0 > and 3.4.9, respectively. > Currently, Gradle is using the newer version. > However, we may need to consider shadowing one of the versions to avoid > conflicts. > This issue must be resolved before the GA release. > [https://lists.apache.org/thread/msh2q0g121lhcxmvdx15ks353dv03j4r] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20096) Fix building indexes after switch to Catalog
[ https://issues.apache.org/jira/browse/IGNITE-20096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-20096: Assignee: (was: Kirill Tkalenko) > Fix building indexes after switch to Catalog > > > Key: IGNITE-20096 > URL: https://issues.apache.org/jira/browse/IGNITE-20096 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When switch the *IndexManager* to the Catalog, a number of problems are > revealed, one of them is the building of indexes, it is proposed to solve > this problem separately so that the switch is smoother. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20096) Fix building indexes after switch to Catalog
[ https://issues.apache.org/jira/browse/IGNITE-20096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-20096: Assignee: Kirill Tkalenko > Fix building indexes after switch to Catalog > > > Key: IGNITE-20096 > URL: https://issues.apache.org/jira/browse/IGNITE-20096 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When switch the *IndexManager* to the Catalog, a number of problems are > revealed, one of them is the building of indexes, it is proposed to solve > this problem separately so that the switch is smoother. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20096) Fix building indexes after switch to Catalog
[ https://issues.apache.org/jira/browse/IGNITE-20096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-20096. -- Resolution: Duplicate > Fix building indexes after switch to Catalog > > > Key: IGNITE-20096 > URL: https://issues.apache.org/jira/browse/IGNITE-20096 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When switch the *IndexManager* to the Catalog, a number of problems are > revealed, one of them is the building of indexes, it is proposed to solve > this problem separately so that the switch is smoother. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20545) Test IgniteRpcTest.testDisconnect is flaky on TC
Sergey Chugunov created IGNITE-20545: Summary: Test IgniteRpcTest.testDisconnect is flaky on TC Key: IGNITE-20545 URL: https://issues.apache.org/jira/browse/IGNITE-20545 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Test failed recently on main branch ([failed run|https://ci.ignite.apache.org/viewLog.html?buildId=7536503&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests]), there is an assertion in test logs: org.opentest4j.AssertionFailedError: expected: but was: at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at app//org.apache.ignite.raft.jraft.rpc.AbstractRpcTest.testDisconnect(AbstractRpcTest.java:128) Test history shows that it fails occasionally in different branches with the same error in logs. Looks like there is some kind of race between events in test logic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20472) API to consumer cache dumps
[
https://issues.apache.org/jira/browse/IGNITE-20472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771477#comment-17771477
]
Ignite TC Bot commented on IGNITE-20472:
{panel:title=Branch: [pull/10953/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10953/head] Base: [master] : New Tests
(308)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
153|https://ci2.ignite.apache.org/viewLog.html?buildId=7360976]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteCacheDumpSelf2Test.testCheckOnEmptyNode - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteCacheDumpSelf2Test.testCheckFailOnCorruptedData - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=true,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=TRANSACTIONAL]
- PASSED{color}
... and 142 new tests
{color:#8b}Snapshots{color} [[tests
153|https://ci2.ignite.apache.org/viewLog.html?buildId=7360959]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteCacheDumpSelf2Test.testCheckOnEmptyNode - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteCacheDumpSelf2Test.testCheckFailOnCorruptedData - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=TRANSACTIONAL]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=ATOMIC]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=TRANSACTIONAL]
- PASSED{color}
... and 142 new tests
{color:#8b}Queries 3{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7361001]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
DumpCacheConfigTest.testSQLTableDump - PASSED{color}
{color:#8b}Queries 3 (lazy=true){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7361003]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
DumpCacheConfigTest.testSQLTableDump - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7360
[jira] [Resolved] (IGNITE-18606) Switch to Java 17
[ https://issues.apache.org/jira/browse/IGNITE-18606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-18606. Resolution: Won't Fix > Switch to Java 17 > - > > Key: IGNITE-18606 > URL: https://issues.apache.org/jira/browse/IGNITE-18606 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20098) Move exception classes related to distribution zones to an appropriate package/module
[ https://issues.apache.org/jira/browse/IGNITE-20098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20098: - Description: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException It seems to me, that this is not correct way to handle dependencies between `catalog` and `distribution zone` modules. All exceptions should be was: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException > Move exception classes related to distribution zones to an appropriate > package/module > - > > Key: IGNITE-20098 > URL: https://issues.apache.org/jira/browse/IGNITE-20098 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > The following exceptions classes were moved to the `core` module due to > CatalogService feature: > - DistributionZoneNotFoundException > - DistributionZoneBindTableException > - DistributionZoneAlreadyExistsException > It seems to me, that this is not correct way to handle dependencies between > `catalog` and `distribution zone` modules. All exceptions should be -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20098) Move exception classes related to distribution zones to an appropriate package/module
[ https://issues.apache.org/jira/browse/IGNITE-20098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20098: - Description: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException > Move exception classes related to distribution zones to an appropriate > package/module > - > > Key: IGNITE-20098 > URL: https://issues.apache.org/jira/browse/IGNITE-20098 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > The following exceptions classes were moved to the `core` module due to > CatalogService feature: > - DistributionZoneNotFoundException > - DistributionZoneBindTableException > - DistributionZoneAlreadyExistsException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20098) Move exception classes related to distribution zones to an appropriate package/module
[ https://issues.apache.org/jira/browse/IGNITE-20098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20098: - Description: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException It seems to me, that this is not the correct way to handle dependencies between `catalog` and `distribution zone` modules. All exceptions should be moved to the one place. IMHO, it should be the `distribution zone` module. was: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException It seems to me, that this is not correct way to handle dependencies between `catalog` and `distribution zone` modules. All exceptions should be > Move exception classes related to distribution zones to an appropriate > package/module > - > > Key: IGNITE-20098 > URL: https://issues.apache.org/jira/browse/IGNITE-20098 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > The following exceptions classes were moved to the `core` module due to > CatalogService feature: > - DistributionZoneNotFoundException > - DistributionZoneBindTableException > - DistributionZoneAlreadyExistsException > It seems to me, that this is not the correct way to handle dependencies > between `catalog` and `distribution zone` modules. All exceptions should be > moved to the one place. IMHO, it should be the `distribution zone` module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20546) Entries aren't expired while re-inserting with SQL
Maksim Timonin created IGNITE-20546: --- Summary: Entries aren't expired while re-inserting with SQL Key: IGNITE-20546 URL: https://issues.apache.org/jira/browse/IGNITE-20546 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin Fix For: 2.16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20470) Ducktape to check dump performance
[ https://issues.apache.org/jira/browse/IGNITE-20470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-20470: Assignee: Sergey Korotkov > Ducktape to check dump performance > -- > > Key: IGNITE-20470 > URL: https://issues.apache.org/jira/browse/IGNITE-20470 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Sergey Korotkov >Priority: Major > Labels: IEP-109, ise > > Dump creation can affect transactions performance with change listener and > disc operations. We must create ducktape test to check this. > Example test scenario: > * Start nodes > * Start transaction operations: insert, update, remove. > * Create dump > * Check dump consistency. > Measure > * Transaction performance penalty. > * GC utilization. > * Disc utilization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20547) Core Mapping API
Mikhail Pochatkin created IGNITE-20547: -- Summary: Core Mapping API Key: IGNITE-20547 URL: https://issues.apache.org/jira/browse/IGNITE-20547 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin Create base interface with default implementation based on GSON library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20548) Modify Compute server API for optional mapper
Mikhail Pochatkin created IGNITE-20548: -- Summary: Modify Compute server API for optional mapper Key: IGNITE-20548 URL: https://issues.apache.org/jira/browse/IGNITE-20548 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20549) Modify Java Client for mapper providing
Mikhail Pochatkin created IGNITE-20549: -- Summary: Modify Java Client for mapper providing Key: IGNITE-20549 URL: https://issues.apache.org/jira/browse/IGNITE-20549 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20550) Modify C# client compute API for mapping
Mikhail Pochatkin created IGNITE-20550: -- Summary: Modify C# client compute API for mapping Key: IGNITE-20550 URL: https://issues.apache.org/jira/browse/IGNITE-20550 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20551) Modify C++ client compute API for mapping
Mikhail Pochatkin created IGNITE-20551: -- Summary: Modify C++ client compute API for mapping Key: IGNITE-20551 URL: https://issues.apache.org/jira/browse/IGNITE-20551 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20538) Thin 3.0: ignite-client uses ignite-core as a public dependency
[
https://issues.apache.org/jira/browse/IGNITE-20538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771499#comment-17771499
]
Pavel Tupitsyn commented on IGNITE-20538:
-
Merged to main: 453eb7eb2c04bf380b3551117e0b368659a9b6b8
> Thin 3.0: ignite-client uses ignite-core as a public dependency
> ---
>
> Key: IGNITE-20538
> URL: https://issues.apache.org/jira/browse/IGNITE-20538
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 1. Change *ignite-client* dependency from *api project(':ignite-core')* to
> *implementation project(':ignite-core')*
> 2. Move related classes to *ignite-api* module (logger, etc)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20526) JDBC2 (thin client) throws IllegalMonitorStateException if property ignite.jdbc.nodeId is filled
[
https://issues.apache.org/jira/browse/IGNITE-20526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-20526:
Summary: JDBC2 (thin client) throws IllegalMonitorStateException if
property ignite.jdbc.nodeId is filled (was: JDBC2 (thin client) throws
IllegalMonitorStateException if property ignite.jdbc..nodeId is filled)
> JDBC2 (thin client) throws IllegalMonitorStateException if property
> ignite.jdbc.nodeId is filled
>
>
> Key: IGNITE-20526
> URL: https://issues.apache.org/jira/browse/IGNITE-20526
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.15
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Attachments: JdbcComplexQuerySelfTest.java
>
>
> Any sql query with non empty resultset will throw exception, if jdbc2 (thin)
> is used and operates under REPLICATED caches:
> {noformat}
> Caused by: java.lang.IllegalMonitorStateException: attempt to unlock read
> lock, not locked by current thread
> at
> java.base/java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:448)
> at
> java.base/java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:432)
> at
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1382)
> at
> java.base/java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:897)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.unlock(GridH2Table.java:566)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.unlockReadInternal(GridH2Table.java:510)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.unlockTables(GridH2Table.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.H2ResultSetIterator.unlockTables(H2ResultSetIterator.java:267)
> {noformat}
> Step to reproduce, take for example existing
> JdbcComplexQuerySelfTest
> change cache mode into :
> cache.setCacheMode(REPLICATED);
> and change implementation with:
> {noformat}
> @Override protected void beforeTest() throws Exception {
> Properties cfg = new Properties();
> cfg.setProperty(PROP_NODE_ID, grid(0).localNode().id().toString());
> stmt = DriverManager.getConnection(BASE_URL, cfg).createStatement();
> assert stmt != null;
> assert !stmt.isClosed();
> }
> {noformat}
> also, with *lazy=false* upper case is not reproduced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20532) Invalid SharedSecrets loading on jdk 12 and later
[ https://issues.apache.org/jira/browse/IGNITE-20532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771512#comment-17771512 ] Ivan Daschinsky commented on IGNITE-20532: -- [~namelchev] Thanks for review, merged > Invalid SharedSecrets loading on jdk 12 and later > - > > Key: IGNITE-20532 > URL: https://issues.apache.org/jira/browse/IGNITE-20532 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.15 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20490) Update the snappy dependency in order to fix CVEs
[ https://issues.apache.org/jira/browse/IGNITE-20490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-20490: Labels: ise (was: ) > Update the snappy dependency in order to fix CVEs > - > > Key: IGNITE-20490 > URL: https://issues.apache.org/jira/browse/IGNITE-20490 > Project: Ignite > Issue Type: Task >Affects Versions: 2.15 >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > The dependency needs to be updated to fix CVE: > https://github.com/xerial/snappy-java/security/advisories/GHSA-55g7-9cwv-5qfv -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20529) Update Ignite dependency: Snappy
[ https://issues.apache.org/jira/browse/IGNITE-20529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev resolved IGNITE-20529. - Resolution: Duplicate https://issues.apache.org/jira/browse/IGNITE-20490 > Update Ignite dependency: Snappy > - > > Key: IGNITE-20529 > URL: https://issues.apache.org/jira/browse/IGNITE-20529 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > > Update Ignite dependency: Snappy 1.1.10.3 to 1.1.10.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20357) Design node config, zone and table storage relations
[ https://issues.apache.org/jira/browse/IGNITE-20357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-20357: Attachment: Copy of Unify storage configurations for the table_zone_node levels.pdf > Design node config, zone and table storage relations > > > Key: IGNITE-20357 > URL: https://issues.apache.org/jira/browse/IGNITE-20357 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Attachments: Copy of Unify storage configurations for the > table_zone_node levels.pdf > > > *Motivation* > We need to clarify the UX around the table storage, zone and node configs > according to zone-based collocation. > *Definition of done* > User has the simple and predictable flow to: > - Configure the node storage from the point of view: tables with which > requirements for storage can use this node. > - Describe on the zone creation, the nodes with which table storages can be a > part of this zone > - Describe on the table creation, which storage needed for this table and > receive the error as soon as possible if chosen zone can't guarantee that its > nodes have this storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20552) The example code is giving a NotSerializableException
yafengshi created IGNITE-20552:
--
Summary: The example code is giving a NotSerializableException
Key: IGNITE-20552
URL: https://issues.apache.org/jira/browse/IGNITE-20552
Project: Ignite
Issue Type: Improvement
Components: documentation
Affects Versions: None
Reporter: yafengshi
Fix For: None
docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
The following code will result in a NotSerializableException：
{code:java}
QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
.setFields(new LinkedHashMap() {{
put("orgId", Integer.class.getName());
put("salary", Integer.class.getName());
}}) {code}
{code:java}
java.io.NotSerializableException: com.demo.TestController
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
~[na:1.8.0_362]
at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_362]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:1.8.0_362]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.8.0_362]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
~[na:1.8.0_362]
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
~[na:1.8.0_362]
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
~[na:1.8.0_362]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5131)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$dynamicStartCache$30(GridCacheProcessor.java:3537)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3569)
~[ignite-core-2.15.0.jar:2.15.0]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3473)
~[ignite-core-2.15.0.jar:2.15.0]
at
org
[jira] [Resolved] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yafengshi resolved IGNITE-20552.
Resolution: Fixed
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Priority: Major
> Labels: bugfix
> Fix For: None
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5131)
> ~
[jira] [Reopened] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yafengshi reopened IGNITE-20552:
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Priority: Major
> Labels: bugfix
> Fix For: None
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5131)
> ~[ignite-core-2.15.0.ja
[jira] [Updated] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yafengshi updated IGNITE-20552:
---
Labels: newbie (was: bugfix)
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Priority: Major
> Labels: newbie
> Fix For: None
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:
[jira] [Created] (IGNITE-20553) Unexpected rebalancing immediately after table creation
Kirill Tkalenko created IGNITE-20553:
Summary: Unexpected rebalancing immediately after table creation
Key: IGNITE-20553
URL: https://issues.apache.org/jira/browse/IGNITE-20553
Project: Ignite
Issue Type: Bug
Reporter: Kirill Tkalenko
Fix For: 3.0.0-beta2
During the implementation of IGNITE-20330, it was discovered that when running
*org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest#checkSchemasCorrectlyRestore*,
a situation may occur that after creating the table, rebalancing will begin
and this test will freeze on the first insert (*sql(ignite1,
String.format("INSERT INTO " + TABLE_NAME + " VALUES(%d, %d, %d)", i, i, 2 *
i));*). The situation is not reproduced often; you need to run the test several
times.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20541) Watch Processor performs unnecessary work in case of empty events
[ https://issues.apache.org/jira/browse/IGNITE-20541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20541: - Reviewer: Kirill Tkalenko > Watch Processor performs unnecessary work in case of empty events > - > > Key: IGNITE-20541 > URL: https://issues.apache.org/jira/browse/IGNITE-20541 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > If a Meta Storage event does not match any of the Watch Listeners, Watch > Processor creates a bunch of empty futures for no reason, we can simply skip > such events. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20553) Unexpected rebalancing immediately after table creation
[
https://issues.apache.org/jira/browse/IGNITE-20553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20553:
-
Description:
During the implementation of IGNITE-20330, it was discovered that when running
{*}org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest#checkSchemasCorrectlyRestore{*},
a situation may occur that after creating the table, rebalancing will begin
and this test will freeze on the first insert ({*}sql(ignite1,
String.format("INSERT INTO " + TABLE_NAME + " VALUES(%d, %d, %d)", i, i, 2 *
i));{*}). The situation is not reproduced often; you need to run the test
several times.
h3. Upd#1
It's a known issue that node restart is broken. Before proceeding with given
ticket metastorage compaction epic should be finished, espesially
https://issues.apache.org/jira/browse/IGNITE-20210
was:During the implementation of IGNITE-20330, it was discovered that when
running
*org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest#checkSchemasCorrectlyRestore*,
a situation may occur that after creating the table, rebalancing will begin
and this test will freeze on the first insert (*sql(ignite1,
String.format("INSERT INTO " + TABLE_NAME + " VALUES(%d, %d, %d)", i, i, 2 *
i));*). The situation is not reproduced often; you need to run the test several
times.
> Unexpected rebalancing immediately after table creation
> ---
>
> Key: IGNITE-20553
> URL: https://issues.apache.org/jira/browse/IGNITE-20553
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> During the implementation of IGNITE-20330, it was discovered that when
> running
> {*}org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest#checkSchemasCorrectlyRestore{*},
> a situation may occur that after creating the table, rebalancing will begin
> and this test will freeze on the first insert ({*}sql(ignite1,
> String.format("INSERT INTO " + TABLE_NAME + " VALUES(%d, %d, %d)", i, i, 2 *
> i));{*}). The situation is not reproduced often; you need to run the test
> several times.
> h3. Upd#1
> It's a known issue that node restart is broken. Before proceeding with given
> ticket metastorage compaction epic should be finished, espesially
> https://issues.apache.org/jira/browse/IGNITE-20210
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19537) 3.0 Data streamer
[ https://issues.apache.org/jira/browse/IGNITE-19537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19537: Summary: 3.0 Data streamer (was: Thin 3.0: Data streamer) > 3.0 Data streamer > - > > Key: IGNITE-19537 > URL: https://issues.apache.org/jira/browse/IGNITE-19537 > Project: Ignite > Issue Type: Epic > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Design and implement data streamer for Ignite 3.0 clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19537) 3.0 Data streamer
[ https://issues.apache.org/jira/browse/IGNITE-19537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19537: Description: Design and implement data streamer for Ignite 3.0 clients and embedded API. (was: Design and implement data streamer for Ignite 3.0 clients.) > 3.0 Data streamer > - > > Key: IGNITE-19537 > URL: https://issues.apache.org/jira/browse/IGNITE-19537 > Project: Ignite > Issue Type: Epic > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Design and implement data streamer for Ignite 3.0 clients and embedded API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20554) 3.0 Continuous Query
Pavel Tupitsyn created IGNITE-20554: --- Summary: 3.0 Continuous Query Key: IGNITE-20554 URL: https://issues.apache.org/jira/browse/IGNITE-20554 Project: Ignite Issue Type: Epic 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-19537) 3.0 Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-19537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19537: Summary: 3.0 Data Streamer (was: 3.0 Data streamer) > 3.0 Data Streamer > - > > Key: IGNITE-19537 > URL: https://issues.apache.org/jira/browse/IGNITE-19537 > Project: Ignite > Issue Type: Epic > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Design and implement data streamer for Ignite 3.0 clients and embedded API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20554) 3.0 Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20554: Labels: ignite-3 (was: ) > 3.0 Continuous Query > > > Key: IGNITE-20554 > URL: https://issues.apache.org/jira/browse/IGNITE-20554 > Project: Ignite > Issue Type: Epic >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20555) Basic Embedded Continuous Query
Pavel Tupitsyn created IGNITE-20555: --- Summary: Basic Embedded Continuous Query Key: IGNITE-20555 URL: https://issues.apache.org/jira/browse/IGNITE-20555 Project: Ignite Issue Type: New Feature 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] [Created] (IGNITE-20556) Embedded Continuous Query: add columnNames option
Pavel Tupitsyn created IGNITE-20556: --- Summary: Embedded Continuous Query: add columnNames option Key: IGNITE-20556 URL: https://issues.apache.org/jira/browse/IGNITE-20556 Project: Ignite Issue Type: New Feature Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Add an ability to receive a subset of columns in a Continuous Query with *ContinuousQueryOptions.columnNames*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (IGNITE-20554) 3.0 Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-20554: > 3.0 Continuous Query > > > Key: IGNITE-20554 > URL: https://issues.apache.org/jira/browse/IGNITE-20554 > Project: Ignite > Issue Type: Epic >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (IGNITE-20555) Basic Embedded Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-20555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-20555: > Basic Embedded Continuous Query > --- > > Key: IGNITE-20555 > URL: https://issues.apache.org/jira/browse/IGNITE-20555 > Project: Ignite > Issue Type: New Feature >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (IGNITE-20556) Embedded Continuous Query: add columnNames option
[ https://issues.apache.org/jira/browse/IGNITE-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-20556: > Embedded Continuous Query: add columnNames option > - > > Key: IGNITE-20556 > URL: https://issues.apache.org/jira/browse/IGNITE-20556 > Project: Ignite > Issue Type: New Feature >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Add an ability to receive a subset of columns in a Continuous Query with > *ContinuousQueryOptions.columnNames*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20557) Embedded Continuous Query: add filter by event type
Pavel Tupitsyn created IGNITE-20557: --- Summary: Embedded Continuous Query: add filter by event type Key: IGNITE-20557 URL: https://issues.apache.org/jira/browse/IGNITE-20557 Project: Ignite Issue Type: New Feature Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Add a possibility to receive events of specific types only (any combination of CREATE, UPDATE, DELETE) with *ContinuousQueryOptions.filter* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (IGNITE-20557) Embedded Continuous Query: add filter by event type
[ https://issues.apache.org/jira/browse/IGNITE-20557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-20557: > Embedded Continuous Query: add filter by event type > --- > > Key: IGNITE-20557 > URL: https://issues.apache.org/jira/browse/IGNITE-20557 > Project: Ignite > Issue Type: New Feature >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Add a possibility to receive events of specific types only (any combination > of CREATE, UPDATE, DELETE) with *ContinuousQueryOptions.filter* -- This message was sent by Atlassian Jira (v8.20.10#820010)
