[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=17771337#comment-17771337
]
Ignite TC Bot commented on IGNITE-20532:
{panel:title=Branch: [pull/10969/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10969/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7359933buildTypeId=IgniteTests24Java8_RunAll]
> 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: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20346) ODBC 3.0: Implement column metadata fetching
[ https://issues.apache.org/jira/browse/IGNITE-20346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771335#comment-17771335 ] Pavel Tupitsyn commented on IGNITE-20346: - [~isapego] Looks good to me in general; please see a couple of minor comments on GitHub. > ODBC 3.0: Implement column metadata fetching > > > Key: IGNITE-20346 > URL: https://issues.apache.org/jira/browse/IGNITE-20346 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Scope: > - Implement server side request handling; > - Implement client side metadata handling; > - Port applicable tests; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20537) Add ability to create implicit transactions
Roman Puchkovskiy created IGNITE-20537:
--
Summary: 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
Fix For: 3.0.0-beta2
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] [Updated] (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:all-tabpanel ] Ivan Daschinsky updated IGNITE-20532: - Summary: Invalid SharedSecrets loading on jdk 12 and later (was: Invalid SharedSecrets loading on jdk 12 and earlier) > 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: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-20528:
-
Assignee: Anton Vinogradov
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-97, ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20536) No-op handlers for StripedDisruptor.StripeEntryHandler#subscribers
Sergey Uttsel created IGNITE-20536: -- Summary: No-op handlers for StripedDisruptor.StripeEntryHandler#subscribers Key: IGNITE-20536 URL: https://issues.apache.org/jira/browse/IGNITE-20536 Project: Ignite Issue Type: Bug Reporter: Sergey Uttsel h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-20397 we discussed that it is possible to get null handler in StripedDisruptor.StripeEntryHandler#onEvent on a table drop. And we start to use a log warning instead of an assert. But this is not the best solution. We still need to assert that handler is not null on first event for the partition. And we need to skip events if the partition was removed. So we need: # to add assert that `handler != null`, # on StripedDisruptor.StripeEntryHandler#unsubscribe put a no-op handler to a subscribers map instead of remove it, # to remove the no-op handler when there are no events for this handler. h3. Definition of done: # assert that `handler != null` is added, # no-op handler on StripedDisruptor.StripeEntryHandler#unsubscribe, # remove handler when it is not needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20535) User object mapping
Mikhail Pochatkin created IGNITE-20535: -- Summary: User object mapping Key: IGNITE-20535 URL: https://issues.apache.org/jira/browse/IGNITE-20535 Project: Ignite Issue Type: Epic Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause a resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20534:
--
Description:
It is possible to rollback a transaction, invoke a modification operation on
some table, open another transaction and get 'Failed to acquire a lock due to a
conflict' when accessing that table.
Reproducer:
{code:java}
@Test
public void testLockIsNotReleasedAfterTxRollback() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteSql sql = ignite.sql();
try (Session ses = ignite.sql().createSession()) {
ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
PRIMARY KEY, val INTEGER)").affectedRows();
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin();
assertThrows(RuntimeException.class, () -> session.execute(tx,
"SELECT 1/0"));
tx.rollback();
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
line is commented out, everything works fine.
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin(new
TransactionOptions().readOnly(false));
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to a
conflict [txId=018af087-fb6b---e9bae05c,
conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
tx.commit();
}
}
{code}
was:
It is possible to rollback a transaction, invoke a modification operation, open
another transaction and get 'Failed to acquire a lock due to a conflict' when
accessing that table.
Reproducer:
{code:java}
@Test
public void testLockIsNotReleasedAfterTxRollback() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteSql sql = ignite.sql();
try (Session ses = ignite.sql().createSession()) {
ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
PRIMARY KEY, val INTEGER)").affectedRows();
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin();
assertThrows(RuntimeException.class, () -> session.execute(tx,
"SELECT 1/0"));
tx.rollback();
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
line is commented out, everything works fine.
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin(new
TransactionOptions().readOnly(false));
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to a
conflict [txId=018af087-fb6b---e9bae05c,
conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
tx.commit();
}
}
{code}
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause a resource leak.
> --
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation on
> some table, open another transaction and get 'Failed to acquire a lock due to
> a conflict' when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause a resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20534:
--
Summary: Transactions. It is possible to call enlist on a rollbacked
transaction and cause a resource leak. (was: Transactions. It is possible to
call enlist on a rollbacked transaction and cause resource leak.)
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause a resource leak.
> --
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation,
> open another transaction and get 'Failed to acquire a lock due to a conflict'
> when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
> a conflict [txId=018af087-fb6b---e9bae05c,
> conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
> intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> tx.commit();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20534:
--
Labels: ignite-3 (was: )
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause resource leak.
>
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation,
> open another transaction and get 'Failed to acquire a lock due to a conflict'
> when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
> a conflict [txId=018af087-fb6b---e9bae05c,
> conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
> intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> tx.commit();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause resource leak.
Maksim Zhuravkov created IGNITE-20534:
-
Summary: Transactions. It is possible to call enlist on a
rollbacked transaction and cause resource leak.
Key: IGNITE-20534
URL: https://issues.apache.org/jira/browse/IGNITE-20534
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-beta2
Reporter: Maksim Zhuravkov
It is possible to rollback a transaction, invoke a modification operation, open
another transaction and get 'Failed to acquire a lock due to a conflict' when
accessing that table.
Reproducer:
{code:java}
@Test
public void testLockIsNotReleasedAfterTxRollback() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteSql sql = ignite.sql();
try (Session ses = ignite.sql().createSession()) {
ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
PRIMARY KEY, val INTEGER)").affectedRows();
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin();
assertThrows(RuntimeException.class, () -> session.execute(tx,
"SELECT 1/0"));
tx.rollback();
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
line is commented out, everything works fine.
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin(new
TransactionOptions().readOnly(false));
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to a
conflict [txId=018af087-fb6b---e9bae05c,
conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
tx.commit();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20533) Implement AuthenticationRequest validation in AuthenticationManagerImpl when authentication is enabled
Ivan Gagarkin created IGNITE-20533:
--
Summary: Implement AuthenticationRequest validation in
AuthenticationManagerImpl when authentication is enabled
Key: IGNITE-20533
URL: https://issues.apache.org/jira/browse/IGNITE-20533
Project: Ignite
Issue Type: Improvement
Components: security
Reporter: Ivan Gagarkin
Assignee: Ivan Gagarkin
Currently, the
{{org.apache.ignite.internal.security.authentication.AuthenticationManagerImpl}}
class attempts to authenticate users even when authentication is enabled, but
the {{AuthenticationRequest}} contains an empty username and password.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20532) Invalid SharedSecrets loading on jdk 12 and earlier
[ https://issues.apache.org/jira/browse/IGNITE-20532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-20532: - Affects Version/s: 2.15 > Invalid SharedSecrets loading on jdk 12 and earlier > --- > > 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 > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20532) Invalid SharedSecrets loading on jdk 12 and earlier
[ https://issues.apache.org/jira/browse/IGNITE-20532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-20532: - Labels: ise (was: ) > Invalid SharedSecrets loading on jdk 12 and earlier > --- > > 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 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20532) Invalid SharedSecrets loading on jdk 12 and earlier
[ https://issues.apache.org/jira/browse/IGNITE-20532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-20532: - Fix Version/s: 2.16 > Invalid SharedSecrets loading on jdk 12 and earlier > --- > > Key: IGNITE-20532 > URL: https://issues.apache.org/jira/browse/IGNITE-20532 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20532) Invalid SharedSecrets loading on jdk 12 and earlier
Ivan Daschinsky created IGNITE-20532: Summary: Invalid SharedSecrets loading on jdk 12 and earlier Key: IGNITE-20532 URL: https://issues.apache.org/jira/browse/IGNITE-20532 Project: Ignite Issue Type: Bug Reporter: Ivan Daschinsky Assignee: Ivan Daschinsky -- 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
]
Roman Puchkovskiy updated IGNITE-20520:
---
Reviewer: Andrey Mashenkov
> 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: 10m
> 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-20506) CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT removal
[ https://issues.apache.org/jira/browse/IGNITE-20506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20506: -- Ignite Flags: Release Notes Required > CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT removal > - > > Key: IGNITE-20506 > URL: https://issues.apache.org/jira/browse/IGNITE-20506 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20527) Main compilation issue
[
https://issues.apache.org/jira/browse/IGNITE-20527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin resolved IGNITE-20527.
--
Fix Version/s: 3.0.0-beta2
Resolution: Fixed
> 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
> 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] [Assigned] (IGNITE-20527) Main compilation issue
[
https://issues.apache.org/jira/browse/IGNITE-20527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin reassigned IGNITE-20527:
Assignee: Alexander Lapin
> 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
> 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] [Assigned] (IGNITE-20436) Thin 3.0: Utilize exception handler in client code
[ https://issues.apache.org/jira/browse/IGNITE-20436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-20436: Assignee: Pavel Tupitsyn (was: Igor Sapego) > Thin 3.0: Utilize exception handler in client code > -- > > Key: IGNITE-20436 > URL: https://issues.apache.org/jira/browse/IGNITE-20436 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Utilize exception handler introduced by IGNITE-19539 in client code. Search > this tickets tag in code for specific places. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Labels: iep-97 ise (was: ise ise-97)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: iep-97, ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Labels: ise ise-97 (was: ise)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise, ise-97
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20530) Start building indexes for write-only indexes
[ https://issues.apache.org/jira/browse/IGNITE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20530: - Description: Now indexes are started for all indexes, but of course they can stop immediately because there is no need to build them, but it is more correct to start building for write-only indexes (with this status). At the moment there is *org.apache.ignite.internal.catalog.descriptors.CatalogIndexDescriptor#writeOnly*, but it does not change in any way. was:Now indexes are started for all indexes, but of course they can stop immediately because there is no need to build them, but it is more correct to start building for write-only indexes (with this status). > Start building indexes for write-only indexes > - > > Key: IGNITE-20530 > URL: https://issues.apache.org/jira/browse/IGNITE-20530 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Now indexes are started for all indexes, but of course they can stop > immediately because there is no need to build them, but it is more correct to > start building for write-only indexes (with this status). > At the moment there is > *org.apache.ignite.internal.catalog.descriptors.CatalogIndexDescriptor#writeOnly*, > but it does not change in any way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Description:
CDC doesn't work If some cache objects transformation is applied (see the
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
ignite_cdc.sh utility produces the NPE (see below). The immediate reason of the
NPE is that ignite_cdc.sh uses the reduced version of the context
(StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
{noformat}
[2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
[CacheObjectImpl [val=null, hasValBytes=true]]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
~[classes/:?]
at
org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
~[classes/:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
[classes/:?]
at
org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344) [classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
{noformat}
was:
CDC doesn't work If some cache objects transformation is applied (see the
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
ignite_cdc.sh utility produces the NPE (see below). The immediate reason of the
NPE is that ignite_cdc.sh uses the reduced version of the context
(StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
{noformat}
[2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
[CacheObjectImpl [val=null, hasValBytes=true]]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
~[classes/:?]
at
org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
~[classes/:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
[classes/:?]
at
[jira] [Updated] (IGNITE-20511) Thin 3.0: Track and log connection ID on the server
[ https://issues.apache.org/jira/browse/IGNITE-20511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20511: Issue Type: Improvement (was: Bug) > Thin 3.0: Track and log connection ID on the server > --- > > Key: IGNITE-20511 > URL: https://issues.apache.org/jira/browse/IGNITE-20511 > Project: Ignite > Issue Type: Improvement > 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 > > > * Assign a unique ID to every client connection in > *ClientInboundMessageHandler* > * Include it into all log messages to correlate them easier -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20531) Thin 3.0: Add user-defined client name
[ https://issues.apache.org/jira/browse/IGNITE-20531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20531: Description: * Pass user-defined client name to the server * Include into log messages was: * Pass user-defined client name to the server * Log it > Thin 3.0: Add user-defined client name > -- > > Key: IGNITE-20531 > URL: https://issues.apache.org/jira/browse/IGNITE-20531 > Project: Ignite > Issue Type: Improvement > 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 > > > * Pass user-defined client name to the server > * Include into log messages -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20531) Thin 3.0: Add user-defined client name
[ https://issues.apache.org/jira/browse/IGNITE-20531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20531: Description: * Pass user-defined client name to the server * Log it > Thin 3.0: Add user-defined client name > -- > > Key: IGNITE-20531 > URL: https://issues.apache.org/jira/browse/IGNITE-20531 > Project: Ignite > Issue Type: Improvement > 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 > > > * Pass user-defined client name to the server > * Log it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20530) Start building indexes for write-only indexes
Kirill Tkalenko created IGNITE-20530: Summary: Start building indexes for write-only indexes Key: IGNITE-20530 URL: https://issues.apache.org/jira/browse/IGNITE-20530 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Now indexes are started for all indexes, but of course they can stop immediately because there is no need to build them, but it is more correct to start building for write-only indexes (with this status). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20531) Thin 3.0: Add user-defined client name
Pavel Tupitsyn created IGNITE-20531: --- Summary: Thin 3.0: Add user-defined client name Key: IGNITE-20531 URL: https://issues.apache.org/jira/browse/IGNITE-20531 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20511) Thin 3.0: Track and log connection ID on the server
[ https://issues.apache.org/jira/browse/IGNITE-20511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20511: Summary: Thin 3.0: Track and log connection ID on the server (was: Thin 3.0: Track and log client ID on the server) > Thin 3.0: Track and log connection ID on the server > --- > > Key: IGNITE-20511 > URL: https://issues.apache.org/jira/browse/IGNITE-20511 > 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 > > > * Assign a unique ID to every client connection in > *ClientInboundMessageHandler* > * Include it into all log messages to correlate them easier -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Labels: ise (was: iep-97 ise)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
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:
Attachment: JdbcComplexQuerySelfTest.java
> 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] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-20528:
-
Labels: ise (was: )
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-20528:
-
Labels: iep-97 ise (was: ise)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: iep-97, ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (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 updated IGNITE-20529: Labels: ise (was: ) > 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] [Created] (IGNITE-20529) Update Ignite dependency: Snappy
Aleksandr Nikolaev created IGNITE-20529: --- Summary: 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 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-20407) Update Ignite dependency Snappy
[ https://issues.apache.org/jira/browse/IGNITE-20407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-20407: Release Note: Updated dependency version of Snappy-java (was: Updated dependency version of Snappy-java to 1.1.10.3) > Update Ignite dependency Snappy > --- > > Key: IGNITE-20407 > URL: https://issues.apache.org/jira/browse/IGNITE-20407 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency: Snappy 1.1.8.4 to 1.1.10.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20407) Update Ignite dependency Snappy
[ https://issues.apache.org/jira/browse/IGNITE-20407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-20407: Docs Text: Update Ignite dependency: Snappy was: Update Ignite dependency: Snappy to 1.1.10.3 > Update Ignite dependency Snappy > --- > > Key: IGNITE-20407 > URL: https://issues.apache.org/jira/browse/IGNITE-20407 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency: Snappy 1.1.8.4 to 1.1.10.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
Sergey Korotkov created IGNITE-20528:
Summary: CDC doesn't work if the "Cache objects transformation" is
applied
Key: IGNITE-20528
URL: https://issues.apache.org/jira/browse/IGNITE-20528
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
CDC doesn't work If some cache objects transformation is applied (see the
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
ignite_cdc.sh utility produces the NPE (see below). The immediate reason of the
NPE is that ignite_cdc.sh uses the reduced version of the context
(StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
{noformat}
[2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
[CacheObjectImpl [val=null, hasValBytes=true]]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
~[classes/:?]
at
org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
~[classes/:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
[classes/:?]
at
org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344) [classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
{noformat}
--
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
]
Alexander Lapin updated IGNITE-20527:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Main compilation issue
> --
>
> Key: IGNITE-20527
> URL: https://issues.apache.org/jira/browse/IGNITE-20527
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Blocker
>
> {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] [Created] (IGNITE-20527) Main compilation issue
Alexander Lapin created IGNITE-20527: Summary: Main compilation issue Key: IGNITE-20527 URL: https://issues.apache.org/jira/browse/IGNITE-20527 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- 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
]
Alexander Lapin updated IGNITE-20527:
-
Description:
{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}
> Main compilation issue
> --
>
> Key: IGNITE-20527
> URL: https://issues.apache.org/jira/browse/IGNITE-20527
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Blocker
>
> {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-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:
Ignite Flags: (was: Docs Required,Release Notes Required)
> 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
>
> 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] [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:
Description:
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.
was:
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}
> 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
>
> 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
>
[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:
Description:
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
and change implementation with:
change cache mode into :
cache.setCacheMode(PARTITIONED);
{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}
was:
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
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}
> 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
>
> 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
>
[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:
Description:
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}
was:
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(PARTITIONED);
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}
> 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
>
> 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)
>
[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:
Description:
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(PARTITIONED);
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}
was:
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
and change implementation with:
change cache mode into :
cache.setCacheMode(PARTITIONED);
{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}
> 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
>
> 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)
>
[jira] [Created] (IGNITE-20526) JDBC2 (thin client) throws IllegalMonitorStateException if property ignite.jdbc..nodeId is filled
Evgeny Stanilovsky created IGNITE-20526:
---
Summary: 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
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
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}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20525) Fix ItBuildIndexTest#testChangePrimaryReplicaOnMiddleBuildIndex
Kirill Tkalenko created IGNITE-20525: Summary: Fix ItBuildIndexTest#testChangePrimaryReplicaOnMiddleBuildIndex Key: IGNITE-20525 URL: https://issues.apache.org/jira/browse/IGNITE-20525 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko At the moment, *org.apache.ignite.internal.sql.engine.ItBuildIndexTest#testChangePrimaryReplicaOnMiddleBuildIndex* is not easy to fix, since we do not have the ability to change the leaseholder in the middle of building the index, such an opportunity should appear IGNITE-20365. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate
[
https://issues.apache.org/jira/browse/IGNITE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771012#comment-17771012
]
Vladislav Pyatkov commented on IGNITE-20367:
LGTM
> ItTableRaftSnapshotsTest times out with high flaky rate
> ---
>
> Key: IGNITE-20367
> URL: https://issues.apache.org/jira/browse/IGNITE-20367
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
> at
> app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
> at
> app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
> at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
>
[jira] [Commented] (IGNITE-20517) Update Ignite dependency: Jetty
[ https://issues.apache.org/jira/browse/IGNITE-20517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771011#comment-17771011 ] Mikhail Petrov commented on IGNITE-20517: - [~aonikolaev] Thank you for the contribution. > Update Ignite dependency: Jetty > --- > > Key: IGNITE-20517 > URL: https://issues.apache.org/jira/browse/IGNITE-20517 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Jetty dependency 9.4.51.v20230217 to 9.4.52.v20230823 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20432) Sql. CatalogUtils#defaultLength length derivation is not clear
[
https://issues.apache.org/jira/browse/IGNITE-20432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20432:
---
Description:
For now below code part is commented with ignite-19938 TODO, which is not
relevant one.
The goal of this issue is to align the correctness of method call usage.
{noformat}
private static int defaultLength(ColumnType columnType, int precision) {
switch (columnType) {
case BITMASK:
case STRING:
case BYTE_ARRAY:
return DEFAULT_VARLEN_LENGTH;
default:
return Math.max(DEFAULT_LENGTH, precision);
}
}
{noformat}
Most probably we need amend just date/time
was:
For now below code part is commented with ignite-19938 TODO, which is not
relevant one.
The goal of this issue is to align the correctness of method call usage.
{noformat}
private static int defaultLength(ColumnType columnType, int precision) {
switch (columnType) {
case BITMASK:
case STRING:
case BYTE_ARRAY:
return DEFAULT_VARLEN_LENGTH;
default:
return Math.max(DEFAULT_LENGTH, precision);
}
}
{noformat}
> Sql. CatalogUtils#defaultLength length derivation is not clear
> --
>
> Key: IGNITE-20432
> URL: https://issues.apache.org/jira/browse/IGNITE-20432
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> For now below code part is commented with ignite-19938 TODO, which is not
> relevant one.
> The goal of this issue is to align the correctness of method call usage.
> {noformat}
> private static int defaultLength(ColumnType columnType, int precision) {
> switch (columnType) {
> case BITMASK:
> case STRING:
> case BYTE_ARRAY:
> return DEFAULT_VARLEN_LENGTH;
> default:
> return Math.max(DEFAULT_LENGTH, precision);
> }
> }
> {noformat}
> Most probably we need amend just date/time
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20517) Update Ignite dependency: Jetty
[ https://issues.apache.org/jira/browse/IGNITE-20517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20517: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Update Ignite dependency: Jetty > --- > > Key: IGNITE-20517 > URL: https://issues.apache.org/jira/browse/IGNITE-20517 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Jetty dependency 9.4.51.v20230217 to 9.4.52.v20230823 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20517) Update Ignite dependency: Jetty
[ https://issues.apache.org/jira/browse/IGNITE-20517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20517: Docs Text: Updated Jetty dependency (was: Update Jetty dependency ) > Update Ignite dependency: Jetty > --- > > Key: IGNITE-20517 > URL: https://issues.apache.org/jira/browse/IGNITE-20517 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Jetty dependency 9.4.51.v20230217 to 9.4.52.v20230823 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Description: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. It is understood that single-column mapping allows nulls to set nullable column values; however, overall situation is confusing. We can improve it in 3 ways: # Keep existing behavior, improve javadoc # Always disallow null value (NOTE: makes it impossible to work with nulls in 2-column simple type mapping scenario) # Always allow null value (set all mapped columns to null for POJO use case) was: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. It is understood that single-column mapping allows nulls to set nullable column values; however, overall situation is confusing. We can improve it in 3 ways: # Keep existing behavior, improve javadoc # Always disallow null value # Always allow null value (set all mapped columns to null for POJO use case) > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavior with null value is inconsistent: > * Interface method does not have *@Nullable* annotation on *val* > * *KeyValueBinaryViewImpl* throws an exception when *val* is null > * *KeyValueViewImpl* does not throw exception right away; null is allowed for > simple mapping (e.g. **), but not allowed with POJOs > () > This affects embedded and thin APIs equally. > It is understood that single-column mapping allows nulls to set nullable > column values; however, overall situation is confusing. We can improve it in > 3 ways: > # Keep existing behavior, improve javadoc > # Always disallow null value (NOTE: makes it impossible to work with nulls in > 2-column simple type mapping scenario) > # Always allow null value (set all mapped columns to null for POJO use case) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Description: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. It is understood that single-column mapping allows nulls to set nullable column values; however, overall situation is confusing. We can improve it in 3 ways: # Keep existing behavior, improve javadoc # Always disallow null value # Always allow null value (set all mapped columns to null for POJO use case) was: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. It is understood that single-column mapping allows nulls to set nullable column values; however, overall situation is confusing. We can improve it in 3 ways: 1. Keep existing behavior, improve javadoc 2. Always disallow null value 3. Always allow null value (set all mapped columns to null for POJO use case) > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavior with null value is inconsistent: > * Interface method does not have *@Nullable* annotation on *val* > * *KeyValueBinaryViewImpl* throws an exception when *val* is null > * *KeyValueViewImpl* does not throw exception right away; null is allowed for > simple mapping (e.g. **), but not allowed with POJOs > () > This affects embedded and thin APIs equally. > It is understood that single-column mapping allows nulls to set nullable > column values; however, overall situation is confusing. We can improve it in > 3 ways: > # Keep existing behavior, improve javadoc > # Always disallow null value > # Always allow null value (set all mapped columns to null for POJO use case) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Description: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. It is understood that single-column mapping allows nulls to set nullable column values; however, overall situation is confusing. We can improve it in 3 ways: 1. Keep existing behavior, improve javadoc 2. Always disallow null value 3. Always allow null value (set all mapped columns to null for POJO use case) was: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. A simple fix would be to disable nulls in all cases, and add null check to *KeyValueViewImpl*. > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavior with null value is inconsistent: > * Interface method does not have *@Nullable* annotation on *val* > * *KeyValueBinaryViewImpl* throws an exception when *val* is null > * *KeyValueViewImpl* does not throw exception right away; null is allowed for > simple mapping (e.g. **), but not allowed with POJOs > () > This affects embedded and thin APIs equally. > It is understood that single-column mapping allows nulls to set nullable > column values; however, overall situation is confusing. We can improve it in > 3 ways: > 1. Keep existing behavior, improve javadoc > 2. Always disallow null value > 3. Always allow null value (set all mapped columns to null for POJO use case) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Description: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. A simple fix would be to disable nulls in all cases, and add null check to *KeyValueViewImpl*. was: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavior with null value is inconsistent: > * Interface method does not have *@Nullable* annotation on *val* > * *KeyValueBinaryViewImpl* throws an exception when *val* is null > * *KeyValueViewImpl* does not throw exception right away; null is allowed for > simple mapping (e.g. **), but not allowed with POJOs > () > This affects embedded and thin APIs equally. > A simple fix would be to disable nulls in all cases, and add null check to > *KeyValueViewImpl*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Description: *KeyValueView.put* behavior with null value is inconsistent: * Interface method does not have *@Nullable* annotation on *val* * *KeyValueBinaryViewImpl* throws an exception when *val* is null * *KeyValueViewImpl* does not throw exception right away; null is allowed for simple mapping (e.g. **), but not allowed with POJOs () This affects embedded and thin APIs equally. was: *KeyValueView.put* behavi This affects embedded and thin APIs equally. > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavior with null value is inconsistent: > * Interface method does not have *@Nullable* annotation on *val* > * *KeyValueBinaryViewImpl* throws an exception when *val* is null > * *KeyValueViewImpl* does not throw exception right away; null is allowed for > simple mapping (e.g. **), but not allowed with POJOs > () > This affects embedded and thin APIs equally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of put(k, v) with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Description: *KeyValueView.put* behavi This affects embedded and thin APIs equally. > Inconsistent behavior of put(k, v) with null value > -- > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavi > This affects embedded and thin APIs equally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20524) Inconsistent behavior of KeyValueView.put with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Summary: Inconsistent behavior of KeyValueView.put with null value (was: Inconsistent behavior of put(k, v) with null value) > Inconsistent behavior of KeyValueView.put with null value > - > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *KeyValueView.put* behavi > This affects embedded and thin APIs equally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20524) Inconsistent behavior of put(k, v) with null value
Pavel Tupitsyn created IGNITE-20524: --- Summary: Inconsistent behavior of put(k, v) with null value Key: IGNITE-20524 URL: https://issues.apache.org/jira/browse/IGNITE-20524 Project: Ignite Issue Type: Improvement 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-20524) Inconsistent behavior of put(k, v) with null value
[ https://issues.apache.org/jira/browse/IGNITE-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20524: Component/s: thin client > Inconsistent behavior of put(k, v) with null value > -- > > Key: IGNITE-20524 > URL: https://issues.apache.org/jira/browse/IGNITE-20524 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20517) Update Ignite dependency: Jetty
[
https://issues.apache.org/jira/browse/IGNITE-20517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771004#comment-17771004
]
Ignite TC Bot commented on IGNITE-20517:
{panel:title=Branch: [pull/10962/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10962/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7354908buildTypeId=IgniteTests24Java8_RunAll]
> Update Ignite dependency: Jetty
> ---
>
> Key: IGNITE-20517
> URL: https://issues.apache.org/jira/browse/IGNITE-20517
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update Jetty dependency 9.4.51.v20230217 to 9.4.52.v20230823
--
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 ] Alexander Lapin updated IGNITE-20457: - Description: 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] [Assigned] (IGNITE-20519) Add causality token of the last update of catalog descriptors to CatalogObjectDescriptor
[
https://issues.apache.org/jira/browse/IGNITE-20519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-20519:
Assignee: Mirza Aliev
> Add causality token of the last update of catalog descriptors to
> CatalogObjectDescriptor
>
>
> Key: IGNITE-20519
> URL: https://issues.apache.org/jira/browse/IGNITE-20519
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> It could be useful to add causality token of the last update of
> {{CatalogObjectDescriptor}}. For example, this will help us to call
> {{DistributionZoneManager#dataNodes(long causalityToken, int zoneId)}} for
> the specified {{CatalogZoneDescriptor}}, so we could receive data nodes with
> accordance of correct version of filter from {{CatalogZoneDescriptor}}
> *Implementation notes*
> This could be done with the enriching {{UpdateEntry#applyUpdate(Catalog
> catalog)}} with {{causalityToken}}, so we could propagate {{causalityToken}}
> to all {{UpdateEntry}}, where we recreate {{CatalogObjectDescriptor}} and
> create new version of {{Catalog}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20448) Implement strategies for failure handling
[ https://issues.apache.org/jira/browse/IGNITE-20448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-20448: --- Reviewer: Vyacheslav Koptilin > Implement strategies for failure handling > - > > Key: IGNITE-20448 > URL: https://issues.apache.org/jira/browse/IGNITE-20448 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > Need to implement the following strategies for failure handling: > - StopNodeFailureHandler This handler should stop the node in case of a > critical error > - StopNodeOrHaltFailureHandler This handler should try to stop the node. If > the node cannot be stopped during a timeout, then the JVM process should be > stopped forcibly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20448) Implement strategies for failure handling
[ https://issues.apache.org/jira/browse/IGNITE-20448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-20448: -- Assignee: Sergey Uttsel (was: Vyacheslav Koptilin) > Implement strategies for failure handling > - > > Key: IGNITE-20448 > URL: https://issues.apache.org/jira/browse/IGNITE-20448 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > Need to implement the following strategies for failure handling: > - StopNodeFailureHandler This handler should stop the node in case of a > critical error > - StopNodeOrHaltFailureHandler This handler should try to stop the node. If > the node cannot be stopped during a timeout, then the JVM process should be > stopped forcibly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20448) Implement strategies for failure handling
[ https://issues.apache.org/jira/browse/IGNITE-20448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-20448: -- Assignee: Vyacheslav Koptilin (was: Sergey Uttsel) > Implement strategies for failure handling > - > > Key: IGNITE-20448 > URL: https://issues.apache.org/jira/browse/IGNITE-20448 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Need to implement the following strategies for failure handling: > - StopNodeFailureHandler This handler should stop the node in case of a > critical error > - StopNodeOrHaltFailureHandler This handler should try to stop the node. If > the node cannot be stopped during a timeout, then the JVM process should be > stopped forcibly. -- 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. 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. -- 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. * was:IGNITE-20479 replaced custom null checks with standard > .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. > * -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20523) .NET: Thin 3.0: ArgumentNullException.ThrowIfNull allocates on value types
Pavel Tupitsyn created IGNITE-20523: --- Summary: .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 Fix For: 3.0.0-beta2 -- 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 > .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 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20471) Timeout exception from org.apache.ignite.sql.Session#execute() could be printed to log ambiguously
[
https://issues.apache.org/jira/browse/IGNITE-20471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20471:
---
Component/s: sql
> Timeout exception from org.apache.ignite.sql.Session#execute() could be
> printed to log ambiguously
> --
>
> Key: IGNITE-20471
> URL: https://issues.apache.org/jira/browse/IGNITE-20471
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> The following code prints the different logs:
> {code:java}
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT)");
> IgniteSql sql = igniteSql();
> Session ses = sql.sessionBuilder().build();
> try {
> ses.execute(null, "INSERT INTO TEST VALUES (?, ?)", 1, 1);
> } catch (Exception e) {
> log.error("EXCEPTION", e);
> throw e;
> }
> {code}
> This log is printed when we call {{log.error("EXCEPTION", e);}}
> {noformat}
> [2023-09-29T17:58:48,717][ERROR][main][ItSqlAsynchronousApiTest] EXCEPTION
> org.apache.ignite.lang.IgniteException: null
> at
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> ~[?:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.select(ItSqlAsynchronousApiTest.java:458)
> ~[integrationTest/:?]
> ...
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:54d81fd9-6453-4adb-863d-6e82b9c0cb08
> at
> org.apache.ignite.internal.sql.api.SessionImpl.lambda$executeAsync$3(SessionImpl.java:208)
> ~[main/:?]
> ...
> Caused by: org.apache.ignite.lang.IgniteException
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:110)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:100)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:76)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> ~[?:?]
> ...
> Caused by: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.sql.engine.exec.ResolvedDependencies.fetchColocationGroup(ResolvedDependencies.java:60)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.fetchColocationGroups(ExecutionServiceImpl.java:982)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.mapFragments(ExecutionServiceImpl.java:850)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$11(ExecutionServiceImpl.java:654)
> ~[main/:?]
> ...
> {noformat}
> This one is printed after we {{throw e}}
> {noformat}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:54d81fd9-6453-4adb-863d-6e82b9c0cb08
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
>
[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate
[
https://issues.apache.org/jira/browse/IGNITE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20367:
-
Reviewer: Vladislav Pyatkov
> ItTableRaftSnapshotsTest times out with high flaky rate
> ---
>
> Key: IGNITE-20367
> URL: https://issues.apache.org/jira/browse/IGNITE-20367
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
> at
> app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
> at
> app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
> at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
> at
> app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
>
